date:20150206

Rather than accumulating into host_testid_suffix directly, accumulate
into a list testid_args first.

No functional change: all we do is defer the construction of
host_testid_suffix, which is not used until later in this function.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 sg-run-job |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 68d6c65..5c192ab 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -117,19 +117,22 @@ proc spawn-ts {iffail testid ts args} {
 
 set real_args {}
 set adding 1
-set host_testid_suffix {}
+set testid_args {}
 foreach arg $args {
 if {![string compare + $arg]} {
 set adding [expr {!$adding}]
 continue
 }
 lappend real_args $arg
-if {$adding} { append host_testid_suffix /$arg }
+if {$adding} { lappend testid_args $arg }
 }
 
 regsub {^ts-} $ts {} deftestid
 append deftestid /@
 
+set host_testid_suffix {}
+foreach arg $testid_args { append host_testid_suffix /$arg }
+
 jobdb::spawn-step-begin $flight $jobinfo(job) $ts stepno
 
 if {[string match =* $testid]} {
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 00/10] Repeat rump kernel xenstorels test

This 10-patch series(!) arranges to repeat the xenstorels test 50
times.  In my ad-hoc tests this takes about 3 minutes so is clearly
fine from a resource POV.

This is in aid of debugging the problem seen in 33690 and 33416 (which
we think is the same).  However, in my ad-hoc tests it hasn't failed
even once (with the bits from flight 33866 which is after we think the
bug appeared).  I think it would be valuable to introduce this new
repeat test in any case.

The series is in four parts:

 - 01..03  Minor improvements in TestSupport.pm

 - 04..07 Changes to testid generation to give better control of the
   testid for tests done with the ts-repeat-test script from
   patch 08.

 - 08..10  Actually do the repetition

04..07 need a thorough full-flight test which I have not yet done.
But this sql rune suggests that nothing is horribly broken at least
for the rump test job:

  select * from (select testid,flight,stepno,step,status,started,finished from 
steps where flight=33866 and job='test-amd64-i386-rumpuserxen-i386') a full 
outer join (select * from steps where flight=34273 and 
job='test-amd64-i386-rumpuserxen-i386') b using (testid) order by b.stepno, 
a.stepno;


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 08/10] sg-run-job, etc.: Infrastructure for test script repetition

Provide:
 * ts-repeat-test, a script to run multiple other test scripts in a loop
 * repeat-ts, a proc in sg-run-job which invokes it

No callers yet.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 sg-run-job |4 
 ts-repeat-test |   66 
 2 files changed, 70 insertions(+)
 create mode 100755 ts-repeat-test

diff --git a/sg-run-job b/sg-run-job
index 070534d..0a49c93 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -103,6 +103,10 @@ proc run-ts {args} {
 if {![reap-ts $reap]} { error test script failed }
 }
 
+proc repeat-ts {reps testid args} {
+ eval [list run-ts . $testid + ts-repeat-test $reps +] $args
+}
+
 proc spawn-ts {iffail testid args} {
 global flight c jobinfo reap_details env
 
diff --git a/ts-repeat-test b/ts-repeat-test
new file mode 100755
index 000..e3b1426
--- /dev/null
+++ b/ts-repeat-test
@@ -0,0 +1,66 @@
+#!/usr/bin/perl -w
+#
+# usage:
+#   ./ts-repeat-test COUNT ARGSPECS...
+#   ./ts-repeat-test COUNT [-] ts-SCRIPT [ARGS...] [; ...]
+#
+# ts-SCRIPT  will be prefixed with ./ before execution
+# (provided it actually starts with `ts-')
+# ;  separates multiple scripts to be run
+# -  before script name means to ignore errors
+# \  at the start of any ARGSPEC is removed (after the checks above)
+
+use strict;
+use Osstest::TestSupport;
+
+use Data::Dumper;
+
+tsreadconfig();
+
+my $reps = shift @ARGV;
+die unless @ARGV  $reps =~ m/^\d+$/;
+
+my @cmdis = ();
+my $cmdi = { };
+# $cmds[]{L} = qw(./ts-foo-bar arg arg...);
+# $cmds[]{IgnoreError} = undef or 1
+
+push @ARGV, ';';
+
+foreach (@ARGV) {
+if ($_ eq ';') {
+   if (%$cmdi) {
+   push @cmdis, $cmdi;
+   $cmdi = { };
+   }
+} else {
+   if (!$cmdi-{L}) {
+   if ($_ eq '-') {
+   $cmdi-{IgnoreError} = 1;
+   next;
+   }
+   s#^(?=ts-)#./#;
+   }
+   s#^\\##;
+   push @{ $cmdi-{L} }, $_;
+}
+}
+
+my $dumper = new Data::Dumper [\@cmdis], [qw(*cmdis)];
+$dumper-Indent(0);
+print $dumper-Dump,\n;
+
+foreach my $rep (1..$reps) {
+logm(== rep $rep ==);
+foreach my $cmdi (@cmdis) {
+   my $l = $cmdi-{L};
+   logm(-- rep $rep @$l --);
+   my $r = system @$l;
+   if ($r) {
+   my $m = $l-[0]: .($r==-1 ? $! : status $?).\n;
+   if ($cmdi-{IgnoreError}) { warn $m; } else { die $m; }
+   }
+}
+}
+
+logm(== did $reps ==);
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 10/10] rump kernel tests: Repeat the xenstorels test 50 times

Add a new step which uses repeat-ts to run
ts-rumpuserxen-demo-xenstorels many times.

We have to run ts-guest-destroy-hard first each time, to destroy the
guest which might exist at each previous step.  To help with ad-hoc
debugging runs, we specify `-' on the destroy, so that if the destroy
fails (probably because the guest doesn't exist) we don't mind.

Strategically placed `+'s in the repeat-ts command line arrange that
the testid ends up being
   rumpuserxen-demo-xenstorels/xenstorels.repeat

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 sg-run-job |3 +++
 1 file changed, 3 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 0a49c93..ebbf53f 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -327,6 +327,9 @@ proc run-job/test-rumpuserxen {} {
 set g xenstorels
 run-ts . =   ts-rumpuserxen-demo-setup  + host + $g
 run-ts . =   ts-rumpuserxen-demo-xenstorels + host + $g
+repeat-ts 50 =.repeat \
+ + - ts-guest-destroy-hardhost   $g \; + \
+ ts-rumpuserxen-demo-xenstorels + host + $g
 run-ts . =   ts-guest-destroy-hard  + host + $g
 }
 
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Development for Dummies.

2015-02-06 Thread Jason Long

Thank you.
Can you answer my previous questions about Ocaml and C? Why Ocaml is unique and 
which part of Xen use it?
I know my questions are silly but I'm a dummies and I looked at amazon.com and 
found Tons of C book but which one is good?

Cheers.



On Friday, February 6, 2015 5:14 PM, Pasi Kärkkäinen pa...@iki.fi wrote:
On Fri, Feb 06, 2015 at 01:35:58PM +, Jason Long wrote:
 In your opinion, Can a normal user like me become a developer? 
 I must first start learning C or Ocaml? Can you recommend a book for both to 
 me? 
 Can you tell me why developers choose Ocaml and C? and not C++ or Python?


Xen hypervisor, like any other hypervisor, is a very low level piece of 
software.
Lowlevel software tends to be written in lowlevel languages, such as C and 
assembler.

Like said most of Xen is written in C, so you need to learn/know C.

You should first start with learning programming with C language, and the 
generic concepts of computer hardware,
operating systems, kernels, memory management, etc.

Something like a hypervisor, or an operating system kernel, is a quite complex 
beast,
so you should probably first start with something much easier and learn C 
properly in an easier project.
When you know C and Linux/Unix internals well you can continue working on Xen 
aswell.


-- Pasi


 Cheers.
 
 
 
 On Friday, February 6, 2015 2:46 AM, Pasi Kärkkäinen pa...@iki.fi wrote:
 On Fri, Feb 06, 2015 at 10:31:09AM +, Jason Long wrote:
  Can you tell me why Ocaml used? What is the features of this language? Why 
  not other?
  Excuse me, I'm a beginner in programming and can you show me some books or 
  reference step by step? I'm a dummies :(
 
 
 There are two different versions of xenstore-daemon (xenstored). 
 The earlier one, written in C, and the newer one, written in OCaml 
 (oxenstored).
 
 Note that this is just one of the many components in Xen. Most Xen components 
 are written in C.
 
 Here you have some slides about oxenstored:
 http://gazagnaire.org/pub/GH09.pdf
 
 
 -- Pasi
 
 
  Cheers.
  
  
  
  On Thursday, February 5, 2015 11:59 PM, Pasi Kärkkäinen pa...@iki.fi 
  wrote:
  On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote:
   Hello Folks.
   I want to become a Xen developer and I don't have any knowledge about 
   development. Can you tell me what programming language is needed? How can 
   I start and etc?
  
  
  Hello,
  
  Xen is mostly written in C language, but there are other languages being 
  used aswell.. obviously lowlevel assembly language for some architecture 
  specific lowlevel stuff, and some highler level languages (OCaml) for 
  certain components (oxenstored). Also various scripting languages are used, 
  perl, python, etc. 
  
  Also you need to know all the usual Linux/Unix commandline (development) 
  tools.
  
  -- Pasi
  
  
   
   Tnx.
   
   ___
   Xen-devel mailing list
   Xen-devel@lists.xen.org
   http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 03/10] TestSupport: Make next_unique_name count in decimal, not unary

Ie, we add `+counter' rather than an ever-longer series of `+'s.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 Osstest/TestSupport.pm |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 55541b1..8aed285 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -486,7 +486,8 @@ sub target_file_exists ($$) {
 
 sub next_unique_name ($) {
 my ($fnref) = @_;
-$$fnref .= '+';
+my $num = $$fnref =~ s/\+([1-9]\d*)$// ? $1 : 0;
+$$fnref .= '+'.($num+1);
 }
 
 our $target_editfile_cancel_exception =
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 04/10] tcl/osstestlib.tcl: Provide lshift

No callers yet.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 tcl/osstestlib.tcl |7 +++
 1 file changed, 7 insertions(+)

diff --git a/tcl/osstestlib.tcl b/tcl/osstestlib.tcl
index 1531c87..a0413c4 100644
--- a/tcl/osstestlib.tcl
+++ b/tcl/osstestlib.tcl
@@ -67,3 +67,10 @@ proc lremove {listvar item} {
 if {$ix0} return
 set list [lreplace $list $ix $ix]
 }
+
+proc lshift {listvar} {
+upvar 1 $listvar list
+set head [lindex $list 0]
+set list [lrange $list 1 end]
+return $head
+}
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 09/10] rump kernel tests: Cancel unneeded edits of guest config

If the guest config is already set up to preserve, cancel the edit.
We are going to repeat this test, and this avoids creating many
identical copies of the same file in the log output.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 ts-rumpuserxen-demo-xenstorels |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index ed46843..a54fbf4 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -32,7 +32,11 @@ our $gn = $gho-{Guest};
 sub arrangepreserve () {
 target_editfile_root($ho,$r{$gho-{Guest}_cfgpath}, sub {
while (EI) {
-   next if m/^\s*on_poweroff\s*=/;
+   if (m/^\s*on_poweroff\s*=/) {
+   target_editfile_cancel(already configured to preserve)
+   if m/\bpreserve\b/;
+   next;
+   }
print EO or die $!;
}
print EO \n,on_poweroff='preserve'\n or die $!;
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 07/10] sg-run-job: testid generation: Process ts more like rest of args

Remove ts as a separate parameter to spawn-ts.  The test script now
becomes the first entry in args.

We process it through the arg loop as before.  Currently there are no
calls where the first arg is `+' so the test script name ends up in
both real_args and testid_args.

We split it out of real_args into the ts variable with lshift.
We split it out of testid_args into the deftestid with lshift.

So afterwards in spawn-ts, all the variables (including real_args, ts,
deftestid and testid_args and hence host_testid_suffix) have the
values they would have had before.

Therefore there is no functional change for any existing calls.

However, because the first argument is not treated specially for the
`+' procesing loop, it is now possible to specify `+' as the first
entry in args to spawn-ts (ie where ts used to be) to arrange that the
deftestid (and hence, probably, the testid) is computed using later
arguments.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 sg-run-job |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 5c192ab..070534d 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -103,12 +103,12 @@ proc run-ts {args} {
 if {![reap-ts $reap]} { error test script failed }
 }
 
-proc spawn-ts {iffail testid ts args} {
+proc spawn-ts {iffail testid args} {
 global flight c jobinfo reap_details env
 
 if {[file exists abort]} {
 jobdb::logputs stdout \
-aborting - not executing $flight.$jobinfo(job) $ts $args
+aborting - not executing $flight.$jobinfo(job) $args
 job-set-status $flight $jobinfo(job) aborted
 return {}
 }
@@ -127,7 +127,9 @@ proc spawn-ts {iffail testid ts args} {
 if {$adding} { lappend testid_args $arg }
 }
 
-regsub {^ts-} $ts {} deftestid
+set ts [lshift real_args]
+
+regsub {^ts-} [lshift testid_args] {} deftestid
 append deftestid /@
 
 set host_testid_suffix {}
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 05/10] sg-run-job: testid generation: Move spawn-step-begin

Run spawn-step-begin until after the loop over $args, and after the
computation of the basic deftestid.

No functional change: nothing in that loop looks at stepno.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 sg-run-job |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 2cf810a..68d6c65 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -115,8 +115,6 @@ proc spawn-ts {iffail testid ts args} {
 
 if {![string compare . $iffail]} { set iffail fail }
 
-jobdb::spawn-step-begin $flight $jobinfo(job) $ts stepno
-
 set real_args {}
 set adding 1
 set host_testid_suffix {}
@@ -132,6 +130,8 @@ proc spawn-ts {iffail testid ts args} {
 regsub {^ts-} $ts {} deftestid
 append deftestid /@
 
+jobdb::spawn-step-begin $flight $jobinfo(job) $ts stepno
+
 if {[string match =* $testid]} {
 set testid $deftestid[string range $testid 1 end]
 } elseif {![string compare $testid *]} {
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [rumpuserxen test] 34212: regressions - FAIL

flight 34212 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34212/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 33866

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumpuserxen  e28e2b9daf7ab2922913889d90ec438b9bee3d56
baseline version:
 rumpuserxen  30d72f3fc5e35cd53afd82c8179cc0e0b11146ad


People who touched revisions under test:
  Ian Jackson ian.jack...@eu.citrix.com
  Martin Lucina mar...@lucina.net


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-i386-rumpuserxen-i386 blocked 



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

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

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


Not pushing.


commit e28e2b9daf7ab2922913889d90ec438b9bee3d56
Author: Ian Jackson ian.jack...@eu.citrix.com
Date:   Wed Feb 4 16:29:26 2015 +

app-tools: Support old -D__RUMPUSER_XEN__ for now

Released versions of Xen (Xen 4.5) rely on __RUMPUSER_XEN__ being
defined.

A patch to change this in Xen upstream exists and will be backported,
but until that makes it through to a stable point release of Xen 4.5,
we should support both #defines.

This commit partially reverts 91d56232d987
   Renaming platform macros, app-tools and autoconf target string

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Martin Lucina mar...@lucina.net
CC: Ian Campbell ian.campb...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com

commit 05e06b0fe52918d6575e33b7d7551d85c93f7aff
Author: Martin Lucina mar...@lucina.net
Date:   Mon Feb 2 18:01:52 2015 +0100

Sync Travis CI configuration with app-tools rename

Signed-off-by: Martin Lucina mar...@lucina.net

commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
Author: Martin Lucina mar...@lucina.net
Date:   Mon Feb 2 18:00:36 2015 +0100

Remove even older rumpxen-app-* variants of app-tools

Signed-off-by: Martin Lucina mar...@lucina.net

commit 91d56232d987f5df594723ed46b9000b4d43e21a
Author: Martin Lucina mar...@lucina.net
Date:   Mon Feb 2 17:52:41 2015 +0100

Renaming platform macros, app-tools and autoconf target string

As discussed at: http://thread.gmane.org/gmane.comp.rumpkernel.user/739

This commit renames the platform macros, app-tools and autoconf target
string to be consistent with current naming of the entire stack:

app-tools/rumpapp-xen-* - app-tools/rumprun-xen-*
$ARCH-rumpxen-netbsd - $ARCH-rumprun-netbsd
-D__RUMPUSER_XEN__ -D__RUMPAPP__ - -D__RUMPRUN__

Signed-off-by: Martin Lucina mar...@lucina.net

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Development for Dummies.

2015-02-06 Thread Razvan Cojocaru

On 02/06/2015 09:17 PM, Jason Long wrote:
 I know my questions are silly but I'm a dummies and I looked at amazon.com 
 and found Tons of C book but which one is good?

The C Programming Language, by Brian W. Kernighan and Dennis M.
Ritchie: http://cm.bell-labs.com/cm/cs/cbook/


Cheers,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] vNUMA for PV guest: kernel and toolstack interaction regarding e820_host=1

Hi all

I encounter a problem that I would like to get some advice. It's PV
specific because of the P2M manipulation is only required by PV.

Current scheme of memory allocation scheme:

1. Libxc populate contiguous chunk of pages and fill in initial P2M. The
   holes in e820 map are in fact filled with pages.

2. Guest kernel reads e820 map from Xen and remap pages in e820 holes if
   there are holes, update P2M as it sees fit. (That is normally true when
   e820_host=1 is set)

This is not very ideal for PV vNUMA, because those pages remapped may
end up in the wrong vnode.

What I have in mind is:

1. Libxc populates pages, but skips e820 holes. The initial P2M is the
   final P2M guest sees.
2. Guest kernel skips remapping. But Linux still needs to setup 1-1
   mapping for holes.

In order to avoid misconfiguration, we would need to introduce a new
feature flag to indicate guest has the ability to skip remapping. Libxc
will check that feature flag when building domain.

Does the above scheme make sense?

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] vNUMA for PV guest: kernel and toolstack interaction regarding e820_host=1

On Fri, Feb 06, 2015 at 07:42:15PM +, David Vrabel wrote:
 On 06/02/15 19:32, Wei Liu wrote:
  Hi all
  
  I encounter a problem that I would like to get some advice. It's PV
  specific because of the P2M manipulation is only required by PV.
  
  Current scheme of memory allocation scheme:
  
  1. Libxc populate contiguous chunk of pages and fill in initial P2M. The
 holes in e820 map are in fact filled with pages.
  
  2. Guest kernel reads e820 map from Xen and remap pages in e820 holes if
 there are holes, update P2M as it sees fit. (That is normally true when
 e820_host=1 is set)
  
  This is not very ideal for PV vNUMA, because those pages remapped may
  end up in the wrong vnode.
  
  What I have in mind is:
  
  1. Libxc populates pages, but skips e820 holes. The initial P2M is the
 final P2M guest sees.
  2. Guest kernel skips remapping. But Linux still needs to setup 1-1
 mapping for holes.
  
  In order to avoid misconfiguration, we would need to introduce a new
  feature flag to indicate guest has the ability to skip remapping. Libxc
  will check that feature flag when building domain.
  
  Does the above scheme make sense?
 
 I really not keen on any additional complexity in PV guest memory setup.

I agree. I would like to avoid as much complexity as possible. That's
why I ask before implementing anything on guest side.

FWIW the tool stack side already makes sense to me (sans the new feature
flag). It's Linux that I'm not very sure of what to do.

  Particularly as I don't see a long term future for x86 PV guests.  I
 also don't think we should bake into the Xen ABI the behaviour of one
 particular guest.
 
 Consider how you can fix this purely in the guest.
 

Yeah, I guess I can make the memory movement more sensible inside Linux.
That is, take into consideration vNUMA information. There might be other
complex interactions, I will need to get my hands dirty first.

Now my conclusion is that I should proceed with my toolstack side patches
first and fix Linux later.

Wei.

 David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] Repeat rump kernel xenstorels test

Ian Jackson writes ([PATCH 00/10] Repeat rump kernel xenstorels test):
 04..07 need a thorough full-flight test which I have not yet done.
 But this sql rune suggests that nothing is horribly broken at least
 for the rump test job:
 
   select * from (select testid,flight,stepno,step,status,started,finished 
 from steps where flight=33866 and job='test-amd64-i386-rumpuserxen-i386') a 
 full outer join (select * from steps where flight=34273 and 
 job='test-amd64-i386-rumpuserxen-i386') b using (testid) order by b.stepno, 
 a.stepno;

For my own records: said full-flight test is now running as 34137.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] vNUMA for PV guest: kernel and toolstack interaction regarding e820_host=1

2015-02-06 Thread David Vrabel

On 06/02/15 19:32, Wei Liu wrote:
 Hi all
 
 I encounter a problem that I would like to get some advice. It's PV
 specific because of the P2M manipulation is only required by PV.
 
 Current scheme of memory allocation scheme:
 
 1. Libxc populate contiguous chunk of pages and fill in initial P2M. The
holes in e820 map are in fact filled with pages.
 
 2. Guest kernel reads e820 map from Xen and remap pages in e820 holes if
there are holes, update P2M as it sees fit. (That is normally true when
e820_host=1 is set)
 
 This is not very ideal for PV vNUMA, because those pages remapped may
 end up in the wrong vnode.
 
 What I have in mind is:
 
 1. Libxc populates pages, but skips e820 holes. The initial P2M is the
final P2M guest sees.
 2. Guest kernel skips remapping. But Linux still needs to setup 1-1
mapping for holes.
 
 In order to avoid misconfiguration, we would need to introduce a new
 feature flag to indicate guest has the ability to skip remapping. Libxc
 will check that feature flag when building domain.
 
 Does the above scheme make sense?

I really not keen on any additional complexity in PV guest memory setup.
 Particularly as I don't see a long term future for x86 PV guests.  I
also don't think we should bake into the Xen ABI the behaviour of one
particular guest.

Consider how you can fix this purely in the guest.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvSCSI test

2015-02-06 Thread Kristian Hagsted Rasmussen

On Friday, February 6, 2015 15:25, Juergen Gross jgr...@suse.com wrote:
To: Kristian Hagsted Rasmussen; Olaf Hering; xen-de...@lists.xensource.com
Subject: Re: [Xen-devel] pvSCSI test

After some more fiddling around, I believe the configuration should be okay.
My /etc/target/xen-pvscsi_start.sh look like this:

modprobe xen-scsiback
mkdir /sys/kernel/config/target/xen-pvscsi
mkdir -p /sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0
echo naa.6001405708ab297e
/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/nexus
xen-pvscsi Target Ports
mkdir -p
/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/lun/lun_0
ln -s
/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/lun/lun_0/../../../../../../target/core/iblock_0/3_0_0_0

/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/lun/lun_0/xen-pvscsi_port

iblock_0?

Sorry the result is the same if I use pscsi, I just tried iblock as it was a
harddisk I tried to pass through and lio documentation advice against using
pscsi for hard drives.

I just now tried to pass through a bluray drive on another machine, however I
get the exact same error. What I noticed, however, was that the error only
appears if the DomU kernel supports xen-scsifront. I hazzard a guess that this
is because the backend only tries to connect to the device if the frontend
makes a call for it.

In xenstore I have the following entry for vscsi under /local/domain/0/backend:
vscsi =
3 =
0 =
frontend = /local/domain/3/device/vscsi/0
frontend-id = 3
online = 1
state = 4
feature-host = 0
vscsi-devs =
dev-0 =
p-dev = 3:0:0:0
v-dev = 0:0:0:0
state = 6
feature-sg-grant = 128

As I am no expert I am not sure about this, but shouldn't there be a path to
the device, more then just the p-dev statement?

Do I have to manually add the device to xenstore?

If you do not feel for answering more of my questions please feel free to say
so, I am just interested in this work and really look forward to its inclusion
in xen.

/Kristian

You are not using pscsi, but iblock. Is that on purpose? I have tested
pscsi and fileio only.

What does lsscsi tell you after adding the device via targetcli? I
suppose you see a new scsi target you should use instead of 3:0:0:0
(that's what I did in the fileio case).

Attributes for xen-pvscsi Target Portal Group
Parameters for xen-pvscsi Target Portal Group
echo 3:0:0:0
/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/param/alias

And
cat
/sys/kernel/config/target/xen-pvscsi/naa.600140512a981c66/tpgt_0/param/alias
returns 3:0:0:0 as expected.

If I understand this correctly, it is xen-scsiback that reads the target
configuration from ConfigFS and hence the problem that xen-pvscsi cannot
find the device has nothing to do with which toolstack is used?

Yes and no. In theory the backend would accept anything from xenstore
which it can find in configfs. The toolstack however will only write
values into the xenstore it believes are valid SCSI devices.

If you are willing to part with the script you used together with targetcli,
I would be more then happy to try that out.

I did my first tests with fileio on a machine I have no longer access
to. after I got it running I changed to my local test machine and pscsi.
Here I did the targetcli stuff manually and verified afterwards that
the single steps I put in my script were working. So the script I gave
you is basically the documentation of the manual setup I used.

Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 02/10] TestSupport: Introduce next_unique_name

No functional change.

Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
 Osstest/TestSupport.pm |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5a4c41f..55541b1 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -46,7 +46,7 @@ BEGIN {
 
   store_runvar get_runvar get_runvar_maybe
   get_runvar_default need_runvars flight_otherjob
-  unique_incrementing_runvar 
+  unique_incrementing_runvar next_unique_name
 
   target_cmd_root target_cmd target_cmd_build
   target_cmd_output_root target_cmd_output
@@ -484,6 +484,11 @@ sub target_file_exists ($$) {
 die $rfile $out ?;
 }
 
+sub next_unique_name ($) {
+my ($fnref) = @_;
+$$fnref .= '+';
+}
+
 our $target_editfile_cancel_exception =
 bless { }, 'Osstest::TestSupport::TargetEditfileCancelException';
 
@@ -509,7 +514,7 @@ sub teditfileex {
 $! == ENOENT or die $lfile $!;
 last;
 }
-$lleaf .= '+';
+next_unique_name \$lleaf;
 }
 if ($rdest eq $rfile) {
 logm(editing $rfile as $lfile.'{,.new}');
@@ -929,7 +934,7 @@ sub open_unique_stashfile ($) {
 $dh= new IO::File $stash/$df, O_WRONLY|O_EXCL|O_CREAT;
 last if $dh;
 die $df $! unless $!==EEXIST;
-$$leafref .= '+';
+next_unique_name $leafref;
 }
 return $dh;
 }
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

2015-02-06 Thread Sasha Levin

On 02/06/2015 02:42 PM, Davidlohr Bueso wrote:
 On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
 On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
 raghavendra...@linux.vnet.ibm.com wrote:
 Paravirt spinlock clears slowpath flag after doing unlock.
 [ fix edited out ]

 So I'm not going to be applying this for 3.19, because it's much too
 late and the patch is too scary. Plus the bug probably effectively
 never shows up in real life (it is probably easy to trigger the
 speculative *read* but probably never the actual speculative write
 after dropping the lock last).

 This will need a lot of testing by the paravirt people - both
 performance and correctness. So *maybe* for 3.20, but maybe for even
 later, and then marked for stable, of course.

 Are there any good paravirt stress-tests that people could run for
 extended times?
 
 locktorture inside a VM should give a proper pounding.

Would it catch lifetime issues too? I thought it just tests out correctness.

I tried it and other unrelated stuff broke. I'll send separate mails for that...


Thanks,
Sasha

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

2015-02-06 Thread Sasha Levin

On 02/06/2015 09:49 AM, Raghavendra K T wrote:
 Paravirt spinlock clears slowpath flag after doing unlock.
 As explained by Linus currently it does:
 prev = *lock;
 add_smp(lock-tickets.head, TICKET_LOCK_INC);
 
 /* add_smp() is a full mb() */
 
 if (unlikely(lock-tickets.tail  TICKET_SLOWPATH_FLAG))
 __ticket_unlock_slowpath(lock, prev);
 
 
 which is *exactly* the kind of things you cannot do with spinlocks,
 because after you've done the add_smp() and released the spinlock
 for the fast-path, you can't access the spinlock any more.  Exactly
 because a fast-path lock might come in, and release the whole data
 structure.
 
 Linus suggested that we should not do any writes to lock after unlock(),
 and we can move slowpath clearing to fastpath lock.
 
 However it brings additional case to be handled, viz., slowpath still
 could be set when somebody does arch_trylock. Handle that too by ignoring
 slowpath flag during lock availability check.
 
 Reported-by: Sasha Levin sasha.le...@oracle.com
 Suggested-by: Linus Torvalds torva...@linux-foundation.org
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com

With this patch, my VMs lock up quickly after boot with:

[  161.613469] BUG: spinlock lockup suspected on CPU#31, kworker/31:1/5213
[  161.613469]  lock: purge_lock.28981+0x0/0x40, .magic: dead4ead, .owner: 
kworker/7:1/6400, .owner_cpu: 7
[  161.613469] CPU: 31 PID: 5213 Comm: kworker/31:1 Not tainted 
3.19.0-rc7-next-20150204-sasha-00048-gee3a350 #1869
[  161.613469] Workqueue: events bpf_prog_free_deferred
[  161.613469]   f03dd27f 88056b227a88 
a1702276
[  161.613469]   88017cf7 88056b227aa8 
9e1d009c
[  161.613469]  a3edae60 86c3f830 88056b227ad8 
9e1d01d7
[  161.613469] Call Trace:
[  161.613469] dump_stack (lib/dump_stack.c:52)
[  161.613469] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8))
[  161.613469] do_raw_spin_lock (include/linux/nmi.h:48 
kernel/locking/spinlock_debug.c:119 kernel/locking/spinlock_debug.c:137)
[  161.613469] _raw_spin_lock (kernel/locking/spinlock.c:152)
[  161.613469] ? __purge_vmap_area_lazy (mm/vmalloc.c:615)
[  161.613469] __purge_vmap_area_lazy (mm/vmalloc.c:615)
[  161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[  161.613469] vm_unmap_aliases (mm/vmalloc.c:1052)
[  161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[  161.613469] ? __lock_acquire (kernel/locking/lockdep.c:2019 
kernel/locking/lockdep.c:3184)
[  161.613469] change_page_attr_set_clr (arch/x86/mm/pageattr.c:1394)
[  161.613469] ? debug_object_deactivate (lib/debugobjects.c:463)
[  161.613469] set_memory_rw (arch/x86/mm/pageattr.c:1662)
[  161.613469] ? __lock_is_held (kernel/locking/lockdep.c:3518)
[  161.613469] bpf_jit_free (include/linux/filter.h:377 
arch/x86/net/bpf_jit_comp.c:991)
[  161.613469] bpf_prog_free_deferred (kernel/bpf/core.c:646)
[  161.613469] process_one_work (kernel/workqueue.c:2014 
include/linux/jump_label.h:114 include/trace/events/workqueue.h:111 
kernel/workqueue.c:2019)
[  161.613469] ? process_one_work (./arch/x86/include/asm/atomic64_64.h:33 
include/asm-generic/atomic-long.h:38 kernel/workqueue.c:598 
kernel/workqueue.c:625 kernel/workqueue.c:2007)
[  161.613469] worker_thread (include/linux/list.h:189 kernel/workqueue.c:2147)
[  161.613469] ? process_one_work (kernel/workqueue.c:2091)
[  161.613469] kthread (kernel/kthread.c:207)
[  161.613469] ? finish_task_switch (./arch/x86/include/asm/current.h:14 
kernel/sched/sched.h:1058 kernel/sched/core.c:2258)
[  161.613469] ? flush_kthread_work (kernel/kthread.c:176)
[  161.613469] ret_from_fork (arch/x86/kernel/entry_64.S:283)
[  161.613469] ? flush_kthread_work (kernel/kthread.c:176)

And a few soft lockup messages inside the scheduler after that.


Thanks,
Sasha



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 1/7] linux-stubdomain: Compile QEMU

On Fri, Feb 06, 2015 at 12:25:33PM -0500, Eric Shelton wrote:
 On Fri, Feb 6, 2015 at 10:46 AM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  On Tue, 3 Feb 2015, Eric Shelton wrote:
 
  Before having patches, I would like to try to get them upstream in QEMU.
  If we really cannot do that, then I would still prefer to commit any
  required workarounds to the qemu-xen rather than having them here as
  patches.
 
 Absolutely; the intent is to upstream the changes to QEMU, and
 eliminate the patching to QEMU being done in the patchset I sent out.
 I just need to sort out all of the QEMU changes first...
 
  diff --git a/stubdom-linux/qemu-xen-common.patch 
  b/stubdom-linux/qemu-xen-common.patch
  new file mode 100644
  index 000..b473e36
  --- /dev/null
  +++ b/stubdom-linux/qemu-xen-common.patch
  @@ -0,0 +1,12 @@
  +--- a/xen-common.c   2015-01-25 20:42:36.32998 -0500
   b/xen-common.c   2015-01-25 20:43:20.34663 -0500
  +@@ -92,7 +92,8 @@
  + exit(1);
  + }
  +
  +-snprintf(path, sizeof (path), device-model/%u/state, xen_domid);
  ++snprintf(path, sizeof (path),
  ++ /local/domain/0/device-model/%u/state, xen_domid);
 
  Even if this counts as a workaround, I think it could go upstream in
  QEMU.
 
 Agreed, although I will likely follow Wei's suggestion to use a
 /local/domain/{stubdom-id}/... path, instead of under dom0's tree in
 xenstore.
 

I guess if you don't use absolute path it should just writes to
/local/domain/$stubdom_id. (This has a restriction that it doesn't work
with xenstore connection opened with socket.)

Since you're at it, could you try to 

1) retain the relative path used here, so that it writes to ~ (from
   stubdom's PoV it is /local/domain/$stubdom_id, that's the theory)
2) modify patch 7/7 to use the /local/domain/$stubdom_id path.

My hunch is that it is not too complicated to retrieve stubdom_id in
libxl (it should be available somewhere).

A side note is that you may need to grant write permission the stubdom to
write to its own path. Search for XS_PERM_ in libxl_dm.c you will see
some place using /local/domain/0.

That's what I would do to tackle this whole problem. I haven't tried it
personally though (got distracted half way).

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

2015-02-06 Thread Davidlohr Bueso

On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
 On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
 raghavendra...@linux.vnet.ibm.com wrote:
  Paravirt spinlock clears slowpath flag after doing unlock.
 [ fix edited out ]
 
 So I'm not going to be applying this for 3.19, because it's much too
 late and the patch is too scary. Plus the bug probably effectively
 never shows up in real life (it is probably easy to trigger the
 speculative *read* but probably never the actual speculative write
 after dropping the lock last).
 
 This will need a lot of testing by the paravirt people - both
 performance and correctness. So *maybe* for 3.20, but maybe for even
 later, and then marked for stable, of course.
 
 Are there any good paravirt stress-tests that people could run for
 extended times?

locktorture inside a VM should give a proper pounding.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen's Linux kernel config options V2

On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
 arm and arm64

I'll update CONFIG_XEN_PVHVM to be x86 specific, it already depends on
X86_LOCAL_APIC, so just updating it on the proposal to annotate it is
x86 specific.

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen's Linux kernel config options V2

On Mon, Jan 19, 2015 at 5:28 AM, Ian Campbell ian.campb...@citrix.com wrote:
 In your list do the options which come under XEN or XEN_FRONTEND depend
 on the respective headline config option?

An indentation reflects a dependency on the above option.

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Xen's Linux kernel config options v3

This is a third respin for a design proposal for a rework on the config options
on the Linux kernel related to Xen. The frist two proposals came from Juergen,
I'm taking on the work now as some other work I am doing is related to this.
This third iteration addresses the feedback given on Juergen's last v2
proposal. Let me know if there are any questions or any further feedback before
we start addressing the changes.

Reasons to consider a cleanup / reorganizing of the kconfig options:

- Everything depends on Xen but that's obviously not right. For instance
  we want to be able to build Xen frontend drivers for HVM domains without
  the need for choosing a pvops kernel: currently the frontend drivers need
  Xen configured which depends on PARAVIRT.
- XEN should not depend on PAE, we can have HVM guests without PAE.
- Some features are available for x86 only, in spite of these not being
  architecture specific, e.g. XEN_DEBUG_FS
- Be able to build a Dom0 using XEN_PVH(x86) without having to configure
  XEN_HAVE_PVMMU(x86).

Current Xen related config options are as follows:

Legend:

- The first column are the Xen config options. Indentation in this
  column reflects the dependency between those options (e.g.
  XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
  XEN_DOM0, which depends on XEN).
- The second column shows the options which are selected automatically
  if the corresponding option in the first column is configured.
- The last column shows additional dependencies which can't be shown via
  the indentation level of the first column.
- Some options or dependencies are architecture specific, they are
  listed with the architecture requirements in parens (e.g. XEN_TMEM(x86)
  which is available for x86 only).
- Non-Xen options are mentioned only if they seem to be really relevant,
  like e.g. PARAVIRT or BROKEN.
- All listed options are user selectable, options which are not user selectable 
but
  automatic are prefixed with a '*' on the left hand side to make emphasis

Option  Selects Depends
-
XEN PARAVIRT_CLOCK(x86) PARAVIRT(x86)
XEN_HAVE_PVMMU(x86)
SWIOTLB_XEN(arm,arm64)
  PCI_XEN(x86)  SWIOTLB_XEN
  XEN_DOM0  PCI_XEN(x86)
XEN_BACKEND
  XEN_BLKDEV_BACKEND
  XEN_PCIDEV_BACKEND(x86)
  XEN_SCSI_BACKEND
  XEN_NETDEV_BACKEND
XEN_ACPI_HOTPLUG_MEMORY XEN_STUB
XEN_ACPI_HOTPLUG_CPUXEN_STUB
XEN_MCE_LOG(x86)
  XEN_ACPI_PROCESSOR(x86)   ACPI_PROCESSOR
CPU_FREQ
  XEN_PVHVM(x86)
XEN_PVH(x86)
  XEN_MAX_DOMAIN_MEMORY(x86)
  XEN_SAVE_RESTORE(x86)
  XEN_DEBUG_FS(x86)
  XEN_FBDEV_FRONTENDXEN_XENBUS_FRONTEND
INPUT_XEN_KBDDEV_FRONTEND
  XEN_BLKDEV_FRONTEND   XEN_XENBUS_FRONTEND
  HVC_XEN
HVC_XEN_FRONTENDXEN_XENBUS_FRONTEND
  TCG_XEN   XEN_XENBUS_FRONTEND
  XEN_PCIDEV_FRONTEND   PCI_XEN
XEN_XENBUS_FRONTEND
  XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND
  INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND
  XEN_WDT
  XEN_BALLOON
XEN_SELFBALLOONING  XEN_TMEM
XEN_BALLOON_MEMORY_HOTPLUG
XEN_SCRUB_PAGES
  XEN_DEV_EVTCHN
  XENFS XEN_PRIVCMD
XEN_COMPAT_XENFS
  XEN_SYS_HYPERVISOR
  XEN_XENBUS_FRONTEND
  XEN_GNTDEV
  XEN_GRANT_DEV_ALLOC
  SWIOTLB_XEN
  XEN_TMEM(x86)
  XEN_PRIVCMD
  XEN_STUB(x86_64)  BROKEN
  XEN_ACPI_PROCESSOR(x86)
  XEN_HAVE_PVMMU
  XEN_EFI(x64)
  XEN_NETDEV_FRONTEND   XEN_XENBUS_FRONTEND

After some feedback for the first draft I'd suggest the following:

Option  Selects Depends
--
XEN
  XEN_PV(x86)   XEN_HAVE_PVMMU(x86)
PARAVIRT
PARAVIRT_CLOCK
  XEN_PVH(x86)  XEN_PVHVM
PARAVIRT
PARAVIRT_CLOCK
  XEN_PVHVM(x86)PARAVIRT
PARAVIRT_CLOCK
  XEN_BACKEND   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
XEN_PVH(x86) ||
XEN_PVHVM(x86)
XEN_TMEM(x86)
XEN_PRIVCMD
XEN_BLKDEV_BACKEND
XEN_PCIDEV_BACKEND(x86)
XEN_SCSI_BACKEND
XEN_NETDEV_BACKEND
  PCI_XEN(x86)  SWIOTLB_XEN
  XEN_DOM0

Re: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig

On Mon, Feb 2, 2015 at 1:32 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
 On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek mma...@suse.cz wrote:
 Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
 On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek mma...@suse.cz wrote:
 On 2015-01-29 21:47, Paul Bolle wrote:
 [Added Michal. Removed Yann.]

 On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote:
 On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com 
 wrote:
 On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
 On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
 On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@suse.com

 This v3 addresses Stefano's feedback from the v2 series, namely
 moving PCI stuff to x86 as its all x86 specific and also just
 removing the CONFIG_TCG_XEN=m from the general config. To be
 clear the changes from the v2 series are below.

 Luis R. Rodriguez (2):
   x86, platform, xen, kconfig: clarify kvmconfig is for kvm
   x86, arm, platform, xen, kconfig: add xen defconfig helper

  arch/x86/configs/xen.config | 10 ++
  kernel/configs/xen.config   | 26 ++
  scripts/kconfig/Makefile|  7 ++-
  3 files changed, 42 insertions(+), 1 deletion(-)
  create mode 100644 arch/x86/configs/xen.config
  create mode 100644 kernel/configs/xen.config

 Who could these changes go through?

 I would be OK with taking it in the Xen tree, but I would feel more
 comfortable doing that if you had an ack from Yann Morin (CC'ed).

 *Poke*

 Hey Yann, wondering if you had any feedback. Thanks.

 Yann has disappeared a year ago. Michal now, informally, keeps an eye on
 kconfig related patches.

 I did not see this. Can you please bounce me the original series?

 Done, let me know if you did not get them

 I got them, sorry for the delay. You can add Acked-by: Michal Marek
 mma...@suse.cz if you want.

 Thanks Michal, what tree should this go through though?

David should this go through your tree? Can anyone provide pointers?

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.10 test] 34210: regressions - FAIL

flight 34210 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34210/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install  fail pass in 34094
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 34094 pass 
in 34210

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 
fail blocked in 26303
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail   like 26303
 test-amd64-i386-libvirt   9 guest-start   fail in 34094 like 26303
 test-amd64-amd64-libvirt  9 guest-start   fail in 34094 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-armhf-armhf-xl-sedf-pin  5 xen-boot fail   never pass
 test-armhf-armhf-xl-midway5 xen-boot fail   never pass
 test-armhf-armhf-xl-sedf  5 xen-boot fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  5 xen-boot fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail in 34094 never pass

version targeted for testing:
 linux4227cffc1f9e4a9241071354476c225705b614c8
baseline version:
 linuxbe67db109090b17b56eb8eb2190cd70700f107aa


879 people touched revisions under test,
not listing them all


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64

Re: [Xen-devel] Xen's Linux kernel config options V2

On Fri, Feb 6, 2015 at 4:07 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Thu, 5 Feb 2015, Luis R. Rodriguez wrote:
 On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  On Wed, 4 Feb 2015, David Vrabel wrote:
  On 16/12/14 16:21, Juergen Gross wrote:
   Hi,
  
   This is a design proposal for a rework of the config options on the
   Linux kernel which are related to Xen.
  
   The need to do so arose from the fact that it is currently not
   possible to build the Xen frontend drivers for a non-pvops kernel,
   e.g. to run them in a HVM-domain. There are more drawbacks in the
   current config options to which I'll come later.
  
   Option  Selects Depends
   --
   XEN
 XEN_PV(x86)   XEN_HAVE_PVMMU
   PARAVIRT
   PARAVIRT_CLOCK
 XEN_PVH(x86)  XEN_PVHVM
   PARAVIRT
   PARAVIRT_CLOCK
 XEN_PVHVM PARAVIRT
   PARAVIRT_CLOCK
 
  PARAVIRT_CLOCK and PARAVIRT are x86 specific.
  Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
  arm and arm64 as there is just one type of guest, I would rather just
  have CONFIG_XEN there.

 Interesting, right now we have as part of the recommended change for
 XEN_BACKEND:

 Option  Selects Depends
 --
 XEN
   XEN_BACKEND   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
 XEN_PVH(x86) ||
 XEN_PVHVM

 How would we ensure to enable XEN_BACKEND for arm then?

 I thought that you wanted to turn XEN_BACKEND into a user selectable
 option.  On arm and arm64 this option wouldn't depend on anything
 (except CONFIG_XEN).

OK sure, that maps to this dependency list then:

ARM || ARM64 || ( X86  (XEN_PV || XEN_PVH || XEN_PVHVM )

 XEN_BACKEND   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
   XEN_PVH(x86) ||
   XEN_PVHVM
   XEN_BLKDEV_BACKEND
   XEN_PCIDEV_BACKEND(x86)
   XEN_SCSI_BACKEND
   XEN_NETDEV_BACKEND
 PCI_XEN(x86)  SWIOTLB_XEN
 XEN_DOM0  XEN_BACKEND XEN_PV(x86) ||
   PCI_XEN(x86)XEN_PVH(x86)
   XEN_ACPI_HOTPLUG_MEMORY XEN_STUB
   XEN_ACPI_HOTPLUG_CPUXEN_STUB
   XEN_MCE_LOG(x86)
 XEN_MAX_DOMAIN_MEMORY(x86)
 XEN_SAVE_RESTORE(x86)
 XEN_DEBUG_FS
 XEN_WDT
 XEN_BALLOON
   XEN_SELFBALLOONING  XEN_TMEM
   XEN_BALLOON_MEMORY_HOTPLUG
   XEN_SCRUB_PAGES
 XENFS XEN_PRIVCMD
   XEN_COMPAT_XENFS
 XEN_SYS_HYPERVISOR
 XEN_DEV_EVTCHN
 XEN_GNTDEV
 XEN_GRANT_DEV_ALLOC
 SWIOTLB_XEN
 XEN_TMEM
 
  not available on arm and arm64

 Can you clarify if you meant only XEN_TMEM or all the above here?

 Only TMEM, sorry for being terse

That was listed as one of the example Kconfig entries which are
currently not available on other architectures despite not being
architecture specific, the other one being XEN_DEBUG_FS. So to be
clear -- do we not want XEN_TMEM for arm in the future ?

 XEN_PRIVCMD
 XEN_STUB(x86_64)  BROKEN
 XEN_ACPI_PROCESSOR(x86)
 XEN_HAVE_PVMMU
 
  x86 specific

 Likewise, all of the above quoted options ?

 only XEN_HAVE_PVMMU

Updated.

 XEN_EFI(x64)
 
  FYI soon to be available on arm

 OK thanks.

 XEN_XENBUS_FRONTEND
   XEN_FRONTENDXEN
   XEN_XENBUS_FRONTEND
 XEN_FBDEV_FRONTENDINPUT_XEN_KBDDEV_FRONTEND
 XEN_BLKDEV_FRONTEND
 HVC_XEN_FRONTEND  HVC_XEN
 TCG_XEN
 XEN_PCIDEV_FRONTEND   PCI_XEN
 
  x86 specific for the moment

 All?

 XEN_PCIDEV_FRONTEND and PCI_XEN

Updated.

 XEN_SCSI_FRONTEND
 INPUT_XEN_KBDDEV_FRONTEND
 XEN_NETDEV_FRONTEND
 XEN_PLATFORM_PCI
 
  definitely x86 only

 All?

 only XEN_PLATFORM_PCI

Updated.

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

2015-02-06 Thread Davidlohr Bueso

On Fri, 2015-02-06 at 16:15 -0500, Sasha Levin wrote:
 On 02/06/2015 02:42 PM, Davidlohr Bueso wrote:
  On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
  On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
  raghavendra...@linux.vnet.ibm.com wrote:
  Paravirt spinlock clears slowpath flag after doing unlock.
  [ fix edited out ]
 
  So I'm not going to be applying this for 3.19, because it's much too
  late and the patch is too scary. Plus the bug probably effectively
  never shows up in real life (it is probably easy to trigger the
  speculative *read* but probably never the actual speculative write
  after dropping the lock last).
 
  This will need a lot of testing by the paravirt people - both
  performance and correctness. So *maybe* for 3.20, but maybe for even
  later, and then marked for stable, of course.
 
  Are there any good paravirt stress-tests that people could run for
  extended times?
  
  locktorture inside a VM should give a proper pounding.
 
 Would it catch lifetime issues too? I thought it just tests out correctness.

Given enough contention it should, yeah. The spinlock can be acquired by
another thread right after releasing the lock in the unlock's slowpath.
And all locktorture does is pound on locks with random hold times.

Thanks,
Davidlohr


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen's Linux kernel config options V2

On Mon, Jan 19, 2015 at 5:28 AM, Ian Campbell ian.campb...@citrix.com wrote:
 Could you annotate (maybe not a new column, perhaps with a * or
 something) which options are supposed to be user-visible vs purely
 internal things which can be selected?

All options listed will be user selectable unless otherwise noted with
a (*) in the next iteration.

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 34196: regressions - FAIL

flight 34196 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34196/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 33686
 test-amd64-i386-libvirt   5 xen-boot  fail REGR. vs. 33686

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10fail REGR. vs. 33686

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail never pass

version targeted for testing:
 ovmf 0e40240230fe51cc1890ec90d6f602046a3d8a77
baseline version:
 ovmf 447d264115c476142f884af0be287622cd244423


People who touched revisions under test:
  Gao, Liming liming@intel.com
  Long, Qin qin.l...@intel.com
  Yao, Jiewen jiewen@intel.com
  Aaron Pop aar...@ami.com
  Abner Chang abner.ch...@hp.com
  Alex Williamson alex.william...@redhat.com
  Anderw Fish af...@apple.com
  Andrew Fish af...@apple.com
  Anthony PERARD anthony.per...@citrix.com
  Ard Biesheuvel ard.biesheu...@linaro.org
  Ari Zigler a...@mellanox.com
  Brendan Jackman brendan.jack...@arm.com
  Bruce Cran bruce.c...@gmail.com
  Cecil Sheng cecil.sh...@hp.com
  Chao Zhang chao.b.zh...@intel.com
  Chao, Zhang chao.b.zh...@intel.com
  Chen Fan chen.fan.f...@cn.fujitsu.com
  Chris Phillips chr...@hp.com
  Chris Ruffin chris.ruf...@intel.com
  Cinnamon Shia cinnamon.s...@hp.com
  Daryl McDaniel  daryl.mcdan...@intel.com
  Daryl McDaniel daryl.mcdan...@intel.com
  daryl.mcdaniel daryl.mcdan...@intel.com
  daryl.mcdan...@intel.com
  darylm503 darylm503@Edk2
  David Wei david@intel.com
  David Woodhouse david.woodho...@intel.com
  Deric Cole deric_c...@phoenix.com
  Dong Eric eric.d...@intel.com
  Dong Guo guo.d...@intel.com
  Dong, Guo guo.d...@intel.com
  Elvin Li elvin...@intel.com
  Eric Dong eric.d...@intel.com
  Eugene Cohen eug...@hp.com
  Feng Tian feng.t...@intel.com
  Feng, Bob C bob.c.f...@intel.com
  Fu Siyuan siyuan...@intel.com
  Fu, Siyuan siyuan...@intel.com
  Gabriel Somlo so...@cmu.edu
  Gao, Liming liming@intel.com
  Gao, Liming liming.gao Gao, Liming liming@intel.com
  Gao, Liming liming@intel.com
  Garrett Kirkendall garrett.kirkend...@amd.com
  Gary Lin g...@suse.com
  Grzegorz Milos gm...@cam.ac.uk
  Hao Wu hao.a...@intel.com
  Harry Liebel harry.lie...@arm.com
  Hess Chen hesheng.c...@intel.com
  Hot Tian hot.t...@intel.com
  isakov-sl isakov...@bk.ru
  isakov...@bk.ru
  Jaben Carsey jaben.car...@intel.com
  jcarsey jcarsey
  jcarsey jcarsey@Edk2
  Jeff Bobzin (jeff.bobzin Jeff Bobzin (jeff.bob...@insyde.com)
  Jeff Bobzin (jeff.bob...@insyde.com)
  Jeff Fan jeff@intel.com
  Jiewen Yao jiewen@intel.com
  Joe Peterson joe.peter...@intel.com
  Jordan Justen jordan.l.jus...@intel.com
  jyao1 jyao1
  jyao1 jyao1@Edk2
  Kinney, Michael D michael.d.kin...@intel.com
  Larry Cleeton lclee...@microsoft.com
  Laszlo Ersek ler...@redhat.com
  Leandro G. Biss Becker lbec...@positivo.com.br
  Lee Leahy leroy.p.le...@intel.com
  Leif Lindholm leif.lindh...@linaro.org
  leroy.p.leahy leroy.p.le...@intel.com
  leroy.p.le...@intel.com
  lhauch larry.ha...@intel.com
  Li, Elvin elvin...@intel.com
  Liming Gao liming@intel.com
  Long Qin qin.l...@intel.com
  Long, Qin

Re: [Xen-devel] [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual sound

2015-02-06 Thread Oleksandr Dmytryshyn

Hi, Stefano.

Currently we have this configuration:
Dom0, DomD (driver domain), DomU (Android).
Sound driver is inside DomD. Backend uses ALSA for playback/capture.

On Thu, Feb 5, 2015 at 9:47 PM, Stefano Panella
stefano.pane...@citrix.com wrote:
 Hi all,

 First of all I would like to say that:
 - I am happy that PV audio is finding its way into xen and there is active 
 development on it
 - Defining a flexible and future proof PV audio protocol is very hard and 
 will probably take a bit of trial and error in the beginning.
 - I hope I will be able to save some time in the trial and error process 
 sharing a bit of my xen audio related experiences.

 I had a look at the patches sent and even if I am sure they are solving in a 
 practical way a specific use case scenario, the protocol specified does not 
 look general enough in my opinion and it does many assumptions which might or 
 not be acceptable.

 Also I could not find any discussion around the actual design of the protocol 
 including motivations and scope.

 I would like to think one could break the design protocol of a PV driver in 
 different areas where different people can contribute at different levels 
 bringing their particular expertise.

 Anyway, first it would be good to start a discussion around some basic 
 questions and then we could go into more detail.

 - what is the aim of the protocol? Just pipe some sort of sound data from 
 guest and dom0 or expose the guest with a real xen PV soundcard?
The aim is to expose the guest with a real xen PV soundcard.

 - how general/granular/configurable should it be in term of the potentially 
 many and different sound devices present in dom0?
Each sound device in DomD has own name and it is mapped to the selected
sound device of the PV soundcard in the frontend. I'll little rework the stream
mappings description in this protocol in the next patch-set.

 - audio, differently from any other Xen PV driver, is a real-time thing, 
 should this be reflected in the protocol? Most sound driver API require to 
 know when a particular sound sample is played on the Speaker or how old is a 
 sample coming from a Mic (particularly useful for Acoustic Echo Cancellation)
I don't know exactly how reflect it in the protocol. My PV driver adds
additional latency which is comparable to the context switching.

 - Should the protocol allow the backend to publish many capabilities so the 
 frontend can chose how to best use them?
Yes, it should. Maybe this should be added a bit later to the protocol.
At first it will be simple version of the protocol description.

 - how easy/feasible would be to write frontend and backend drivers using the 
 protocol for different OSs?
It is feasible to write backend and frontend drivers.
The main work should be done:
1. Learn how use ALSA to play/capture data (if ALSA is used for backend driver)
2. Learn how to create and use an virtual soundcard in selected OS
(linux, unix, etc.)
3. Learn how use an event channel and shared memory.

 - would the protocol map well with the current major sound driver models and 
 API for the different guest Oss? (linux alsa driver, Windows WaveCiclic or 
 WaveRT etc..)
At least the protocol map would be well with the alsa-like drivers
(Linux, QNX). BTW we've written a test version of the PV sound frontend
which works on the QNX. Unfurtunatelly I don't know about Windows WaveCiclic


 I hope these questions will help moving the conversation in a constructive 
 and productive way for now :)

 Stefano

 -Original Message-
 From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
 Sent: Monday, February 2, 2015 6:52 PM
 To: Oleksandr Dmytryshyn
 Cc: xen-devel@lists.xen.org; embedded-pv-de...@lists.xenproject.org; Iurii 
 Konovalenko; Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan 
 Beulich; Stefano Panella
 Subject: Re: [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual 
 sound

 On Thu, 2015-01-29 at 13:01 +0200, Oleksandr Dmytryshyn wrote:
 This is ABI for the two halves of a Para-virtual sound driver to
 communicate with each to other.

 I wonder whether Stefano (Cc-ed), which has a great deal of experience with 
 --real, virtual and paravirtual-- audio, could find a few minutes to have a 
 look and help us here, by saying what he thinks :-)

 Stefano, a bit of context (Oleksandr and Iurii, can add more, if needed, I'm 
 sure):

 http://marc.info/?l=xen-develm=142165575819173
 http://marc.info/?l=xen-develm=142194015107046

 Thanks and Regards,
 Dario

 --
 This happens because I choose it to happen! (Raistlin Majere)
 -
 Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software 
 Engineer, Citrix Systems RD Ltd., Cambridge (UK)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] xen: cleanup sysfs management

2015-02-06 Thread David Vrabel

On 05/02/15 20:38, Takashi Iwai wrote:
 Hi,
 
 this is a couple of patchset to clean up the sysfs entry creation /
 removal in xen driver codes.  They are relatively straightforward
 conversion patches, where manual function calls are replaced with
 static attribute groups.

These look fine but they're a bit late for 3.20.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 34181: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 
fail REGR. vs. 34137

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34137

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-stop   fail   never pass
 test-armhf-armhf-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass

version targeted for testing:
 xen  441256a532dd737905ce335506d2ffcf0ff0db7c
baseline version:
 xen  a1b4af132077de694054d757fea4573d482c8b3a


People who touched revisions under test:
  Andrew Cooper andrew.coop...@citrix.com
  Boris Ostrovsky boris.ostrov...@oracle.com
  Daniel De Graaf dgde...@tycho.nsa.gov
  Daniel Kiper daniel.ki...@oracle.com
  Ed White edmund.h.wh...@intel.com
  Ian Jackson ian.jack...@eu.citrix.com
  Jan Beulich jbeul...@suse.com
  Kevin Tian kevin.t...@intel.com
  Tim Deegan t...@xen.org
  Wei Liu wei.l...@citrix.com


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass

[Xen-devel] [PATCH v7] sndif: add ABI for Para-virtual sound

2015-02-06 Thread Oleksandr Dmytryshyn

This is ABI for the two halves of a Para-virtual
sound driver to communicate with each to other.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

Changes since v6:
 * Reworked streams description  in the Backend XenBus Nodes

 xen/include/public/io/sndif.h | 429 ++
 1 file changed, 429 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..0118cab
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,429 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * 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) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_XENSND_H__
+#define __XEN_PUBLIC_IO_XENSND_H__
+
+/*
+ * Front-back notifications: When enqueuing a new request, sending a
+ * notification can be made conditional on req_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
+ *
+ * Back-front notifications: When enqueuing a new response, sending a
+ * notification can be made conditional on rsp_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Frontends must set
+ * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
+ */
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Para-virtual sound card driver utilize nodes within the
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *- Backend Device parameters -
+ *
+ * devid
+ *  Values: uint32_t
+ *
+ *  Index of the soundcard which will be

[Xen-devel] pvSCSI test

2015-02-06 Thread Kristian Hagsted Rasmussen

On Wednesday, February 4, 2015 05:41, Juergen Gross jgr...@suse.com wrote:
 To: Kristian Hagsted Rasmussen; Olaf Hering; xen-de...@lists.xensource.com
 Subject: Re: pvSCSI test

 On 02/03/2015 07:16 PM, Kristian Hagsted Rasmussen wrote:

 Hi Olaf and Juergen

 I am interested in testing pvSCSI as I have a system were it would be ideal.
 I have tried to apply this patch 
 http://marc.info/?l=xen-develm=139885599019457w=2; called libbxl: add 
 support for pvscsi, iteration 1, to my xen-4.5 tree.
 I am using kernel 3.18.4 compiled with xen-scsiback and xen-scsifront 
 compiled into the kernel, for both Dom0 and DomU.

   My Ubuntu domU is running fine, however the scsi disk I want to pass 
 through does not appear.

 in my config I have added the line:
 vscsi= ['3:0:0:0,0:0:0:0']
 I have also tried with:
 vscsi= ['/dev/sdb,0:0:0:0']

 but no matter which syntax I use I get the following error in dmesg log:
 xen-pvscsi: 3:0:0:0 doesn't exist

 I have no errors in the log files for the domU.

 Am I missing something in my configuration, perhaps some device hiding like 
 for pci pass through?

 The upstream pvscsi backend is using the target infrastructure. Until
 the tools are aware of this you'll have to configure the device to
 pass to a domain in Dom0 e.g. via a script:

 #!/bin/bash
 # usage:
 # mkpvscsi device
 # e.g. mkpvscsi /dev/sr0

 DEV=$1

 gen_uuid()
 {
  cat /proc/sys/kernel/random/uuid | \
 awk '{print naa.6001405 substr($1,1,8) substr($1,10,1);}'
 }

 TARG=`gen_uuid`
 INIT=`gen_uuid`

 NODE=`lsscsi | awk '$(NF) == '$DEV'
 { print substr($1,2,length($1)-4); }'`
 NAME=`echo $NODE | sed 's/:/_/g'`

I used targetcli to create the pscsi target, so 
skipped from here

 modprobe configfs
 mount -t configfs configfs /sys/kernel/config
 modprobe xen-scsiback
 modprobe target_core_mod

to here 

 cd /sys/kernel/config/target

and here to 

 mkdir -p core/pscsi_0/$NAME
 echo $DEV core/pscsi_0/$NAME/udev_path

to here

 mkdir -p xen-pvscsi/$TARG/tpgt_0
 echo $NODE xen-pvscsi/$TARG/tpgt_0/param/alias
 echo $INIT xen-pvscsi/$TARG/tpgt_0/nexus
 mkdir xen-pvscsi/$TARG/tpgt_0/lun/lun_0

 cd xen-pvscsi/$TARG/tpgt_0/lun/lun_0
 ln -s ../../../../../../target/core/pscsi_0/$NAME xen-pvscsi_port

 -

 After doing this you can use the xen tools to give the device to a domU.
 Please note: this script is untested, I've used a simpler one which
 fitted my needs (using targetcli, which isn't available everywhere).
 I have tested all single steps of the script above, though.

Thanks for the script, I had some problems with the symlinking when
running the script, so tried to make the pscsi in targetcli, and then
shortening the script to skip all script lines concerning the core dir.
This made the script working for me, however I still get:
xen-pvscsi: 3:0:0:0 doesn't exist
error in dmesg log.

Are you using another patch for the xen-tree than the one I listed above?

Thanks Kristian

 Happy testing,

 Juergen

 P.S.: If you are feeling adventurous you can try other target backends
than pscsi, e.g. iscsi or fileio.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Development for Dummies.

2015-02-06 Thread Jason Long

Can you tell me why Ocaml used? What is the features of this language? Why not 
other?
Excuse me, I'm a beginner in programming and can you show me some books or 
reference step by step? I'm a dummies :(

Cheers.



On Thursday, February 5, 2015 11:59 PM, Pasi Kärkkäinen pa...@iki.fi wrote:
On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote:
 Hello Folks.
 I want to become a Xen developer and I don't have any knowledge about 
 development. Can you tell me what programming language is needed? How can I 
 start and etc?


Hello,

Xen is mostly written in C language, but there are other languages being used 
aswell.. obviously lowlevel assembly language for some architecture specific 
lowlevel stuff, and some highler level languages (OCaml) for certain components 
(oxenstored). Also various scripting languages are used, perl, python, etc. 

Also you need to know all the usual Linux/Unix commandline (development) tools.

-- Pasi


 
 Tnx.
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Development for Dummies.

2015-02-06 Thread Pasi Kärkkäinen

On Fri, Feb 06, 2015 at 10:31:09AM +, Jason Long wrote:
 Can you tell me why Ocaml used? What is the features of this language? Why 
 not other?
 Excuse me, I'm a beginner in programming and can you show me some books or 
 reference step by step? I'm a dummies :(


There are two different versions of xenstore-daemon (xenstored). 
The earlier one, written in C, and the newer one, written in OCaml (oxenstored).

Note that this is just one of the many components in Xen. Most Xen components 
are written in C.

Here you have some slides about oxenstored:
http://gazagnaire.org/pub/GH09.pdf


-- Pasi
 
 Cheers.
 
 
 
 On Thursday, February 5, 2015 11:59 PM, Pasi Kärkkäinen pa...@iki.fi wrote:
 On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote:
  Hello Folks.
  I want to become a Xen developer and I don't have any knowledge about 
  development. Can you tell me what programming language is needed? How can I 
  start and etc?
 
 
 Hello,
 
 Xen is mostly written in C language, but there are other languages being used 
 aswell.. obviously lowlevel assembly language for some architecture specific 
 lowlevel stuff, and some highler level languages (OCaml) for certain 
 components (oxenstored). Also various scripting languages are used, perl, 
 python, etc. 
 
 Also you need to know all the usual Linux/Unix commandline (development) 
 tools.
 
 -- Pasi
 
 
  
  Tnx.
  
  ___
  Xen-devel mailing list
  Xen-devel@lists.xen.org
  http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] drivers: xen/block: add multi-page ring support

2015-02-06 Thread Bob Liu


On 02/02/2015 06:43 PM, Roger Pau Monné wrote:
 El 23/01/15 a les 10.14, Bob Liu ha escrit:
 Extend xen/block to support multi-page ring.
  * xen-blkback notify blkfront with feature-multi-ring-pages
  * xen-blkfront write to xenstore about how many pages are used as the ring

 If using 4 pages as the ring, inflight requests inscreased from 32 to 128 and
 IOPS improved nearly 400% on our system.

 Signed-off-by: Bob Liu bob@oracle.com
 ---
  drivers/block/xen-blkback/xenbus.c |   86 +
  drivers/block/xen-blkfront.c   |   94 
 ++--
 
 This requires a patch to xen/include/public/io/blkif.h in the Xen
 repository describing how this protocol extension is going to work
 before reviewing the Linux implementation.
 

But there is no protocol change, just add an parameter max_ring_pages
to control how many pages can be used as the ring. Now with one page we
can only have 32 requests.

-- 
Regards,
-Bob

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 7/7] libxl: Wait for QEMU startup in stubdomain

Thanks for posting.

On Tue, Feb 03, 2015 at 11:06:15PM -0500, Eric Shelton wrote:
[...]
 @@ -1368,12 +1401,24 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
  libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(multidev, *sdss, 
 multidev);
  STATE_AO_GC(sdss-dm.spawn.ao);
  uint32_t dm_domid = sdss-pvqemu.guest_domid;
 +libxl__xswait_state *xswait = sdss-pvqemu.spawn.xswait;
  
  if (rc) {
  LOGE(ERROR, error connecting nics devices);
  goto out;
  }
  
 +/* wait for PV stubdom QEMU instance to be ready */
 +libxl__xswait_init(xswait);
 +xswait-ao = sdss-dm.spawn.ao;
 +xswait-what = GCSPRINTF(stub domain %d startup, dm_domid);
 +xswait-path = GCSPRINTF(/local/domain/0/device-model/%d/state,
 + sdss-dm.guest_domid);

FWIW  we are now experiencing problem with this startup protocol (not
Linux stubdom specific) -- that path that libxl waiting for is wrong.

Unfortunately this problem can't be solved without putting in
significant effort and time (involves redesign of protocol and handle
all the compatibility issues). We can't say for sure when the solution
is going to land.

Also upstream QEMU stubdom, as you already notice, doesn't have a
critical functionality -- save / restore. Adding that in might involve
upstreaming some changes to QEMU, which has a time frame that is out of
our control.  So my hunch is that we're not going to make it in time for
4.6. :-/

Wei.

 +xswait-timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
 +xswait-callback = stub_dm_watch_event;
 +rc = libxl__xswait_start(gc, xswait);
 +if (rc) goto out;
 +
  rc = libxl_domain_unpause(CTX, dm_domid);
  if (rc) goto out;
  
 @@ -1387,7 +1432,6 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
  return;
  }
  }
 -sdss-callback(egc, sdss-dm, rc);
  }
  
  static void spawn_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
 -- 
 1.8.5.5
 
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] xen: cleanup sysfs management

2015-02-06 Thread Takashi Iwai

At Fri, 6 Feb 2015 10:43:44 +,
David Vrabel wrote:
 
 On 05/02/15 20:38, Takashi Iwai wrote:
  Hi,
  
  this is a couple of patchset to clean up the sysfs entry creation /
  removal in xen driver codes.  They are relatively straightforward
  conversion patches, where manual function calls are replaced with
  static attribute groups.
 
 These look fine but they're a bit late for 3.20.

Yeah, feel free to postpone to 3.21 (as long as they aren't lost :)
These are just non-urgent cleanups I happened to find through the
whole tree.


Takashi

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE [and 1 more messages]

Jan Beulich writes (Re: [PATCH] tools: work around collision of -O0 and 
-D_FORTIFY_SOURCE):
 Attached the patch I used for testing. While it works okay for me,
 I guess the configure part will need further taking care of the
 -Wp,-D... variant Don is seeing.

Thanks.  I'm going to pretend my first one was v2, you called your
version v3 and will send out a v4 in just a moment.

Don, can you please test it ?

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvSCSI test

2015-02-06 Thread Juergen Gross

On 02/06/2015 10:32 AM, Kristian Hagsted Rasmussen wrote:

On Wednesday, February 4, 2015 05:41, Juergen Gross jgr...@suse.com wrote:

To: Kristian Hagsted Rasmussen; Olaf Hering; xen-de...@lists.xensource.com
Subject: Re: pvSCSI test

On 02/03/2015 07:16 PM, Kristian Hagsted Rasmussen wrote:

Hi Olaf and Juergen

I am interested in testing pvSCSI as I have a system were it would be ideal.
I have tried to apply this patch http://marc.info/?l=xen-develm=139885599019457w=2; 
called libbxl: add support for pvscsi, iteration 1, to my xen-4.5 tree.
I am using kernel 3.18.4 compiled with xen-scsiback and xen-scsifront compiled 
into the kernel, for both Dom0 and DomU.

   My Ubuntu domU is running fine, however the scsi disk I want to pass through 
does not appear.

in my config I have added the line:
vscsi= ['3:0:0:0,0:0:0:0']
I have also tried with:
vscsi= ['/dev/sdb,0:0:0:0']

but no matter which syntax I use I get the following error in dmesg log:
xen-pvscsi: 3:0:0:0 doesn't exist

I have no errors in the log files for the domU.

Am I missing something in my configuration, perhaps some device hiding like for 
pci pass through?

The upstream pvscsi backend is using the target infrastructure. Until
the tools are aware of this you'll have to configure the device to
pass to a domain in Dom0 e.g. via a script:

#!/bin/bash
# usage:
# mkpvscsi device
# e.g. mkpvscsi /dev/sr0

DEV=$1

gen_uuid()
{
  cat /proc/sys/kernel/random/uuid | \
 awk '{print naa.6001405 substr($1,1,8) substr($1,10,1);}'
}

TARG=`gen_uuid`
INIT=`gen_uuid`

NODE=`lsscsi | awk '$(NF) == '$DEV'
 { print substr($1,2,length($1)-4); }'`
NAME=`echo $NODE | sed 's/:/_/g'`

I used targetcli to create the pscsi target, so
skipped from here

modprobe configfs
mount -t configfs configfs /sys/kernel/config
modprobe xen-scsiback
modprobe target_core_mod

to here

cd /sys/kernel/config/target

and here to

mkdir -p core/pscsi_0/$NAME
echo $DEV core/pscsi_0/$NAME/udev_path

to here

mkdir -p xen-pvscsi/$TARG/tpgt_0
echo $NODE xen-pvscsi/$TARG/tpgt_0/param/alias
echo $INIT xen-pvscsi/$TARG/tpgt_0/nexus
mkdir xen-pvscsi/$TARG/tpgt_0/lun/lun_0

cd xen-pvscsi/$TARG/tpgt_0/lun/lun_0
ln -s ../../../../../../target/core/pscsi_0/$NAME xen-pvscsi_port

-

After doing this you can use the xen tools to give the device to a domU.
Please note: this script is untested, I've used a simpler one which
fitted my needs (using targetcli, which isn't available everywhere).
I have tested all single steps of the script above, though.

Thanks for the script, I had some problems with the symlinking when
running the script, so tried to make the pscsi in targetcli, and then
shortening the script to skip all script lines concerning the core dir.
This made the script working for me, however I still get:
xen-pvscsi: 3:0:0:0 doesn't exist
error in dmesg log.

Are you using another patch for the xen-tree than the one I listed above?

I've used xm to get the drivers working, not xl. I wanted to have only
one changed component during tests in order to know which component is
failing. :-)

What are the contents of

/sys/kernel/config/target/xen-pvscsi/$TARG/tpgt_0/param/alias

($TARG replaced by the UUID generated above, of course)?

This should be 3:0:0:0 in your case. That's where the backend is
looking for the match from xenstore.

And the final symlink in the script is required. $NAME can be anything,
but has to match the pscsi name, of course.

Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xenbus_client: extend interface to suppurt multi-page ring