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

[osstest service owner]

flight 94590 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94590/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 94588
 build-amd64   5 xen-build fail REGR. vs. 94588
 build-amd64-xsm   5 xen-build fail REGR. vs. 94588
 build-i3865 xen-build fail REGR. vs. 94588

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf 2be45bfe2779043bc3566e879e7ec279412012dc
baseline version:
 ovmf 1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb

Last test of basis94588  2016-05-20 01:14:27 Z0 days
Testing same since94590  2016-05-20 03:46:31 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Not pushing.


commit 2be45bfe2779043bc3566e879e7ec279412012dc
Author: Fu Siyuan 
Date:   Fri May 6 10:30:09 2016 +0800

ShellPkg: Add argument to set block size for tftp command.

TFTP block size has a big impact on the transmit performance, this patch is 
to
add new argument [-s ] for shell "tftp" command to configure the
block size for file download.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Reviewed-by: Qiu Shumin 
Reviewed-by: Jaben Carsey 

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94587: trouble: blocked/broken

[osstest service owner]

flight 94587 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94587/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  103 days
Testing same since93977  2016-05-10 11:09:16 Z9 days   26 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [qemu-mainline test] 94586: tolerable FAIL - PUSHED

[osstest service owner]

flight 94586 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94586/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94554
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94554

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu6bd8ab6889f45a42d69a3a65a4d6e7fc2453c84c
baseline version:
 qemuua257c741491ff1c3c192d13a89c136dd6401c54d

Last test of basis94554  2016-05-18 14:32:38 Z1 days
Failing since 94577  2016-05-19 09:49:45 Z0 days2 attempts
Testing same since94586  2016-05-19 21:15:40 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Cao jin 
  Cornelia Huck 
  Denis V. Lunev 
  Eric Blake 
  Greg Kurz 
  John Snow 
  Kevin Wolf 
  Max Filippov 
  Max Reitz 
  Michael Tokarev 
  Paolo Bonzini 
  Peter Maydell 
  Peter Xu 
  Stefan Hajnoczi 
  Stefan Weil 
  Wei Jiangang 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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-pvops   

[Xen-devel] [ovmf test] 94588: all pass - PUSHED

[osstest service owner]

flight 94588 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94588/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb
baseline version:
 ovmf 4be1fbc287a2972a0cb420bc3a85372426c588b5

Last test of basis94583  2016-05-19 17:43:11 Z0 days
Testing same since94588  2016-05-20 01:14:27 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=ovmf
+ revision=1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb
+ branch=ovmf
+ revision=1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

[Xen-devel] [qemu-upstream-4.3-testing test] 94584: trouble: blocked/broken

[osstest service owner]

flight 94584 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94584/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  103 days
Testing same since93977  2016-05-10 11:09:16 Z9 days   25 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

[Wei Liu]

On Thu, May 19, 2016 at 11:54:55PM +0300, Andrii Anisov wrote:
> Wei,
> 
> Actually it should be the oldest patch in our current series, it was
> initial researches, I tried to fit the dom0 system rootfs into
> smallest possible initramfs so lean busybox was there.
> 
> >> +#trap sigerr ERR
> > > -trap sigerr ERR
> >
> > I know why you want to comment this out but you basically break the
> > error handling protocol. See the fatal function at the beginning of this
> > file.
> And yes we should check this particular line change carefully 'cause
> it was not intelligent adjusting to busybox, just getting rid of nasty
> issue.
> 
> > And you should probably fix your own environment, too.
> I'm not sure I got the point. If we are speaking about our system we
> are tied to this
> http://processors.wiki.ti.com/index.php/Category:GLSDK in dom0. I
> doubt it will be accepted by customer switching to any rich shell.
> 

What I mean is this patch changes (breaks?) error reporting protocol so
your deployment might not function as you expect. And that's something
you need to worry about for your customer.

My bottom line is the error reporting mechanism needs to be preserved,
otherwise we risk breaking other users. Libxl currently relies on those
nodes to report error.

Wei.

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

[Xen-devel] [ovmf test] 94583: all pass - PUSHED

[osstest service owner]

flight 94583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94583/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 4be1fbc287a2972a0cb420bc3a85372426c588b5
baseline version:
 ovmf 758ea94651545896309725b53407e57e79477f28

Last test of basis94575  2016-05-19 06:44:31 Z0 days
Testing same since94583  2016-05-19 17:43:11 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Michael Kinney 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=ovmf
+ revision=4be1fbc287a2972a0cb420bc3a85372426c588b5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
4be1fbc287a2972a0cb420bc3a85372426c588b5
+ branch=ovmf
+ revision=4be1fbc287a2972a0cb420bc3a85372426c588b5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x4be1fbc287a2972a0cb420bc3a85372426c588b5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

Julien,

>>We need to understand the use case and see if it is possible to generalize
>>it for everyone.

Well, the thing I would generalize is an understanding that real chips
(automotive IVI, mobile) have no or has limited SMMU functionality.

For a limited SMMU functionality I would name Renesas RCAR H2 chip -
it has its own IPMMU instead of SMMU. It is claimed that IPMMU
implemets VMSAv7. But no VMSAv7 VE are supported by that IPMMU in
fact.

The most outstanding example is a chip with Cortex A15 MPCore, but
without any VE support at all.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

Meng,

>> If the board is not supported by Xen, can we say Xen will support the
>> board with the warkaround?

I would not say boards are supported by XEN (except earlyprintk).
Rather architectures are supported in general, and SoC's are supported
in architecture implementation defined deviations (i.e. SMMU absence).

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

All,

See the system details I can reveal below:

   - There are two OS in the system Linux(Dom0) and Android(DomU)
   - Android provides almost all infotainment functionality. Linux covers
   functionality with higher reliability requirements and backup in case if
   Android crashes/glitches.
   - Linux (Dom0) handles all HW except GPU.
   - Android (DomD) runs with number of PV drivers, has an exclusive access
   to GPU.
   - The system has 2Gb(-16MB due to errata) RAM under 4GB, and a memory
   bank mapped over 4GB
   - Due to relatively small amount of dma-able memory both domains should
   have assigned RAM both from under 4GB and over 4GB spaces.
   - Several "data flow" mixing scenarios should be provided on Linux side
   I.e. controlling Android audio level, Android audio mute, mixing Android
   audio stream from stream generated by Linux. Same for Android displaying,
   events passing.
   - Domains should share HW codecs.

>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround?

The main limitation is that Jacinto6 lacks of SMMU. All transaction
initiators can address 32bit only, some initiators have no MMU and do not
support sg-lists (require buffers continuous in maddr).

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, May 19, 2016 at 2:00 PM, Julien Grall  wrote:
> Hello,
>
> On 18/05/16 20:17, Meng Xu wrote:
>>
>> On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
>>  wrote:
>>>
>>> This series RFC patches from the currently ongoing production project.
>>> This patch series presents changes needed to fit the system into
>>> customer requirements as well as workaround limitations of the
>>> Jacinto6 SoC.
>>
>>
>> IMHO, it will be better, if possible, to describe the exact customer
>> requirements this patch series tries to satisfy. I'm curious at what
>> the requirements are and if the requirements are general enough for
>> many other customers. :-)
>
>
> I agree with Meng here. We need to understand the use case and see if it
is
> possible to generalize it for everyone.
>
> I looked quickly at this patch series and noticed that most of patches
miss
> details on why it is necessary and what you are trying solve. Can you give
> us more details?
>
>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround? If the board is not supported by Xen, can we say Xen
>> will support the board with the warkaround?
>
>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

[Andrii Anisov]

Wei,

Actually it should be the oldest patch in our current series, it was
initial researches, I tried to fit the dom0 system rootfs into
smallest possible initramfs so lean busybox was there.

>> +#trap sigerr ERR
> > -trap sigerr ERR
>
> I know why you want to comment this out but you basically break the
> error handling protocol. See the fatal function at the beginning of this
> file.
And yes we should check this particular line change carefully 'cause
it was not intelligent adjusting to busybox, just getting rid of nasty
issue.

> And you should probably fix your own environment, too.
I'm not sure I got the point. If we are speaking about our system we
are tied to this
http://processors.wiki.ti.com/index.php/Category:GLSDK in dom0. I
doubt it will be accepted by customer switching to any rich shell.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

On Thu, May 19, 2016 at 2:34 PM, Wei Liu  wrote:
>
> On Wed, May 18, 2016 at 07:32:24PM +0300, Andrii Anisov wrote:
> > This patch makes virtual disks helper scripts be functional
> > in busybox environment. Actually we call sh insteand of bash and
> > rewrite loop with counter to be properly parsed by ash.
> >
> > Signed-off-by: Andrii Anisov 
> > Signed-off-by: Andrii Tseglytskyi 
> > ---
> >  tools/hotplug/Linux/block| 2 +-
> >  tools/hotplug/Linux/locking.sh   | 9 +++--
> >  tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
> >  3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
> > index 8d2ee9d..6a725db 100644
> > --- a/tools/hotplug/Linux/block
> > +++ b/tools/hotplug/Linux/block
> > @@ -1,4 +1,4 @@
> > -#!/bin/bash
> > +#!/bin/sh
> >
> >  dir=$(dirname "$0")
> >  . "$dir/block-common.sh"
> > diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
> > index c6a7e96..b8e9515 100644
> > --- a/tools/hotplug/Linux/locking.sh
> > +++ b/tools/hotplug/Linux/locking.sh
> > @@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
> >
> >  _setlockfd()
> >  {
> > +local lock_
> >  local i
> > -for ((i = 0; i < ${#_lockdict}; i++))
> > -do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> > +let i=0
> > +
> > +for lock_ in _lockdict ;
> > +do
> > +[ -z "$lock_" -o "$lock_" = "$1" ] && break
> > +(( i++ ))
> >  done
> >  _lockdict[$i]="$1"
> >  let _lockfd=200+i
> > diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in 
> > b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > index d5d0b69..42e46e3 100644
> > --- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > +++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > @@ -51,7 +51,7 @@ sigerr() {
> >fatal "$0 failed; error detected."
> >  }
> >
>> +#trap sigerr ERR
> > -trap sigerr ERR
>
> I know why you want to comment this out but you basically break the
> error handling protocol. See the fatal function at the beginning of this
> file.
>
> So we can't take this patch. And you should probably fix your own
> environment, too.
>
> Wei.
>
> >
> >
> >  ##
> > --
> > 2.8.2
> >
> >
> > ___
> > 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] [qemu-mainline test] 94577: trouble: broken/fail/pass

[osstest service owner]

flight 94577 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94577/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  3 host-install(3) broken REGR. vs. 94554

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94554
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 94554
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94554

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu8ec4fe0a4bed4fa27e6f28a746bcf77b27cd05a3
baseline version:
 qemuua257c741491ff1c3c192d13a89c136dd6401c54d

Last test of basis94554  2016-05-18 14:32:38 Z1 days
Testing same since94577  2016-05-19 09:49:45 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Cao jin 
  Greg Kurz 
  Michael Tokarev 
  Peter Maydell 
  Peter Xu 
  Stefan Weil 
  Wei Jiangang 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl  

Re: [Xen-devel] [PATCH] AMD IOMMU: Introduce support for IVHD block type 11h

[Suravee Suthikulpanit]

Hi Jan,

On 05/19/2016 04:09 AM, Jan Beulich wrote:

>>>+int __init amd_iommu_get_supported_ivhd_type(void)
>>>+{
>>>+if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
>>>+return -EPERM;

>>
>>This check appears out of the blue, and isn't being mentioned in
>>the description. Best would probably be to split it out, but at the
>>very least it needs to be (briefly) explained.

>
>This logic was actually duplicated from the
>amd_iommu_update_ivrs_mapping_acpi(). I believe this was added by the
>
>  commit 992fdf6f46252a459c6b1b8d971b2c71f01460f8
>  honor ACPI v4 FADT flags
>
>It might make more sense to pull this out to just check once in the
>amd_iommu_init() along with adding some explanation.

Does it actually need duplicating? I.e. doesn't the error that results
from amd_iommu_update_ivrs_mapping_acpi() (if the flag is clear)
not suffice?

Jan



No, it doesn't need duplicated. It was accidentally duplicated. 
Howerver, as you mentioned earlier, it probably should be moved to the 
beginning of amd_iommu_init() before any parsing of the IVRS table.


Suravee.

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

Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Konrad Rzeszutek Wilk]

On Thu, May 19, 2016 at 04:07:00PM +0100, Wei Liu wrote:
> On Thu, May 19, 2016 at 10:56:06AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
> > > On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> > > >> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded 
> > > >> \n in
> > > >> the signature checking paragraph.
> > > >>
> > > >>   /usr/bin/pandoc --number-sections --toc --standalone 
> > > >> misc/xsplice.markdown
> > > >> --output pdf/misc/xsplice.pdf
> > > >>   ! Undefined control sequence.
> > > >>   l.1085 appended\textasciitilde{}\n
> > > >>
> > > >> Surround the string in backticks to make it verbatim text.
> > > > Ok, where is that change?
> > > 
> > > > @@ -1007,46 +1007,46 @@ expecting such that it can properly do 
> > > > signature verification.
> > > >  
> > > >  The signature is based on the all of the payloads continuously laid out
> > > >  in memory. The signature is to be appended at the end of the ELF 
> > > > payload
> > > > -prefixed with the string '~Module signature appended~\n', followed by
> > > > +prefixed with the string `'~Module signature appended~\n'`, followed by
> > > >  an signature header then followed by the signature, key identifier, 
> > > > and signers
> > > >  name.
> > > 
> > > ^ Here.
> > 
> > Thank you!
> > > 
> > > >> While altering this file, strip the substantial quantity of trailing
> > > >> whitespace.
> > > > Please do not. That was added specifically there otherwise
> > > > markdown messes it up when doing HTML and the lines get mangled up.
> > > 
> > > Markdown isn't whitespace sensitive, so that really shouldn't be doing
> > > anything.  If you want a verbatim text block, indent it by 4 characters.
> > 
> > https://daringfireball.net/projects/markdown/syntax
> > 
> > "When you do want to insert a  break tag using Markdown, you end a
> > line with two or more spaces, then type return."
> > 
> > But if this can be done with indenting it with 4 characters that would
> > work too.
> > 
> 
> I take it you're happy with this change? Do you want to test it and
> report back?

No, this patch as is won't do.

The
'~Module signature appended~\n',
change to
`'~Module signature appended~\n'`,

Albeit part is good!

I can respin this patch with that simple change.
> 
> Wei.
> 
> > > 
> > > ~Andrew

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

Re: [Xen-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

Julien,

> Thank you for your series. For the next version, can you CC the relevant 
> maintainers using scripts/get_maintainer.pl for each patch?

We will take care to follow this rule further.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

[Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Meng Xu]

Hi all,

I'm trying to install two versions of Xen, say Xen 4.6 and Xen
4.7-unstable, onto the same machine. I want them to exist at the same
time, instead of letting one override the other.

I'm thinking about this because sometimes I want to try out someone
else's code which uses an older or newer version. But I also want to
keep my current version of Xen toolstack so that I won't need to
reinstall everything again later.

If I just use the following command, the new installation of the
toolstack will override the old version's toolstack. obviously:
$./configure
$make dist
$sudo make install
(Right now, I just have to recompile my code after I tried out someone
else's code that has a different version. I can keep two version of
Xen kernel and configure it in the grub2 entries. But I have to
reinstall the toolstack.)

My quick question is:
Does anyone try to install two version of Xen toolstack on the same machine?
Is there any documentation about the best practice to install two
versions of Xen onto the same machine?

---
I had a look at the ./configure's help. There are several options,
each of which can specify a specific path to install.
However, I'm not that sure if I should configure every option to make it work.

For example, it has --prefix and --exec-prefix to change the PREFIX
from /usr/local to user defined path. However, there is also --bindir
and --sbindir; I assume I should change it, should I? In addition,
should I specify the --libexecdir for the program executables?

I found one very old link at [1], but I doubt if it's still working
since Xen changes the toolstack a lot since Xen 4.1
http://old-list-archives.xenproject.org/xen-users/2009-09/msg00263.html

Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 0/6] Set of PV drivers used by production project

[Meng Xu]

Hi Lurii,

On Thu, May 19, 2016 at 10:37 AM, Iurii Mykhalskyi
 wrote:
> This patches introduce set of pv drivers interfaces.

Thank you very much for these pv drivers interfaces! It will be useful
for automotive applications, IMO.

However, I do have some questions:
I'm wondering how general the pv driver interfaces are?
Which types of ARM boards (I assume it's for ARM) can they be used?
What are the ARM boards you have tested on?
What are the production use case we are talking about here?

Are you or globallogic going to contribute the PV drivers as well? I'm
looking forward to the PV drivers as well. :-)

Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] [sun8i][H3] Question about running Xen on OrangePi PC

[bharat gohil]

Hello All,

I am trying to boot xen on OrangePi PC(based upon Allwinner H3). It is able
to boot on this target board but it hangs when it try to boot unmodified
linux guest(with xen configuration enable).

Please find following log for same.Can anyone guide me to debug this
problem(hang)?

Starting kernel
...


- UART enabled
-
- CPU  booting
-
- Xen starting in Hyp mode
-
- Zero BSS
-
- Setting up control registers
-
- Turning on paging
-
- Ready
-
(XEN) Checking for initrd in
/chosen
(XEN) RAM: 4000 -
7fff
(XEN)

(XEN) MODULE[0]: 7ec0 - 7ec04000 Device
Tree
(XEN) MODULE[1]: 7f60 - 7f955328 Kernel
console=hvc0 d
(XEN)  RESVD[0]: 7ffa1000 -
7ffa15e8
(XEN)  RESVD[1]: 7ec0 -
7ec04000
(XEN)

(XEN) Command line: console=dtuart dtuart=/soc@01c0/serial@01c28000
dom0_meM
(XEN) Placing Xen at
0x7fc0-0x7fe0
(XEN) Update BOOTMOD_XEN from 7ea0-7eb01701 =>
7fc01
(XEN) Xen heap: 7c00-7e00 (8192
pages)
(XEN) Dom heap: 253952
pages
(XEN) Domain heap
initialised
(XEN) Platform: Generic
System
(XEN) Looking for dtuart at "/soc@01c0/serial@01c28000", options
""
(XEN) Unable to find device "/soc@01c0/serial@01c28000"

(XEN) Bad console= option
'dtuart'
 Xen
4.6.2-pre
(XEN) Xen version 4.6.2-pre (bgohil@) (arm-eabi-gcc (Linaro GCC
5.3-2016.02) 5.6
(XEN) Latest ChangeSet: Tue Apr 26 12:07:49 2016 +0200
git:39546d1
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev
0x5
(XEN) 32-bit
Execution:
(XEN)   Processor Features:
1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE
Jazelle
(XEN) Extensions: GenericTimer
Security
(XEN)   Debug Features:
02010555
(XEN)   Auxiliary Features:

(XEN)   Memory Model Features: 10101105 4000 0124
02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142

(XEN) Using PSCI-0.1 for SMP
bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000
KHz
(XEN) GICv2
initialization:
(XEN)
gic_dist_addr=01c81000
(XEN)
gic_cpu_addr=01c82000
(XEN)
gic_hyp_addr=01c84000
(XEN)
gic_vcpu_addr=01c86000
(XEN)
gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 4 cpus, secure (IID
0100143b).
(XEN) Using scheduler: SMP Credit Scheduler
(credit)
(XEN) Allocated console ring of 32
KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev
0x5
(XEN) Bringing up
CPU1
- CPU 0001 booting
-
- Xen starting in Hyp mode
-
- Setting up control registers
-
- Turning on paging
-
- Ready
-
(XEN) CPU 1
booted.
(XEN) Bringing up
CPU2
- CPU 0002 booting
-
- Xen starting in Hyp mode
-
- Setting up control registers
-
- Turning on paging
-
- Ready
-
(XEN) CPU 2
booted.
(XEN) Bringing up
CPU3
- CPU 0003 booting
-
- Xen starting in Hyp mode
-
- Setting up control registers
-
- Turning on paging
-
- Ready
-
(XEN) CPU 3
booted.
(XEN) Brought up 4
CPUs
(XEN) P2M: 40-bit
IPA
(XEN) P2M: 3 levels with order-1 root, VTCR
0x80003558
(XEN) I/O virtualisation
disabled
(XEN) *** LOADING DOMAIN 0
***
(XEN) Loading kernel from boot module @
7f60
(XEN) Allocating 1:1 mappings totalling 128MB for
dom0:
(XEN) BANK[0] 0x007000-0x007800
(128MB)
(XEN) Grant table range:
0x007fc0-0x007fc61000
(XEN) Loading zImage from 7f60 to
77c0-77f55328
(XEN) Allocating PPI 16 for event channel
interrupt
(XEN) Loading dom0 DTB to
0x77a0-0x77a03cd0
(XEN) Scrubbing Free RAM on 1 nodes using 4
CPUs
(XEN)
..done.
(XEN) Initial low memory virq threshold set at 0x4000
pages.
(XEN) Std. Loglevel:
All
(XEN) Guest Loglevel:
All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xe)
(XEN) Freed 264kB init
memory.
(XEN) d0v0: vGICD: unhandled word write 0x to
ICACTIVER4
(XEN) traps.c:2447:d0v0 HSR=0x93840047 pc=0xc08170e8 gva=0xc8800384
gpa=0x04

-- 
Thanks,
Bharat Gohil
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86

[Stefano Stabellini]

On Thu, 19 May 2016, Stefano Stabellini wrote:
> On Thu, 19 May 2016, Juergen Gross wrote:
> > The pv_time_ops structure contains a function pointer for the
> > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> > uses its own mechanism to account for the "stolen" time a thread wasn't
> > able to run due to hypervisor scheduling.
> > 
> > Add support in Xen arch independent time handling for this feature by
> > moving it out of the arm arch into drivers/xen and remove the x86 Xen
> > hack.
> > 
> > Signed-off-by: Juergen Gross 
> > ---
> > V3: add #include  to avoid build error on arm
> > V2: remove the x86 do_stolen_accounting() hack
> > ---
> >  arch/arm/xen/enlighten.c| 17 ++---
> >  arch/x86/xen/time.c | 44 
> > ++--
> >  drivers/xen/time.c  | 20 
> >  include/linux/kernel_stat.h |  1 -
> >  include/xen/xen-ops.h   |  1 +
> >  kernel/sched/cputime.c  | 10 --
> >  6 files changed, 25 insertions(+), 68 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 75cd734..9163b94 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct 
> > *vma,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> >  
> > -static unsigned long long xen_stolen_accounting(int cpu)
> > -{
> > -   struct vcpu_runstate_info state;
> > -
> > -   BUG_ON(cpu != smp_processor_id());
> > -
> > -   xen_get_runstate_snapshot();
> > -
> > -   WARN_ON(state.state != RUNSTATE_running);
> > -
> > -   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> > -}
> > -
> >  static void xen_read_wallclock(struct timespec64 *ts)
> >  {
> > u32 version;
> > @@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
> >  
> > register_cpu_notifier(_cpu_notifier);
> >  
> > -   pv_time_ops.steal_clock = xen_stolen_accounting;
> > -   static_key_slow_inc(_steal_enabled);
> > +   xen_time_setup_guest();
> 
> You can remove
> 
> #include 
> 
> from headers now I believe

Sorry for the broken English. I meant: you can remove #include
 from the top of the file now I believe.


> 
> > if (xen_initial_domain())
> > pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
> >  
> > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> > index a0a4e55..6be31df 100644
> > --- a/arch/x86/xen/time.c
> > +++ b/arch/x86/xen/time.c
> > @@ -11,8 +11,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -31,44 +29,6 @@
> >  
> >  /* Xen may fire a timer up to this many ns early */
> >  #define TIMER_SLOP 10
> > -#define NS_PER_TICK(10LL / HZ)
> > -
> > -/* snapshots of runstate info */
> > -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
> > -
> > -/* unused ns of stolen time */
> > -static DEFINE_PER_CPU(u64, xen_residual_stolen);
> > -
> > -static void do_stolen_accounting(void)
> > -{
> > -   struct vcpu_runstate_info state;
> > -   struct vcpu_runstate_info *snap;
> > -   s64 runnable, offline, stolen;
> > -   cputime_t ticks;
> > -
> > -   xen_get_runstate_snapshot();
> > -
> > -   WARN_ON(state.state != RUNSTATE_running);
> > -
> > -   snap = this_cpu_ptr(_runstate_snapshot);
> > -
> > -   /* work out how much time the VCPU has not been runn*ing*  */
> > -   runnable = state.time[RUNSTATE_runnable] - 
> > snap->time[RUNSTATE_runnable];
> > -   offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
> > -
> > -   *snap = state;
> > -
> > -   /* Add the appropriate number of ticks of stolen time,
> > -  including any left-overs from last time. */
> > -   stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
> > -
> > -   if (stolen < 0)
> > -   stolen = 0;
> > -
> > -   ticks = iter_div_u64_rem(stolen, NS_PER_TICK, );
> > -   __this_cpu_write(xen_residual_stolen, stolen);
> > -   account_steal_ticks(ticks);
> > -}
> >  
> >  /* Get the TSC speed from Xen */
> >  static unsigned long xen_tsc_khz(void)
> > @@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
> > *dev_id)
> > ret = IRQ_HANDLED;
> > }
> >  
> > -   do_stolen_accounting();
> > -
> > return ret;
> >  }
> >  
> > @@ -431,6 +389,8 @@ static void __init xen_time_init(void)
> > xen_setup_timer(cpu);
> > xen_setup_cpu_clockevents();
> >  
> > +   xen_time_setup_guest();
> > +
> > if (xen_initial_domain())
> > pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
> >  }
> > diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> > index 7107842..2257b66 100644
> > --- a/drivers/xen/time.c
> > +++ b/drivers/xen/time.c
> > @@ -6,6 +6,7 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -75,6 +76,15 @@ bool 

Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86

[Stefano Stabellini]

On Thu, 19 May 2016, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
> 
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
> 
> Signed-off-by: Juergen Gross 
> ---
> V3: add #include  to avoid build error on arm
> V2: remove the x86 do_stolen_accounting() hack
> ---
>  arch/arm/xen/enlighten.c| 17 ++---
>  arch/x86/xen/time.c | 44 ++--
>  drivers/xen/time.c  | 20 
>  include/linux/kernel_stat.h |  1 -
>  include/xen/xen-ops.h   |  1 +
>  kernel/sched/cputime.c  | 10 --
>  6 files changed, 25 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd734..9163b94 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>  
> -static unsigned long long xen_stolen_accounting(int cpu)
> -{
> - struct vcpu_runstate_info state;
> -
> - BUG_ON(cpu != smp_processor_id());
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> -}
> -
>  static void xen_read_wallclock(struct timespec64 *ts)
>  {
>   u32 version;
> @@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
>  
>   register_cpu_notifier(_cpu_notifier);
>  
> - pv_time_ops.steal_clock = xen_stolen_accounting;
> - static_key_slow_inc(_steal_enabled);
> + xen_time_setup_guest();

You can remove

#include 

from headers now I believe



>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index a0a4e55..6be31df 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -11,8 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -31,44 +29,6 @@
>  
>  /* Xen may fire a timer up to this many ns early */
>  #define TIMER_SLOP   10
> -#define NS_PER_TICK  (10LL / HZ)
> -
> -/* snapshots of runstate info */
> -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
> -
> -/* unused ns of stolen time */
> -static DEFINE_PER_CPU(u64, xen_residual_stolen);
> -
> -static void do_stolen_accounting(void)
> -{
> - struct vcpu_runstate_info state;
> - struct vcpu_runstate_info *snap;
> - s64 runnable, offline, stolen;
> - cputime_t ticks;
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - snap = this_cpu_ptr(_runstate_snapshot);
> -
> - /* work out how much time the VCPU has not been runn*ing*  */
> - runnable = state.time[RUNSTATE_runnable] - 
> snap->time[RUNSTATE_runnable];
> - offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
> -
> - *snap = state;
> -
> - /* Add the appropriate number of ticks of stolen time,
> -including any left-overs from last time. */
> - stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
> -
> - if (stolen < 0)
> - stolen = 0;
> -
> - ticks = iter_div_u64_rem(stolen, NS_PER_TICK, );
> - __this_cpu_write(xen_residual_stolen, stolen);
> - account_steal_ticks(ticks);
> -}
>  
>  /* Get the TSC speed from Xen */
>  static unsigned long xen_tsc_khz(void)
> @@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
> *dev_id)
>   ret = IRQ_HANDLED;
>   }
>  
> - do_stolen_accounting();
> -
>   return ret;
>  }
>  
> @@ -431,6 +389,8 @@ static void __init xen_time_init(void)
>   xen_setup_timer(cpu);
>   xen_setup_cpu_clockevents();
>  
> + xen_time_setup_guest();
> +
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  }
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 7107842..2257b66 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
>   return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
>  }
>  
> +static u64 xen_steal_clock(int cpu)
> +{
> + struct vcpu_runstate_info state;
> +
> + BUG_ON(cpu != smp_processor_id());
> + xen_get_runstate_snapshot();
> + return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> +}
> +
>  void xen_setup_runstate_info(int 

[Xen-devel] [ovmf test] 94575: all pass - PUSHED

[osstest service owner]

flight 94575 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94575/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 758ea94651545896309725b53407e57e79477f28
baseline version:
 ovmf 81c1460695f783a3f91431b2babea623556a7f5d

Last test of basis94559  2016-05-18 20:43:21 Z0 days
Testing same since94575  2016-05-19 06:44:31 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Cinnamon Shia 
  Dong, Eric 
  Eric Dong 
  Hao Wu 
  Maurice Ma 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=ovmf
+ revision=758ea94651545896309725b53407e57e79477f28
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
758ea94651545896309725b53407e57e79477f28
+ branch=ovmf
+ revision=758ea94651545896309725b53407e57e79477f28
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x758ea94651545896309725b53407e57e79477f28 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print 

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Stefano Stabellini]

On Thu, 19 May 2016, Juergen Gross wrote:
> On 19/05/16 12:48, Stefano Stabellini wrote:
> > On Thu, 19 May 2016, Jan Beulich wrote:
> > On 19.05.16 at 12:40,  wrote:
> >>> On Thu, 19 May 2016, Juergen Gross wrote:
> > Alternatively, the easiest way will probably be to add a new VMASSIST,
> > which allows the guest to opt into the new behaviour.
> 
>  Aah, nice. Yes, this seems to be a sensible option.
> >>>
> >>> If you are referring to VM_ASSIST, it is only available on x86. I
> >>> suggest we use a feature flag instead.
> >>
> >> A feature flag can only be checked by the guest, not set. How
> >> about enabling VMASSIST for ARM?
> > 
> > Sure
> 
> Stefano, if you want I can do this when adding the VMASSIST option.

That would be great

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

[Xen-devel] [libvirt test] 94572: tolerable FAIL - PUSHED

[osstest service owner]

flight 94572 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94572/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  20a0fa8eb216f03b5e873ed61272083f7a801632
baseline version:
 libvirt  c4111209b8b40fe8673f5dd13518231c4ed7967a

Last test of basis94539  2016-05-18 04:21:06 Z1 days
Testing same since94572  2016-05-19 04:20:56 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Fritz Elfert 
  Jiri Denemark 
  John Ferlan 
  Maxim Nestratov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=libvirt
+ revision=20a0fa8eb216f03b5e873ed61272083f7a801632
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos

[Xen-devel] netif.h clarifications

[Roger Pau Monné]

Hello,

While trying to solve a FreeBSD netfront bug [0] I came across a couple 
of netif.h dark spots that I think should be documented in the netif.h 
header. I'm willing to make those changes, but I want to make sure my 
understanding is right.

Regarding checksum offloading, I had a hard time figuring out what the 
different flags actually mean:

/* Packet data has been validated against protocol checksum. */
#define _NETRXF_data_validated (0)
#define  NETRXF_data_validated (1U<<_NETRXF_data_validated)

/* Protocol checksum field is blank in the packet (hardware offload)? */
#define _NETRXF_csum_blank (1)
#define  NETRXF_csum_blank (1U<<_NETRXF_csum_blank)

(Same applies to the TX flags, I'm not copying them there because they are 
the same)

First of all, I assume "protocol" here refers to Layer 3 and Layer 4 
protocol, so that would be IP and TCP/UDP/SCTP checksum offloading? In any 
case this needs clarification and proper wording.

Then, I have some questions regarding the meaning of the flags themselves 
and the content of the checksum field in all the possible scenarios.

On RX path:

 - NETRXF_data_validated only: data has been validated, but what's the state 
   of the checksum field itself? If the data is validated again, would it 
   match against the checksum?
 - NETRXF_csum_blank only: I don't think this makes much sense, data is in 
   unknown state and checksum is not present, so there's no way to validate 
   it. Packet should be dropped?
 - NETRXF_data_validated | NETRXF_csum_blank: this combination seems to be 
   the one that makes more sense to me, data is valid, but checksum is not 
   there. This matches what some real NICs already do, that is to provide 
   the result of the checksum check _without_ actually providing the 
   checksum itself on the RX path.

On TX path:

 - NETTXF_data_validated only: I don't think this makes any sense, data is 
   always valid from the senders point of view.
 - NETTXF_csum_blank only: checksum calculation offload, it should be 
   performed by the other end.
 - NETTXF_data_validated | NETTXF_csum_blank: again, I don't think it makes 
   much sense, data is always valid from the senders point of view, or else 
   why bother sending it?

So it looks to me like we could get away with just two flags, one on the RX 
side that signals that the packet doesn't have a checksum but that the 
checksum validation has already been performed, and another one on the TX 
side to signal that the packet doesn't have a calculated checksum 
(typical checksum offload).

And then I've also seen some issues with TSO/LRO (GSO in Linux terminology) 
when using packet forwarding inside of a FreeBSD DomU. For example in the 
following scenario:

   +
   |
   +-+   ++   +--+
   | |A B|   router   |C D|  |
   | Guest 1 +---+ +  +---+ Guest 2  |
   | |  bridge0  | |  |  bridge1  |  |
   +-+   ++   +--+
   172.16.1.67  172.16.1.66|   10.0.1.1   10.0.1.2
   |
 +->
  ssh 10.0.1.2 |
   |
   |
   |
   +

All those VMs are inside of the same host, and one of them acts as a gateway 
between them because they are on two different subnets. In this case I'm 
seeing issues because even though I disable TSO/LRO on the "router" at 
runtime, the backend doesn't watch the xenstore feature flag, and never 
disables it from the vif on the Dom0 bridge. This causes LRO packets 
(non-fragmented) to be received at point 'C', and then when the gateway 
tries to inject them into the other NIC it fails because the size is greater 
than the MTU, and the "no fragment" bit is set.

How does Linux deal with this situation? Does it simply ignore the no 
fragment flag and fragments the packet? Does it simply inject the packet to 
the other end ignoring the MTU and propagating the GSO flag?

Roger.

[0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

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

[Xen-devel] [xen-unstable-smoke test] 94582: tolerable all pass - PUSHED

[osstest service owner]

flight 94582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94582/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a396c2549e079ab2f644aab8b2e7f47a8d0e3937
baseline version:
 xen  2bb230972c5ddb1ca823f47750b5d46a9d302d0e

Last test of basis94579  2016-05-19 11:01:49 Z0 days
Testing same since94582  2016-05-19 14:03:32 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ branch=xen-unstable-smoke
+ revision=a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xa396c2549e079ab2f644aab8b2e7f47a8d0e3937 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print 

Re: [Xen-devel] [PATCH for 4.7] xen: sched: avoid races on time values read from NOW()

[Meng Xu]

On Thu, May 19, 2016 at 4:11 AM, Dario Faggioli
 wrote:
> Hey Wei,
>
> Again, I'm using an otherwise unnecessary cover letter for my analysis about
> <>. :-)
>
> I'd say yes, because the patch fixes an actual bug, in the form of a rather
> subtle race condition, which was all but trivial to spot.  I must say, though,
> that I've only found the bug guilty of being particularly nasty if we use
> Credit2.  Actually, I'm quite sure it has an effect on RTDS too (although I 
> did
> not trace that), but since both Credit2 and RTDS are still marked as
> experimental in 4.7, one may think it's not worthwhile putting in something
> like this to fix experimental only code.
>
> Just FYI, this bug is what was causing the issue I briefly chatted about on 
> IRC
> with George, yesterday, i.e., it is what led Credit2 to emit (rather
> aggresively, actually) the debug printks showed here:
>
>  http://pastebin.com/gzYrNST5

In addition to the race condition in the bare metal,  actually I saw
this when I debug/run Xen in VirtualBox.
The situation is:
If we have nested virtualization or if we have heterogeneous cores
which have different speed/time, the RTDS scheduler (maybe credit2 as
well?) will have a problem in budget accounting. The "CPU" of Xen is
scheduled by the underlining hypervisor. One "CPU" of Xen could be
slower than another, showing the time is left behind.

We explicitly say that RTDS will have incorrect budget accounting for
nested virtualization situation, when the RTDS was upstreamed in Xen
4.5.

Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()

[Meng Xu]

On Thu, May 19, 2016 at 4:11 AM, Dario Faggioli
 wrote:
> or (even in cases where there is no race, e.g., outside
> of Credit2) avoid using a time sample which may be rather
> old, and hence stale.
>
> In fact, we should only sample NOW() from _inside_
> the critical region within which the value we read is
> used. If we don't, in case we have to spin for a while
> before entering the region, when actually using it:
>
>  1) we will use something that, at the veryy least, is
> not really "now", because of the spinning,
>
>  2) if someone else sampled NOW() during a critical
> region protected by the lock we are spinning on,
> and if we compare the two samples when we get
> inside our region, our one will be 'earlier',
> even if we actually arrived later, which is a
> race.
>
> In Credit2, we see an instance of 2), in runq_tickle(),
> when it is called by csched2_context_saved() as it samples
> NOW() before acquiring the runq lock. This makes things
> look like the time went backwards, and it confuses the
> algorithm (there's even a d2printk() about it, which would
> trigger all the time, if enabled).
>
> In RTDS, something similar happens in repl_timer_handler(),
> and there's another instance in schedule() (in generic code),
> so fix these cases too.
>
> While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
> a little as well (removing a pointless initialization, and
> moving the sampling a bit closer to its use). These two hunks
> entail no further functional changes.
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Wei Liu 
> ---

Reviewed-by: Meng Xu 

The bug will cause incorrect budget accounting for one VCPU when the
race occurs.

Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Xu, Quan]

On May 19, 2016 7:36 PM, Jan Beulich  wrote:
> >>> On 19.05.16 at 13:26,  wrote:
> > On May 19, 2016 2:13 PM, Jan Beulich  wrote:
> >> >>> "Xu, Quan"  05/19/16 3:35 AM >>>
> >> >On May 19, 2016 8:33 AM, Tian, Kevin  wrote:
> >> >> A single default value for both IOMMU-side and device-side is
> >> >> anyway not optimal. What about introducing a new knob e.g.
> >> >> vtd_qi_device_timeout specifically for device-side flush while
> >> >> using vtd_qi_timeout for other places? If device-side timeout is
> >> >> not specified, it is
> >> then default to vtd_qi_timeout.
> >>
> >> There should imo be a single command line option, allowing for two
> >> values to be passed (e.g. comma-separated).
> >
> > As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation,
> > so we are no need to increasing the value of timeout or introduce a
> > boot-time changed parameter.
> > What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC
> > invalidation timeout.
> 
> If you're absolutely certain no-one will ever find a need to increase that 
> value -
> sure.
> 

Sure.
Also this was mentioned in Kevin's ' Revisit VT-d asynchronous flush issue ' , 
http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00041.html 

"""-For context/iotlb/iec flush, our measurements show worst cases <10us. We 
also confirmed with hardware team, that 1ms is large  enough for IOMMU internal 
flush. """

> > For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout',
> > which is boot-time changed, and 1 ms by default.
> 
> One question is whether making this a VT-d specific command line option is a
> good idea: Other IOMMU implementations ought to be in need of doing
> device IOTLB invalidation too, at least sooner or later.
> 

This is indeed farsighted. Agreed.

> The other question is whether any timeout lower than the current one can be
> considered safe (and hence is usable as a default).
> 

Actually the criticality, 1 ms, is from hardware team.
IOW, Our hardware team confirmed that 1ms should be enough for integrated PCI 
devices with ATS.
for discrete PCI devices with ATS, it's uncertain whether 1ms  or 10ms is too 
restrictive to them, but there are only a few devices now in the market.

Quan

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

Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Wei Liu]

On Thu, May 19, 2016 at 10:56:06AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
> > On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> > > On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> > >> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded 
> > >> \n in
> > >> the signature checking paragraph.
> > >>
> > >>   /usr/bin/pandoc --number-sections --toc --standalone 
> > >> misc/xsplice.markdown
> > >> --output pdf/misc/xsplice.pdf
> > >>   ! Undefined control sequence.
> > >>   l.1085 appended\textasciitilde{}\n
> > >>
> > >> Surround the string in backticks to make it verbatim text.
> > > Ok, where is that change?
> > 
> > > @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature 
> > > verification.
> > >  
> > >  The signature is based on the all of the payloads continuously laid out
> > >  in memory. The signature is to be appended at the end of the ELF payload
> > > -prefixed with the string '~Module signature appended~\n', followed by
> > > +prefixed with the string `'~Module signature appended~\n'`, followed by
> > >  an signature header then followed by the signature, key identifier, and 
> > > signers
> > >  name.
> > 
> > ^ Here.
> 
> Thank you!
> > 
> > >> While altering this file, strip the substantial quantity of trailing
> > >> whitespace.
> > > Please do not. That was added specifically there otherwise
> > > markdown messes it up when doing HTML and the lines get mangled up.
> > 
> > Markdown isn't whitespace sensitive, so that really shouldn't be doing
> > anything.  If you want a verbatim text block, indent it by 4 characters.
> 
> https://daringfireball.net/projects/markdown/syntax
> 
> "When you do want to insert a  break tag using Markdown, you end a
> line with two or more spaces, then type return."
> 
> But if this can be done with indenting it with 4 characters that would
> work too.
> 

I take it you're happy with this change? Do you want to test it and
report back?

Wei.

> > 
> > ~Andrew

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

Re: [Xen-devel] when to bump library versions (was: )

[Jan Beulich]

>>> On 19.05.16 at 16:53,  wrote:
> On Thu, May 19, 2016 at 08:44:59AM -0600, Jan Beulich wrote:
>> >>> On 19.05.16 at 16:34,  wrote:
>> > We could even have the 
>> > library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
>> > that we don't need to go around the different library makefiles bumping 
>> > the 
>> > versions manually.
>> 
>> But so far these two are intentionally private to the xen/ subtree.
> 
> Maybe I'm missing something, but couldn't they be global to the whole tree? 
> (Config.mk seems like a suitable place).

I think originally the idea was that the tool stack isn't really tied to
a specific hypervisor version. What it is tied to is an interface
version (of namely domctl and sysctl).

Jan


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

Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Konrad Rzeszutek Wilk]

On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
> On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> > On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> >> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n 
> >> in
> >> the signature checking paragraph.
> >>
> >>   /usr/bin/pandoc --number-sections --toc --standalone 
> >> misc/xsplice.markdown
> >> --output pdf/misc/xsplice.pdf
> >>   ! Undefined control sequence.
> >>   l.1085 appended\textasciitilde{}\n
> >>
> >> Surround the string in backticks to make it verbatim text.
> > Ok, where is that change?
> 
> > @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature 
> > verification.
> >  
> >  The signature is based on the all of the payloads continuously laid out
> >  in memory. The signature is to be appended at the end of the ELF payload
> > -prefixed with the string '~Module signature appended~\n', followed by
> > +prefixed with the string `'~Module signature appended~\n'`, followed by
> >  an signature header then followed by the signature, key identifier, and 
> > signers
> >  name.
> 
> ^ Here.

Thank you!
> 
> >> While altering this file, strip the substantial quantity of trailing
> >> whitespace.
> > Please do not. That was added specifically there otherwise
> > markdown messes it up when doing HTML and the lines get mangled up.
> 
> Markdown isn't whitespace sensitive, so that really shouldn't be doing
> anything.  If you want a verbatim text block, indent it by 4 characters.

https://daringfireball.net/projects/markdown/syntax

"When you do want to insert a  break tag using Markdown, you end a
line with two or more spaces, then type return."

But if this can be done with indenting it with 4 characters that would
work too.

> 
> ~Andrew

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

Re: [Xen-devel] when to bump library versions (was: )

[Roger Pau Monné]

On Thu, May 19, 2016 at 08:44:59AM -0600, Jan Beulich wrote:
> >>> On 19.05.16 at 16:34,  wrote:
> > Currently we bump the shared library names just before the release, so ATM 
> > xen-unstable is still using the library names from the 4.6 release. This is 
> > an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
> > same box (unless you use a different prefix/DESTDIR), because libraries 
> > from 
> > xen-unstable will replace the stable ones.
> > 
> > IMHO, it would make more sense to bump the library names just *after* we 
> > branch and open the tree for development again.
> 
> As you may have seen in Wei's recent commit, not all libraries have
> their versions bumped for a given release.

IMHO, I would make them all bump, regardless of whether there have been 
changes or not.
 
> > We could even have the 
> > library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
> > that we don't need to go around the different library makefiles bumping the 
> > versions manually.
> 
> But so far these two are intentionally private to the xen/ subtree.

Maybe I'm missing something, but couldn't they be global to the whole tree? 
(Config.mk seems like a suitable place).

Roger.

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

[Xen-devel] Bump library names just after branching

[Roger Pau Monné]

Sorry, re-sending the message with a proper subject line:

Hello,

Currently we bump the shared library names just before the release, so ATM 
xen-unstable is still using the library names from the 4.6 release. This is 
an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
same box (unless you use a different prefix/DESTDIR), because libraries from 
xen-unstable will replace the stable ones.

IMHO, it would make more sense to bump the library names just *after* we 
branch and open the tree for development again. We could even have the 
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
that we don't need to go around the different library makefiles bumping the 
versions manually.

Roger.

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

Re: [Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests

[Xu, Quan]

On May 19, 2016 5:15 PM, Jan Beulich  wrote:
> >>> On 19.05.16 at 10:30,  wrote:
> > On April 28, 2016 11:13 PM, Jan Beulich  wrote:
> >> >>> On 25.04.16 at 10:40,  wrote:
> >> > With other patches also in place, still not work.
> >> > Jianzhong  has been left and Quan will take over the task.
> >>
> >> May I ask for another try, with current tip of staging plus
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-
> >> 04/msg03661.html
> >> ?
> >
> > The same issue for rhel 6.4VM,  which cannot initialize VF driver
> > too.. the below is log  of rhel 6.4 VM:
> >  ..
> >  igbvf: :00.04.0: Invalid MAC Address: 00:00:00:00:00:00
> >  igbvf: probe of :00.04.0 failed with error -5
> >  ..
> >
> > But when I tried to initialize VF MAC in Dom0 with e.g.:
> >   $ip link set eth0 vf 0 mac 00:1E:67:65:93:01
> 
> Makes things even more strange, as things work fine for me with
> SLE11 and SLE12 guests. But I have to admit that the "Invalid MAC Address"
> looks quite unrelated, i.e. is this perhaps some completely different problem
> you have?

I tried to run SLE12 guest. Things are really working fine for me too..
But not for rhel 6.4 guest..

So far, I think the bug is not from xen hypervisor, just from vf driver.

Look at this bug, even from KVM --- igb VF can't work in KVM guest, 
https://bugzilla.kernel.org/show_bug.cgi?id=55421
 
> 
> Again, considering that you have a repro (while I don't), the easiest would be
> to simply log all MSI-X related actions (there shouldn't be too many), to see
> where things go wrong. Such a log alone would maybe already allow me to do
> further investigation.
> 

I need more time to read this part, but sure I will follow it.

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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Jan Beulich]

>>> On 19.05.16 at 15:58,  wrote:
> Case 1: Dom0 is driver domain:
> There is a Ducati firmware which runs on dedicated M4 core and decodes
> video. This firmware uses hardcoded physical addresses for graphics
> buffers. Those addresses should be inside address-space of the driver
> domain (Dom0). Ducati firmware is proprietary and we have no ability
> to rework it. So Dom0 kernel should be placed to the configured
> address (to the DOM0 RAM bank with specific address).
> 
> Case 2: Dom0 is Thin and DomD is driver domain.
> All is the same: Ducati firmware requires special (hardcoded) addresses.

For both of these cases I would then wonder whether such
environments are actually suitable for doing virtualization on.

Jan


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

[Xen-devel] [linux-3.14 test] 94568: tolerable FAIL - PUSHED

[osstest service owner]

flight 94568 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94568/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 94027
 build-amd64-rumpuserxen   6 xen-buildfail   like 94027
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94027
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94027
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94027

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linuxc977650a67e6ca6c3cff9548b031d072d00db80a
baseline version:
 linux1c767107ef341cdc080d44d3ee1c9ca1b6957ce0

Last test of basis94027  2016-05-11 09:44:33 Z8 days
Testing same since94568  2016-05-19 01:45:01 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alex Deucher 
  Allain Legacy 
  Andi Kleen 
  Ben Hutchings 
  Chris Friesen 
  Chris Wilson 
  Daniel Vetter 
  Daniel Vetter 
  David S. Miller 
  Dmitry Torokhov 
  Greg Kroah-Hartman 
  H. Peter Anvin 
  Herbert Xu 
  Ian Campbell 
  Jani Nikula 
  Kangjie Lu 
  Kangjie Lu 
  Kevin Hilman 
  Krzysztof Kozlowski 
  Lucas Stach 
  Maarten Lankhorst 
  Marek Szyprowski 
  Mathias Krause 
  Nikolay Aleksandrov 
  Pavel Emelyanov 
  Tony Lindgren 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd   

Re: [Xen-devel] when to bump library versions (was: )

[Jan Beulich]

>>> On 19.05.16 at 16:34,  wrote:
> Currently we bump the shared library names just before the release, so ATM 
> xen-unstable is still using the library names from the 4.6 release. This is 
> an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
> same box (unless you use a different prefix/DESTDIR), because libraries from 
> xen-unstable will replace the stable ones.
> 
> IMHO, it would make more sense to bump the library names just *after* we 
> branch and open the tree for development again.

As you may have seen in Wei's recent commit, not all libraries have
their versions bumped for a given release.

> We could even have the 
> library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
> that we don't need to go around the different library makefiles bumping the 
> versions manually.

But so far these two are intentionally private to the xen/ subtree.

Jan


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

Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Andrew Cooper]

On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
>> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
>> the signature checking paragraph.
>>
>>   /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
>> --output pdf/misc/xsplice.pdf
>>   ! Undefined control sequence.
>>   l.1085 appended\textasciitilde{}\n
>>
>> Surround the string in backticks to make it verbatim text.
> Ok, where is that change?

> @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature 
> verification.
>  
>  The signature is based on the all of the payloads continuously laid out
>  in memory. The signature is to be appended at the end of the ELF payload
> -prefixed with the string '~Module signature appended~\n', followed by
> +prefixed with the string `'~Module signature appended~\n'`, followed by
>  an signature header then followed by the signature, key identifier, and 
> signers
>  name.

^ Here.

>> While altering this file, strip the substantial quantity of trailing
>> whitespace.
> Please do not. That was added specifically there otherwise
> markdown messes it up when doing HTML and the lines get mangled up.

Markdown isn't whitespace sensitive, so that really shouldn't be doing
anything.  If you want a verbatim text block, indent it by 4 characters.

~Andrew

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

[Xen-devel] [PATCH RFC 5/6] libxl: implementation of PV DRM device interface

[Iurii Mykhalskyi]

From: Pavlo Suikov 

Signed-off-by: Pavlo Suikov 
Signed-off-by: Glib Golubytskyi 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 tools/libxl/libxl.c  | 290 +++
 tools/libxl/libxl.h  |  18 +++
 tools/libxl/libxl_create.c   |  42 -
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.h |  13 +-
 tools/libxl/libxl_types.idl  |  21 +++
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   3 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 164 +++-
 tools/libxl/xl_cmdtable.c|  15 ++
 11 files changed, 567 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b64815e..ccb0411 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,284 @@ exit:
 
 
/**/
 
+int libxl__device_vdrm_setdefault(libxl__gc *gc, libxl_device_vdrm *vdrm)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vdrm->backend_domname, >backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vdrm(libxl__gc *gc, uint32_t domid, 
libxl_device_vdrm *vdrm, libxl__device *device)
+{
+   device->backend_devid   = vdrm->devid;
+   device->backend_domid   = vdrm->backend_domid;
+   device->backend_kind= LIBXL__DEVICE_KIND_VDRM;
+   device->devid   = vdrm->devid;
+   device->domid   = domid;
+   device->kind= LIBXL__DEVICE_KIND_VDRM;
+
+   return 0;
+}
+
+static int libxl__device_vdrm_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vdrm *vdrm)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vdrm_init(vdrm);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vdrm->devid = atoi(tmp);
+else
+vdrm->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vdrm(libxl_ctx *ctx, uint32_t domid,
+  int devid, libxl_device_vdrm *vdrm)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vdrm_init(vdrm);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vdrm/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vdrm_from_xs_be(gc, path, vdrm);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vdrm_add(libxl__egc *egc, uint32_t domid, libxl_device_vdrm 
*vdrm, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vdrm vdrm_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vdrm_init(_saved);
+libxl_device_vdrm_copy(CTX, _saved, vdrm);
+
+rc = libxl__device_vdrm_setdefault(gc, vdrm);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vdrm->devid = libxl__device_nextid(gc, domid, "vdrm")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vdrm(gc, domid, vdrm, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vdrm->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+flexarray_append(back, "mode0");
+flexarray_append(back, vdrm->mode0);
+flexarray_append(back, "mode1");
+flexarray_append(back, vdrm->mode1);
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+flexarray_append(front, "mode0");
+flexarray_append(front, vdrm->mode0);
+flexarray_append(front, "mode1");
+flexarray_append(front, vdrm->mode1);
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+  

[Xen-devel] [PATCH RFC 0/6] Set of PV drivers used by production project

[Iurii Mykhalskyi]

This patches introduce set of pv drivers interfaces.
Drivers interfaces list:
 - PV RTC - real-time clock
 - PV TTY - interface for pv version for device controlled by
via tty (e.g. GPS)
 - PV Audio - sound interface virtualization
 - PV DRM - direct rengering manager virtualization
 - PV RPMSG - remove procedure call interface, in our case
used for playback codecs virtualization

Iurii Mykhalskyi (2):
  libxl: implementation of PV rtc device interface
  libxl: implementation of PV tty device interface.

Pavlo Suikov (4):
  libxl: implementation of PV audio device interface
  libxl: implementation of PV event device interface
  libxl: implementation of PV DRM device interface
  libxl: implementation of PV RPMSG device interface

 tools/libxl/libxl.c  | 1781 +-
 tools/libxl/libxl.h  |  102 ++
 tools/libxl/libxl_create.c   |  214 +++-
 tools/libxl/libxl_device.c   |   12 +
 tools/libxl/libxl_internal.c |8 +
 tools/libxl/libxl_internal.h |   88 +-
 tools/libxl/libxl_types.idl  |  131 +++
 tools/libxl/libxl_types_internal.idl |6 +
 tools/libxl/libxl_utils.h|   19 +
 tools/libxl/xl.h |   18 +
 tools/libxl/xl_cmdimpl.c | 1035 +++-
 tools/libxl/xl_cmdtable.c|   95 ++
 12 files changed, 3499 insertions(+), 10 deletions(-)

-- 
2.8.2


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

[Xen-devel] [PATCH RFC 1/6] libxl: implementation of PV rtc device interface

[Iurii Mykhalskyi]

PV rtc device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.

Signed-off-by: Iurii Mykhalskyi 
Signed-off-by: Glib Golubytskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxl/libxl.c  | 287 ++-
 tools/libxl/libxl.h  |  17 +++
 tools/libxl/libxl_create.c   |  39 -
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.h |  19 ++-
 tools/libxl/libxl_types.idl  |  19 +++
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   3 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 161 +++-
 tools/libxl/xl_cmdtable.c|  15 ++
 11 files changed, 558 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ac50bda..09c4bc7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2323,6 +2323,277 @@ int libxl_devid_to_device_vtpm(libxl_ctx *ctx,
 return rc;
 }
 
+/**/
+
+int libxl__device_vrtc_setdefault(libxl__gc *gc, libxl_device_vrtc *vrtc)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrtc->backend_domname, >backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrtc(libxl__gc *gc, uint32_t domid, 
libxl_device_vrtc *vrtc, libxl__device *device)
+{
+   device->backend_devid   = vrtc->devid;
+   device->backend_domid   = vrtc->backend_domid;
+   device->backend_kind= LIBXL__DEVICE_KIND_VRTC;
+   device->devid   = vrtc->devid;
+   device->domid   = domid;
+   device->kind= LIBXL__DEVICE_KIND_VRTC;
+
+   return 0;
+}
+
+static int libxl__device_vrtc_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrtc *vrtc)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrtc_init(vrtc);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrtc->devid = atoi(tmp);
+else
+vrtc->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrtc(libxl_ctx *ctx, uint32_t domid,
+  int devid, libxl_device_vrtc *vrtc)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrtc_init(vrtc);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vrtc/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrtc_from_xs_be(gc, path, vrtc);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrtc_add(libxl__egc *egc, uint32_t domid, libxl_device_vrtc 
*vrtc, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrtc vrtc_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vrtc_init(_saved);
+libxl_device_vrtc_copy(CTX, _saved, vrtc);
+
+rc = libxl__device_vrtc_setdefault(gc, vrtc);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrtc->devid = libxl__device_nextid(gc, domid, "vrtc")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrtc(gc, domid, vrtc, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrtc->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, _config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration 
returned 

[Xen-devel] [PATCH RFC 6/6] libxl: implementation of PV RPMSG device interface

[Iurii Mykhalskyi]

From: Pavlo Suikov 

Signed-off-by: Pavlo Suikov 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 tools/libxl/libxl.c  | 282 +++
 tools/libxl/libxl.h  |  17 +++
 tools/libxl/libxl_create.c   |  40 -
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.h |  13 +-
 tools/libxl/libxl_types.idl  |  19 +++
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   3 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 161 +++-
 tools/libxl/xl_cmdtable.c|  21 ++-
 11 files changed, 554 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ccb0411..871061d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2873,6 +2873,276 @@ exit:
 
 
/**/
 
+int libxl__device_vrpmsg_setdefault(libxl__gc *gc, libxl_device_vrpmsg *vrpmsg)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrpmsg->backend_domname, 
>backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrpmsg(libxl__gc *gc, uint32_t domid, 
libxl_device_vrpmsg *vrpmsg, libxl__device *device)
+{
+   device->backend_devid   = vrpmsg->devid;
+   device->backend_domid   = vrpmsg->backend_domid;
+   device->backend_kind= LIBXL__DEVICE_KIND_VRPMSG;
+   device->devid   = vrpmsg->devid;
+   device->domid   = domid;
+   device->kind= LIBXL__DEVICE_KIND_VRPMSG;
+
+   return 0;
+}
+
+static int libxl__device_vrpmsg_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrpmsg *vrpmsg)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrpmsg_init(vrpmsg);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrpmsg->devid = atoi(tmp);
+else
+vrpmsg->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrpmsg(libxl_ctx *ctx, uint32_t domid,
+  int devid, libxl_device_vrpmsg *vrpmsg)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrpmsg_init(vrpmsg);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vrpmsg/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrpmsg_from_xs_be(gc, path, vrpmsg);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrpmsg_add(libxl__egc *egc, uint32_t domid, 
libxl_device_vrpmsg *vrpmsg, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrpmsg vrpmsg_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vrpmsg_init(_saved);
+libxl_device_vrpmsg_copy(CTX, _saved, vrpmsg);
+
+rc = libxl__device_vrpmsg_setdefault(gc, vrpmsg);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrpmsg->devid = libxl__device_nextid(gc, domid, "vrpmsg")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrpmsg(gc, domid, vrpmsg, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrpmsg->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, _config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration 
returned %d", rc);
+if (rc) goto out;
+
+

[Xen-devel] [PATCH RFC 4/6] libxl: implementation of PV event device interface

[Iurii Mykhalskyi]

From: Pavlo Suikov 

Touchscreen events device configuration support. Can be further
extended to support any event device whatsoever.

Signed-off-by: Pavlo Suikov 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 tools/libxl/libxl.c  | 289 ++-
 tools/libxl/libxl.h  |  17 +++
 tools/libxl/libxl_create.c   |  39 -
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.c |   4 +
 tools/libxl/libxl_internal.h |  20 ++-
 tools/libxl/libxl_types.idl  |  21 +++
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   4 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 170 -
 tools/libxl/xl_cmdtable.c|  15 ++
 12 files changed, 580 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1426bf6..b64815e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5003,6 +5003,282 @@ out:
 
 
/**/
 
+int libxl__device_vevent_setdefault(libxl__gc *gc, libxl_device_vevent *vevent)
+{
+int rc;
+rc = libxl__resolve_domid(gc, vevent->backend_domname, 
>backend_domid);
+return rc;
+}
+
+static int libxl__device_from_vevent(libxl__gc *gc, uint32_t domid,
+ libxl_device_vevent *vevent,
+ libxl__device *device)
+{
+device->backend_devid = vevent->devid;
+device->backend_domid = vevent->backend_domid;
+device->backend_kind = LIBXL__DEVICE_KIND_VEVENT;
+device->devid = vevent->devid;
+device->domid = domid;
+device->kind = LIBXL__DEVICE_KIND_VEVENT;
+
+return 0;
+}
+
+static int libxl__device_vevent_from_xs_be(libxl__gc *gc,
+   const char *be_path,
+   libxl_device_vevent *vevent)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vevent_init(vevent);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vevent->devid = atoi(tmp);
+else
+vevent->devid = 0;
+
+rc = 0;
+out:
+return rc;
+}
+
+int libxl_devid_to_device_vevent(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vevent *vevent)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vevent_init(vevent);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vevent/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vevent_from_xs_be(gc, path, vevent);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vevent_add(libxl__egc *egc, uint32_t domid,
+  libxl_device_vevent *vevent,
+  libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vevent vevent_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vevent_init(_saved);
+libxl_device_vevent_copy(CTX, _saved, vevent);
+
+rc = libxl__device_vevent_setdefault(gc, vevent);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 16, 1);
+if (vevent->devid == -1) {
+if ((vevent->devid = libxl__device_nextid(gc, domid, "vevent")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vevent(gc, _saved, vevent);
+
+GCNEW(device);
+rc = libxl__device_from_vevent(gc, domid, vevent, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "feature-abs-pointer");
+flexarray_append(back, libxl__sprintf(gc, "%d", 
vevent->feature_abs_pointer));
+flexarray_append(back, "abs-width");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_width));
+flexarray_append(back, "abs-height");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_height));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vevent->devid));
+

Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Konrad Rzeszutek Wilk]

On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
> the signature checking paragraph.
> 
>   /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
> --output pdf/misc/xsplice.pdf
>   ! Undefined control sequence.
>   l.1085 appended\textasciitilde{}\n
> 
> Surround the string in backticks to make it verbatim text.

Ok, where is that change?
> 
> While altering this file, strip the substantial quantity of trailing
> whitespace.

Please do not. That was added specifically there otherwise
markdown messes it up when doing HTML and the lines get mangled up.

> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Rzeszutek Wilk 
> ---
>  docs/misc/xsplice.markdown | 304 
> ++---
>  1 file changed, 152 insertions(+), 152 deletions(-)
> 
> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
> index 4a98be1..80f8bc7 100644
> --- a/docs/misc/xsplice.markdown
> +++ b/docs/misc/xsplice.markdown
> @@ -90,18 +90,18 @@ As example we will assume the hypervisor does not have 
> XSA-132 (see
>  the hypervisor with it. The original code looks as so:
>  
>  
> -   48 89 e0  mov%rsp,%rax  
> -   48 25 00 80 ff ff and$0x8000,%rax  
> +   48 89 e0  mov%rsp,%rax
> +   48 25 00 80 ff ff and$0x8000,%rax
>  
>  
>  while the new patched hypervisor would be:
>  
>  
> -   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
> -   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
> -   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
> -   48 89 e0  mov%rsp,%rax  
> -   48 25 00 80 ff ff and$0x8000,%rax  
> +   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
> +   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
> +   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
> +   48 89 e0  mov%rsp,%rax
> +   48 25 00 80 ff ff and$0x8000,%rax
>  
>  
>  This is inside the arch_do_domctl. This new change adds 21 extra
> @@ -113,8 +113,8 @@ As such we could simplify this problem by only patching 
> the site
>  which calls arch_do_domctl:
>  
>  
> -do_domctl:  
> - e8 4b b1 05 00  callq  82d08015fbb9   
> +do_domctl:
> + e8 4b b1 05 00  callq  82d08015fbb9 
>  
>  
>  with a new address for where the new `arch_do_domctl` would be (this
> @@ -128,8 +128,8 @@ Patching the offset in `hypercall_table` for `do_domctl:
>  
>  
>  
> - 82d08024d490:   79 30  
> - 82d08024d492:   10 80 d0 82 ff ff   
> + 82d08024d490:   79 30
> + 82d08024d492:   10 80 d0 82 ff ff
>  
>  
>  
> @@ -172,9 +172,9 @@ from that). Patching the offset in `hypercall_table` for 
> the old
>  `do_xen_version` (82d080112f9e )
>  
>  
> - 82d08024b270 :   
> - ...  
> - 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff  
> + 82d08024b270 :
> + ...
> + 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff
>  
>  
>  
> @@ -187,17 +187,17 @@ An alternative solution would be to patch insert a 
> trampoline in the
>  old `do_xen_version' function to directly jump to the new `do_xen_version`.
>  
>  
> - 82d080112f9e do_xen_version:  
> - 82d080112f9e:   48 c7 c0 da ff ff ffmov
> $0xffda,%rax  
> - 82d080112fa5:   83 ff 09cmp$0x9,%edi  
> - 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
> do_xen_version+0x534  
> + 82d080112f9e do_xen_version:
> + 82d080112f9e:   48 c7 c0 da ff ff ffmov
> $0xffda,%rax
> + 82d080112fa5:   83 ff 09cmp$0x9,%edi
> + 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
> do_xen_version+0x534
>  
>  
>  with:
>  
>  
> - 82d080112f9e do_xen_version:  
> - 82d080112f9e:   e9 XX YY ZZ QQ  jmpq   [new do_xen_version] 
>  
> + 82d080112f9e do_xen_version:
> + 82d080112f9e:   e9 XX YY ZZ QQ  jmpq   [new do_xen_version]
>  
>  
>  which would lessen the amount of patching to just one location.
> @@ -296,15 +296,15 @@ The `.xsplice.funcs` contains an array of 
> xsplice_patch_func structures
>  which describe the functions to be patched:
>  
>  
> -struct xsplice_patch_func {  
> -const char *name;  
> -void *new_addr;  
> -void *old_addr;  
> -uint32_t new_size;  
> -uint32_t old_size;  
> -uint8_t version;  
> -uint8_t opaque[31];  
> -};  
> +struct xsplice_patch_func {
> +const char *name;
> +void *new_addr;
> +void *old_addr;
> +uint32_t new_size;
> +uint32_t old_size;
> +uint8_t version;
> +uint8_t opaque[31];
> +};
>  
>  
>  The size of the structure is 64 bytes on 64-bit 

[Xen-devel] [PATCH RFC 2/6] libxl: implementation of PV audio device interface

[Iurii Mykhalskyi]

From: Pavlo Suikov 

PV Audio device interface is implemented in libxl and xl with
full support for device control

Signed-off-by: Pavlo Suikov 
Signed-off-by: Glib Golubytskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxl/libxl.c  | 351 ++-
 tools/libxl/libxl.h  |  16 ++
 tools/libxl/libxl_create.c   |  39 +++-
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.c |   4 +
 tools/libxl/libxl_internal.h |  20 +-
 tools/libxl/libxl_types.idl  |  32 
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   3 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 229 ++-
 tools/libxl/xl_cmdtable.c|  20 ++
 12 files changed, 715 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 09c4bc7..d96172d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2593,7 +2593,344 @@ exit:
 return rc;
 }
 
+/**/
+
+int libxl__device_vsnd_setdefault(libxl__gc *gc, libxl_device_vsnd *vsnd)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vsnd->backend_domname, >backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vsnd(libxl__gc *gc, uint32_t domid, 
libxl_device_vsnd *vsnd, libxl__device *device)
+{
+   device->backend_devid   = vsnd->devid;
+   device->backend_domid   = vsnd->backend_domid;
+   device->backend_kind= LIBXL__DEVICE_KIND_VSND;
+   device->devid   = vsnd->devid;
+   device->domid   = domid;
+   device->kind= LIBXL__DEVICE_KIND_VSND;
+
+   return 0;
+}
+
+static int libxl__device_vsnd_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vsnd *vsnd)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vsnd_init(vsnd);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vsnd->devid = atoi(tmp);
+else
+vsnd->devid = 0;
+
+vsnd->short_name = READ_BACKEND(gc, "short-name");
+vsnd->long_name = READ_BACKEND(gc, "long-name");
+vsnd->sample_formats = READ_BACKEND(gc, "sample-formats");
+vsnd->rates = READ_BACKEND(gc, "rates");
+
+tmp = READ_BACKEND(gc, "channels-min");
+if (tmp)
+vsnd->channels_min = atoi(tmp);
+else
+vsnd->channels_min = 0;
+
+tmp = READ_BACKEND(gc, "channels-max");
+if (tmp)
+vsnd->channels_max = atoi(tmp);
+else
+vsnd->channels_max = 0;
+
+tmp = READ_BACKEND(gc, "priority");
+if (tmp)
+vsnd->priority = atoi(tmp);
+else
+vsnd->priority = 0;
+
+vsnd->slave_device = READ_BACKEND(gc, "slave-device");
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vsnd(libxl_ctx *ctx, uint32_t domid,
+  int devid, libxl_device_vsnd *vsnd)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vsnd_init(vsnd);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vsnd/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vsnd_from_xs_be(gc, path, vsnd);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+
+void libxl__device_vsnd_add(libxl__egc *egc, uint32_t domid, libxl_device_vsnd 
*vsnd, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vsnd vsnd_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vsnd_init(_saved);
+libxl_device_vsnd_copy(CTX, _saved, vsnd);
+
+rc = libxl__device_vsnd_setdefault(gc, vsnd);
+if (rc) goto out;
+
+front = flexarray_make(gc, 32, 1);
+back = flexarray_make(gc, 32, 1);
+if (vsnd->devid == -1) {
+if ((vsnd->devid = libxl__device_nextid(gc, domid, "vsnd")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vsnd(gc, _saved, vsnd);
+
+GCNEW(device);
+rc = libxl__device_from_vsnd(gc, domid, vsnd, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "DomD");
+flexarray_append(back, "1");
+flexarray_append(back, "DomU");
+flexarray_append(back, "2");
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vsnd->devid));
+

[Xen-devel] [PATCH RFC 3/6] libxl: implementation of PV tty device interface.

[Iurii Mykhalskyi]

PV tty device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.

Signed-off-by: Iurii Mykhalskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxl/libxl.c  | 282 +++
 tools/libxl/libxl.h  |  17 +++
 tools/libxl/libxl_create.c   |  37 -
 tools/libxl/libxl_device.c   |   2 +
 tools/libxl/libxl_internal.h |  13 +-
 tools/libxl/libxl_types.idl  |  19 +++
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   3 +
 tools/libxl/xl.h |   3 +
 tools/libxl/xl_cmdimpl.c | 160 +++-
 tools/libxl/xl_cmdtable.c|  15 ++
 11 files changed, 549 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d96172d..1426bf6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,276 @@ exit:
 
 
/**/
 
+int libxl__device_vtty_setdefault(libxl__gc *gc, libxl_device_vtty *vtty)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vtty->backend_domname, >backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vtty(libxl__gc *gc, uint32_t domid, 
libxl_device_vtty *vtty, libxl__device *device)
+{
+   device->backend_devid   = vtty->devid;
+   device->backend_domid   = vtty->backend_domid;
+   device->backend_kind= LIBXL__DEVICE_KIND_VTTY;
+   device->devid   = vtty->devid;
+   device->domid   = domid;
+   device->kind= LIBXL__DEVICE_KIND_VTTY;
+
+   return 0;
+}
+
+static int libxl__device_vtty_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vtty *vtty)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vtty_init(vtty);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+   vtty->devid = atoi(tmp);
+else
+   vtty->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vtty(libxl_ctx *ctx, uint32_t domid,
+  int devid, libxl_device_vtty *vtty)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vtty_init(vtty);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+  libxl__sprintf(gc, "%s/device/vtty/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vtty_from_xs_be(gc, path, vtty);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vtty_add(libxl__egc *egc, uint32_t domid, libxl_device_vtty 
*vtty, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vtty vtty_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(_config);
+libxl_device_vtty_init(_saved);
+libxl_device_vtty_copy(CTX, _saved, vtty);
+
+rc = libxl__device_vtty_setdefault(gc, vtty);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vtty->devid = libxl__device_nextid(gc, domid, "vtty")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vtty(gc, domid, vtty, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vtty->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vtty->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, _config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration 
returned %d", rc);
+if (rc) goto out;
+
+DEVICE_ADD(vtty, vttys, domid, _saved, COMPARE_DEVID, _config);
+}
+
+

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Julien Grall]

Hello Oleksandr,

On 19/05/16 14:58, Oleksandr Dmytryshyn wrote:

Why would a user want to allocate DOM0 RAM bank to a specific address?

If I understand correctly your patch, DOM0 will only able to allocate one bank 
of the given size at the specific address. You also add this possibility for 
guest domain (see patch #4) and try to control where the guest memory will be 
allocated. This will increase a lot the chance of the memory allocation to fail.

For instance, the RAM region requested for DOM0 may have been used to allocate 
memory for Xen internal. So you need a way to reserve memory in order to avoid 
Xen using it.

I expect most of the users who want to use direct memory mapped guest to know 
the number of guests which will use this feature.

A such feature is only useful when pass-through a device to the guest on 
platfom without SMMU, so it is by default insecure.

So I would suggest to create a new device-tree binding (or re-use an actual 
one) to reserve memory region to be used for direct memory mapped domain.

Those regions could have an identifier to be used later during the allocation. 
This would avoid memory fragmentation, allow multiple RAM bank for DOM0,...

Any opinions?


Case 1: Dom0 is driver domain:
There is a Ducati firmware which runs on dedicated M4 core and decodes
video. This firmware uses hardcoded physical addresses for graphics
buffers. Those addresses should be inside address-space of the driver
domain (Dom0). Ducati firmware is proprietary and we have no ability
to rework it. So Dom0 kernel should be placed to the configured
address (to the DOM0 RAM bank with specific address).

Case 2: Dom0 is Thin and DomD is driver domain.
All is the same: Ducati firmware requires special (hardcoded) addresses.


So if I understand correctly, patches #4, #13, #16 are only here to 
workaround a firmware which does not do the right thing?


IHMO, modifying the memory allocator in Xen to make a firmware happy is 
just overkill. We need to explore all the possible solutions before 
going forward.


From your description, it looks like to me that the device-tree does 
not correctly describe the platform. The graphic buffers should be 
reserved using /memreserve or via a specific binding.


This would be used later by Xen to map the buffer into dom0 or allow 
dom0 to map it to a guest.


Regards,

--
Julien Grall

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

[Xen-devel] (no subject)

[Roger Pau Monné]

, Ian Jackson , Jan 
Beulich , Konrad Rzeszutek Wilk , 
Stefano Stabellini , Tim Deegan , Wei 
Liu 
Bcc: 
Subject: Bump library names just after branching
Reply-To: 

Hello,

Currently we bump the shared library names just before the release, so ATM 
xen-unstable is still using the library names from the 4.6 release. This is 
an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
same box (unless you use a different prefix/DESTDIR), because libraries from 
xen-unstable will replace the stable ones.

IMHO, it would make more sense to bump the library names just *after* we 
branch and open the tree for development again. We could even have the 
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
that we don't need to go around the different library makefiles bumping the 
versions manually.

Roger.

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

[Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Andrew Cooper]

Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
the signature checking paragraph.

  /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
--output pdf/misc/xsplice.pdf
  ! Undefined control sequence.
  l.1085 appended\textasciitilde{}\n

Surround the string in backticks to make it verbatim text.

While altering this file, strip the substantial quantity of trailing
whitespace.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Konrad Rzeszutek Wilk 
---
 docs/misc/xsplice.markdown | 304 ++---
 1 file changed, 152 insertions(+), 152 deletions(-)

diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 4a98be1..80f8bc7 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -90,18 +90,18 @@ As example we will assume the hypervisor does not have 
XSA-132 (see
 the hypervisor with it. The original code looks as so:
 
 
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
 
 while the new patched hypervisor would be:
 
 
-   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
-   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
-   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
+   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
+   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
+   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
 
 This is inside the arch_do_domctl. This new change adds 21 extra
@@ -113,8 +113,8 @@ As such we could simplify this problem by only patching the 
site
 which calls arch_do_domctl:
 
 
-do_domctl:  
- e8 4b b1 05 00  callq  82d08015fbb9   
+do_domctl:
+ e8 4b b1 05 00  callq  82d08015fbb9 
 
 
 with a new address for where the new `arch_do_domctl` would be (this
@@ -128,8 +128,8 @@ Patching the offset in `hypercall_table` for `do_domctl:
 
 
 
- 82d08024d490:   79 30  
- 82d08024d492:   10 80 d0 82 ff ff   
+ 82d08024d490:   79 30
+ 82d08024d492:   10 80 d0 82 ff ff
 
 
 
@@ -172,9 +172,9 @@ from that). Patching the offset in `hypercall_table` for 
the old
 `do_xen_version` (82d080112f9e )
 
 
- 82d08024b270 :   
- ...  
- 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff  
+ 82d08024b270 :
+ ...
+ 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff
 
 
 
@@ -187,17 +187,17 @@ An alternative solution would be to patch insert a 
trampoline in the
 old `do_xen_version' function to directly jump to the new `do_xen_version`.
 
 
- 82d080112f9e do_xen_version:  
- 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax  
- 82d080112fa5:   83 ff 09cmp$0x9,%edi  
- 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
do_xen_version+0x534  
+ 82d080112f9e do_xen_version:
+ 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax
+ 82d080112fa5:   83 ff 09cmp$0x9,%edi
+ 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
do_xen_version+0x534
 
 
 with:
 
 
- 82d080112f9e do_xen_version:  
- 82d080112f9e:   e9 XX YY ZZ QQ  jmpq   [new do_xen_version]  
+ 82d080112f9e do_xen_version:
+ 82d080112f9e:   e9 XX YY ZZ QQ  jmpq   [new do_xen_version]
 
 
 which would lessen the amount of patching to just one location.
@@ -296,15 +296,15 @@ The `.xsplice.funcs` contains an array of 
xsplice_patch_func structures
 which describe the functions to be patched:
 
 
-struct xsplice_patch_func {  
-const char *name;  
-void *new_addr;  
-void *old_addr;  
-uint32_t new_size;  
-uint32_t old_size;  
-uint8_t version;  
-uint8_t opaque[31];  
-};  
+struct xsplice_patch_func {
+const char *name;
+void *new_addr;
+void *old_addr;
+uint32_t new_size;
+uint32_t old_size;
+uint8_t version;
+uint8_t opaque[31];
+};
 
 
 The size of the structure is 64 bytes on 64-bit hypervisors. It will be
@@ -345,33 +345,33 @@ to `old_addr`.
 A simple example of what a payload file can be:
 
 
-/* MUST be in sync with hypervisor. */  
-struct xsplice_patch_func {  
-const char *name;  
-void *new_addr;  
-void *old_addr;  
-uint32_t new_size;  
-uint32_t old_size;  
+/* MUST be in sync with hypervisor. */
+struct xsplice_patch_func {
+const char *name;
+void *new_addr;
+void *old_addr;
+uint32_t new_size;
+uint32_t old_size;
 uint8_t version;
-

Re: [Xen-devel] Resend: [PATCH] v3 - Add exclusive locking option to block-iscsi

[Roger Pau Monné]

On Thu, May 19, 2016 at 11:29:32AM +1000, Steven Haigh wrote:
> On 2016-05-09 14:22, Steven Haigh wrote:
> > On 2016-05-05 15:52, Steven Haigh wrote:
> > > On 2016-05-05 12:32, Steven Haigh wrote:
> > > > Overview
> > > > 
> > > > If you're using iSCSI, you can mount a target by multiple Dom0
> > > > machines on the same target. For non-cluster aware filesystems, this
> > > > can lead to disk corruption and general bad times by all. The iSCSI
> > > > protocol allows the use of persistent reservations as per the SCSI
> > > > disk spec. Low level SCSI commands for locking are handled by the
> > > > sg_persist program (bundled with sg3_utils package in EL).
> > > > 
> > > > The aim of this patch is to create a 'locktarget=y' option specified
> > > > within the disk 'target' command for iSCSI to lock the target in
> > > > exclusive mode on VM start with a key generated from the local
> > > > systems
> > > > IP, and release this lock on the shutdown of the DomU.
> > > > 
> > > > Example Config:
> > > > disk=
> > > > ['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']
> > > > 
> > > > In writing this, I have also re-factored parts of the script to put
> > > > some things in what I believe to be a better place to make expansion
> > > > easier. This is mainly in removing functions that purely call other
> > > > functions with no actual code execution.
> > > > 
> > > > Signed-off-by: Steven Haigh 
> > > > 
> > > > (on a side note, first time I've submitted a patch to the list
> > > > and I'm
> > > > currently stuck on a webmail client, so apologies in advance if this
> > > > all goes wrong ;)
> > > 
> > > Changes in v2:
> > > Bugfix: Call find_device to locate the /dev/sdX component of the iSCSI
> > > target before trying to run unlock_device().
> > > 
> > > Apologies for this oversight.
> > > 
> > 
> > Changes in v3:
> > * Split the block-iscsi cleanup into a seperate patch
> > (block-iscsi-locking-v3_01_simplify_block-iscsi.patch).
> > * Add locking in second patch file
> > (block-iscsi-locking-v3_02_add_locking.patch)
> 
> Resend of patches.

IMHO, if those patches are going to be committed to Xen they need to be 
sent using git, they are (at least) missing a proper changelog.

> There was a mention of having to add further documentation to
> xl-disk-configuration.txt - however there are no mentions of block-iscsi
> script within the documentation to add. As such, it probably would be out of
> place to add things here.

Hm, I don't think we have ever added specific block-scripts configuration 
options to xl-disk-configuration.txt. What I did was to instead add this 
information at the top of the script file itself, and the locktarget option 
should be documented there together with the other options. Sadly I see that 
the 'multipath' option did not add the documentation.

> The locktarget option is presented directly to the block-iscsi script and
> not evaluated anywhere outside this script.
> 
> -- 
> Steven Haigh
> 
> Email: net...@crc.id.au
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897

> --- block-iscsi.orig2016-05-09 15:12:02.489495212 +1000
> +++ block-iscsi 2016-05-09 15:16:35.447480532 +1000
> @@ -31,16 +31,6 @@
>  echo $1 | sed "s/^\("$2"\)//"
>  }
>  
> -check_tools()
> -{
> -if ! command -v iscsiadm > /dev/null 2>&1; then
> -fatal "Unable to find iscsiadm tool"
> -fi
> -if [ "$multipath" = "y" ] && ! command -v multipath > /dev/null 2>&1; 
> then
> -fatal "Unable to find multipath"
> -fi
> -}
> -
>  # Sets the following global variables based on the params field passed in as
>  # a parameter: iqn, portal, auth_method, user, multipath, password
>  parse_target()
> @@ -52,12 +42,18 @@
>  case $param in
>  iqn=*)
>  iqn=$(remove_label $param "iqn=")
> +if ! command -v iscsiadm > /dev/null 2>&1; then
> +fatal "Could not find iscsiadm tool."
> +fi
>  ;;
>  portal=*)
>  portal=$(remove_label $param "portal=")
>  ;;
>  multipath=*)
>  multipath=$(remove_label $param "multipath=")

This is wrong, multipath can have the values 'y' or 'n' only, and there's a 
check below that makes sure of that. Here you would be checking if 
'multipath' is available even if multipath=n has been set.

IMHO, I think that having a separation between the option parser and the 
tools availability check makes sense, and avoids mistakes like this.

> +if ! command -v multipath > /dev/null 2>&1; then
> +fatal "Multipath selected, but no multipath tools found"
> +fi
>  ;;
>  esac
>  done
> @@ -96,40 +92,6 @@
>  fi
>  }
> 
> -# Attaches the target $iqn in $portal and sets $dev to point to the
> -# multipath device
> -attach()
> -{
> -do_or_die iscsiadm -m node --targetname "$iqn" -p 

[Xen-devel] [PATCH for-4.7 1/3] docs/build: Avoid using multi-target pattern rules

[Andrew Cooper]

Multi-target non-pattern rules and Multi-target pattern rules behave rather
differently.  From `Pattern Intro':

  Pattern rules may have more than one target.  Unlike normal rules, this does
  not act as many different rules with the same prerequisites and commands.
  If a pattern rule has multiple targets, `make' knows that the rule's
  commands are responsible for making all of the targets.  The commands are
  executed only once to make all the targets.

The intended use of the multi-target pattern rules was to avoid repeating the
identical recipe multiple times.  The issue can be demonstrated with the
generation of documentation from pandoc source.

  ./xen.git$ touch docs/features/template.pandoc
  ./xen.git$ make -C docs/
  # Regenerates html/features/template.html
  ./xen.git$ make -C docs/
  # Regenerates txt/features/template.txt
  ./xen.git$ make -C docs/
  # Regenerates pdf/features/template.pdf

To work around this, there need to be three distinct rules, so the execution
of one recipe doesn't short ciruit the others.  To avoid copy
duplication, introduce a metarule, and evalute it for each document target.

As $(PANDOC) is used to generate documentation from different source types,
the metarule can be extended to also encompas the rule to create pdfs from
markdown.

Signed-off-by: Andrew Cooper 
Acked-by: Ian Jackson 
Release-acked-by: Wei Liu 
---
 docs/Makefile | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index b9da605..e2537e8 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -180,22 +180,24 @@ txt/%.txt: %.markdown
@$(INSTALL_DIR) $(@D)
$(INSTALL_DATA) $< $@
 
-pdf/%.pdf: %.markdown
-ifneq ($(PANDOC),)
-   @$(INSTALL_DIR) $(@D)
-   $(PANDOC) --number-sections --toc --standalone $< --output $@
-else
-   @echo "pandoc not installed; skipping $@"
-endif
+# Metarule for generating pandoc rules.
+define GENERATE_PANDOC_RULE
+# $(1) is the target documentation format. $(2) is the source format.
 
-pdf/%.pdf txt/%.txt html/%.html: %.pandoc
+$(1)/%.$(1): %.$(2)
 ifneq ($(PANDOC),)
-   @$(INSTALL_DIR) $(@D)
-   $(PANDOC) --number-sections --toc --standalone $< --output $@
+   @$(INSTALL_DIR) $$(@D)
+   $(PANDOC) --number-sections --toc --standalone $$< --output $$@
 else
-   @echo "pandoc not installed; skipping $@"
+   @echo "pandoc not installed; skipping $$@"
 endif
 
+endef
+$(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc))   # pdf/%.pdf: %.pandoc
+$(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # txt/%.txt: %.pandoc
+$(eval $(call GENERATE_PANDOC_RULE,html,pandoc))  # html/%.html: %.pandoc
+$(eval $(call GENERATE_PANDOC_RULE,pdf,markdown)) # pdf/%.pdf: %.markdown
+
 ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Docs.mk:
$(error You have to run ./configure before building docs)
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 3/3] docs/feature: Tweaks to the feature document template

[Andrew Cooper]

During review of the migration feature doc, some changes were made which
should have been reflected in the template.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 docs/features/template.pandoc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/features/template.pandoc b/docs/features/template.pandoc
index 7698291..82881e3 100644
--- a/docs/features/template.pandoc
+++ b/docs/features/template.pandoc
@@ -29,22 +29,22 @@ Architecture(s): e.g. x86, arm
 A short description the feature, similar to an abstract for a
 paper/presentation.
 
-# User information
+# User details
 
 Information for a user attempting to use the feature.  Should include
 how to enable the feature (is it enabled by default? If not, how to turn
 it on?), and how to interact with the feature (typically via `xl`).
 
+# Technical details
+
+Information for a developer or power user.  Should include where to look
+in-tree for detailed documents and code.
+
 # Limitations
 
 Information concerning incompatibilities with other features or hardware
 combinations.
 
-# Technical information
-
-Information for a developer or power user.  Should include where to look
-in-tree for detailed documents and code.
-
 # Testing
 
 Information concerning how to properly test changes affecting this feature.
-- 
2.1.4


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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Juergen Gross]

On 19/05/16 12:48, Stefano Stabellini wrote:
> On Thu, 19 May 2016, Jan Beulich wrote:
> On 19.05.16 at 12:40,  wrote:
>>> On Thu, 19 May 2016, Juergen Gross wrote:
> Alternatively, the easiest way will probably be to add a new VMASSIST,
> which allows the guest to opt into the new behaviour.

 Aah, nice. Yes, this seems to be a sensible option.
>>>
>>> If you are referring to VM_ASSIST, it is only available on x86. I
>>> suggest we use a feature flag instead.
>>
>> A feature flag can only be checked by the guest, not set. How
>> about enabling VMASSIST for ARM?
> 
> Sure

Stefano, if you want I can do this when adding the VMASSIST option.


Juergen


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

> Why would a user want to allocate DOM0 RAM bank to a specific address?
>
> If I understand correctly your patch, DOM0 will only able to allocate one 
> bank of the given size at the specific address. You also add this possibility 
> for guest domain (see patch #4) and try to control where the guest memory 
> will be allocated. This will increase a lot the chance of the memory 
> allocation to fail.
>
> For instance, the RAM region requested for DOM0 may have been used to 
> allocate memory for Xen internal. So you need a way to reserve memory in 
> order to avoid Xen using it.
>
> I expect most of the users who want to use direct memory mapped guest to know 
> the number of guests which will use this feature.
>
> A such feature is only useful when pass-through a device to the guest on 
> platfom without SMMU, so it is by default insecure.
>
> So I would suggest to create a new device-tree binding (or re-use an actual 
> one) to reserve memory region to be used for direct memory mapped domain.
>
> Those regions could have an identifier to be used later during the 
> allocation. This would avoid memory fragmentation, allow multiple RAM bank 
> for DOM0,...
>
> Any opinions?

Case 1: Dom0 is driver domain:
There is a Ducati firmware which runs on dedicated M4 core and decodes
video. This firmware uses hardcoded physical addresses for graphics
buffers. Those addresses should be inside address-space of the driver
domain (Dom0). Ducati firmware is proprietary and we have no ability
to rework it. So Dom0 kernel should be placed to the configured
address (to the DOM0 RAM bank with specific address).

Case 2: Dom0 is Thin and DomD is driver domain.
All is the same: Ducati firmware requires special (hardcoded) addresses.

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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Roger Pau Monne]

On Thu, May 19, 2016 at 12:21:57PM +0200, Dario Faggioli wrote:
> Since, AFAIUI, you're interested in non-Linux guests' perspective, I'm
> adding Roger (and avoiding trimming, for his benefit), who can tell us
> what he thinks of this all, from the FreeBSD point of view.

Thanks, AFAIK vcpu_runstate_info is only used by Linux ATM? (maybe Windows?) 
FreeBSD doesn't do stolen time accounting at all, and (although I would 
really like to see this implemented) I don't foresee myself adding this in 
the near future. That's mainly because FreeBSD doesn't have the necessary 
scheduler hooks, so it's not only implementing the Xen side of it, it needs 
to be plumbed through the scheduler and that doesn't look like an easy task.

NetBSD also doesn't seem to do it, and OpenBSD just gained basic Xen 
support, so no stolen time accounting there also.
 
> On Thu, May 19, 2016 at 10:49 AM, Juergen Gross  wrote:
> > On 19/05/16 10:09, Andrew Cooper wrote:
> >> On 19/05/2016 08:53, Juergen Gross wrote:
> >>> A guest kernel can use the vcpu_op hypercall sub-op
> >>> VCPUOP_register_runstate_memory_area to get a copy of the
> >>> vcpu_runstate_info of a vcpu mapped into its memory. As this structure
> >>> has no update indicator it is only save to be read by the vcpu it is
> >>> containing the runstate information of.
> >>>
> >>> Being able to read the runstate info of another cpu is required e.g.
> >>> by the Linux kernel to be able to calculate vruntime: see
> >>>
> >>> http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html
> >>>
> >>> I'd suggest to add an "update in progress" indicator in the highest
> >>> bit of vcpu_runstate_info->state_entry_time as this structure element is
> >>> already used to detect vcpu scheduling when vcpu_runstate_info is read
> >>> by the owning vcpu.
> >>>
> >>> The question is how to enable setting this indicator, as the guest must
> >>> be able to cope with it (I believe the Linux kernel would just run fine,
> >>> but we can't be sure this is true for all guests).
> >>>
> >>> I see the following possible solutions:
> >>>
> >>> a) Introduce a new vcpu_op hypercall sub-op for mapping the
> >>>vcpu_runstate_info with update indicator support (a guest supporting
> >>>this would try the new sub-op first and could fall back to
> >>>VCPUOP_register_runstate_memory_area in case of ENOSYS).
> >>>
> >>> b) Add a virtual MSR to switch on the feature (not being able to set the
> >>>appropriate bit would indicate the feature not being available). This
> >>>is the variant KVM is using. Does ARM have something like MSRs?

So I assume the vcpu_runstate_info structure is shared between Xen and KVM, 
just like the PV time info structure?

> >>> c) Add another hypercall to switch on the feature (similar to
> >>>XENVER_get_features we could have a XENVER_set_features).
> >>>
> >>> Any preferences?
> >>
> >> However, irrespective of how you signal the request for new behaviour,
> >> you should see about using a lockless clock rather than a single bit, as
> >> a single bit can't indicate the case where a complete update has
> >> occurred between two samplings.  This will probably require an extension
> >> to the current implementation, at which point you might be able to add a
> >> capability field as well.
> >
> > That's the reason I've chosen state_entry_time as the home for the new
> > bit. state_entry_time is guaranteed to change between two updates. So
> > the logic would look like the following:
> >
> > do {
> >   old_entry_time = READ_ONCE(r->state_entry_time);
> >   rmb();
> >   new_state = READ_ONCE(*r);
> >   rmb();
> > } while (new_state.state_entry_time != old_entry_time ||
> >  (old_entry_time >> 63));
> >
> >> Alternatively, the easiest way will probably be to add a new VMASSIST,
> >> which allows the guest to opt into the new behaviour.
> >
> > Aah, nice. Yes, this seems to be a sensible option.
> >
> FWIW, this looks a good approach to me as well.

I don't have a problem with this, I would just like to use whatever KVM uses 
in order to be able to reduce code duplication if I ever implement this on 
FreeBSD.

Roger.

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

Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86

[Juergen Gross]

On 19/05/16 15:26, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
> 
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
> 
> Signed-off-by: Juergen Gross 

Sorry, forgot scheduling maintainer. Added.


Juergen

> ---
> V3: add #include  to avoid build error on arm
> V2: remove the x86 do_stolen_accounting() hack
> ---
>  arch/arm/xen/enlighten.c| 17 ++---
>  arch/x86/xen/time.c | 44 ++--
>  drivers/xen/time.c  | 20 
>  include/linux/kernel_stat.h |  1 -
>  include/xen/xen-ops.h   |  1 +
>  kernel/sched/cputime.c  | 10 --
>  6 files changed, 25 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd734..9163b94 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>  
> -static unsigned long long xen_stolen_accounting(int cpu)
> -{
> - struct vcpu_runstate_info state;
> -
> - BUG_ON(cpu != smp_processor_id());
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> -}
> -
>  static void xen_read_wallclock(struct timespec64 *ts)
>  {
>   u32 version;
> @@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
>  
>   register_cpu_notifier(_cpu_notifier);
>  
> - pv_time_ops.steal_clock = xen_stolen_accounting;
> - static_key_slow_inc(_steal_enabled);
> + xen_time_setup_guest();
> +
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index a0a4e55..6be31df 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -11,8 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -31,44 +29,6 @@
>  
>  /* Xen may fire a timer up to this many ns early */
>  #define TIMER_SLOP   10
> -#define NS_PER_TICK  (10LL / HZ)
> -
> -/* snapshots of runstate info */
> -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
> -
> -/* unused ns of stolen time */
> -static DEFINE_PER_CPU(u64, xen_residual_stolen);
> -
> -static void do_stolen_accounting(void)
> -{
> - struct vcpu_runstate_info state;
> - struct vcpu_runstate_info *snap;
> - s64 runnable, offline, stolen;
> - cputime_t ticks;
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - snap = this_cpu_ptr(_runstate_snapshot);
> -
> - /* work out how much time the VCPU has not been runn*ing*  */
> - runnable = state.time[RUNSTATE_runnable] - 
> snap->time[RUNSTATE_runnable];
> - offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
> -
> - *snap = state;
> -
> - /* Add the appropriate number of ticks of stolen time,
> -including any left-overs from last time. */
> - stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
> -
> - if (stolen < 0)
> - stolen = 0;
> -
> - ticks = iter_div_u64_rem(stolen, NS_PER_TICK, );
> - __this_cpu_write(xen_residual_stolen, stolen);
> - account_steal_ticks(ticks);
> -}
>  
>  /* Get the TSC speed from Xen */
>  static unsigned long xen_tsc_khz(void)
> @@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
> *dev_id)
>   ret = IRQ_HANDLED;
>   }
>  
> - do_stolen_accounting();
> -
>   return ret;
>  }
>  
> @@ -431,6 +389,8 @@ static void __init xen_time_init(void)
>   xen_setup_timer(cpu);
>   xen_setup_cpu_clockevents();
>  
> + xen_time_setup_guest();
> +
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  }
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 7107842..2257b66 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
>   return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
>  }
>  
> +static u64 xen_steal_clock(int cpu)
> +{
> + struct vcpu_runstate_info state;
> +
> + BUG_ON(cpu != smp_processor_id());
> + xen_get_runstate_snapshot();
> + return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> +}
> +
>  void xen_setup_runstate_info(int 

Re: [Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

From: Iurii Konovalenko 

Move Xen to the end of physical memory


Can you explain why? As Ian campbell said on the previous version sent 
last year [1], Xen itself (i.e .text, .bss and .data, not the xenheap 
itself) is at most 2MB. Are your constraints such that at a 4GB-2MB 
(i.e. 4096M) of lowmem would not be acceptable?


Also, this patch looks very similar to the one you have sent last year 
[2]. Most of the comments in this thread are still valid, so I will not 
repeat them here.


Regards,



Signed-off-by: Iurii Konovalenko 
---
  xen/Rules.mk   |  1 +
  xen/arch/arm/arm32/head.S  | 21 -
  xen/arch/arm/domain_build.c|  2 +-
  xen/arch/arm/platforms/omap5.c | 17 ++---
  xen/arch/arm/platforms/rcar2.c |  9 -
  xen/arch/arm/setup.c   | 21 ++
++-
  xen/arch/arm/smpboot.c | 33 +
  7 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index feb08d6..fbd34a5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI)   += -DHAS_PCI
  CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
  CFLAGS-$(HAS_PDX)   += -DHAS_PDX
  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB

  ifneq ($(max_phys_cpus),)
  CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e1f29bd..a644d6d 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -262,8 +262,21 @@ cpu_init_done:
  add   r4, r4, r10/* r4 := paddr (boot_pagetable) */
  mov   r5, #0 /* r4:r5 is paddr (boot_pagetable) */
  mcrr  CP64(r4, r5, HTTBR)
+#ifdef ARM32_RELOCATE_OVER_4GB
+teq   r7, #0
+beq   1f /* construct pagetable if CPU0 */

-/* Setup boot_pgtable: */
+/*Skip constructing TLBs for secondary CPUs, use constracted by CPU0*/
+PRINT("- Skip construction pagetable, using CPU0 table @")
+mov   r0, r5
+blputn
+mov   r0, r4
+blputn
+PRINT("  -\r\n")
+bne   skip_constructing
+#endif
+
+1:  /* Setup boot_pgtable: */
  ldr   r1, =boot_second
  add   r1, r1, r10/* r1 := paddr (boot_second) */

@@ -346,6 +359,7 @@ virtphys_clash:
  PRINT("- Unable to build boot page tables - virt and phys addresses clash. 
-\r\n")
  b fail

+skip_constructing:
  1:
  PRINT("- Turning on paging -\r\n")

@@ -427,6 +441,11 @@ paging:
   * setup in init_secondary_pagetables. */

  ldr   r4, =init_ttbr /* VA of HTTBR value stashed by CPU 0 */
+#ifdef ARM32_RELOCATE_OVER_4GB
+ldr   r1, =_start
+sub r4, r1
+add r4, #BOOT_RELOC_VIRT_START
+#endif
  ldrd  r4, r5, [r4]   /* Actual value */
  dsb
  mcrr  CP64(r4, r5, HTTBR)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b48718d..f06792e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1487,7 +1487,7 @@ static void __init find_gnttab_region(struct domain *d,
  if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
  panic("Cannot find a space for the grant table region\n");

-#ifdef CONFIG_ARM_32
+#if defined(CONFIG_ARM_32) && !defined(ARM32_RELOCATE_OVER_4GB)
  /*
   * The gnttab region must be under 4GB in order to work with DOM0
   * using short page table.
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index a49ba62..fe77397 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -25,6 +25,10 @@
  #include 
  #include 

+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
+
  static uint16_t num_den[8][2] = {
  { 0,  0 },  /* not used */
  {  26 *  64,  26 *  125 },  /* 12.0 Mhz */
@@ -132,9 +136,16 @@ static int __init omap5_smp_init(void)
  }

  printk("Set AuxCoreBoot1 to %"PRIpaddr" (%p)\n",
-   __pa(init_secondary), init_secondary);
-writel(__pa(init_secondary), wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
-
+   __pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , init_secondary);
+writel(__pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
  printk("Set AuxCoreBoot0 to 0x20\n");
  writel(0x20, wugen_base + OMAP_AUX_CORE_BOOT_0_OFFSET);

diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index bb25751..26973f6 

Re: [Xen-devel] [PATCH 1/2] xtf: remove setting ROOT path in common.mk

[Andrew Cooper]

On 19/05/16 14:46, Roger Pau Monne wrote:
> Since it might be included from different paths that have different levels
> of nestedness. Also all makefiles that include common.mk already define ROOT
> on their own.
>
> Signed-off-by: Roger Pau Monné 

I really need to work on improving the build system.  This one is
already creaking at the seams.

LGTM - Reviewed-by: Andrew Cooper  and committed.

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

[Xen-devel] [PATCH 2/2] xtf: add a launcher script

[Roger Pau Monne]

Add a simple script that can list the tests relevant to the current
environment and run them. In it's current form it's functionality is quite
limited, and consists in one of this two options:

 - list: list tests relevant to the current environment. This information is
   fetched from each test test-info.json and the output of `xl info`.
 - test: launch a test (which can include creating several VMs) and report
   the results back. The results are printed on the terminal, and the error
   code is set appropriately (see backend/return_code.py for the list of
   possible error codes).

The path to the directory where the tests are stored is mandatory, and
should always be passed to the script. As an example, I've used the
following bash runes in order to launch all tests suitable for my
environment:

for test in `dist/bin/xtf-launcher.py -f dist/tests/ -l`
do
dist/bin/xtf-launcher.py -f dist/tests/ -t $test
echo "Test $test return code: $?"
done

Which yields the following (trimmed for convenience):

Parsing config from dist/tests/cpuid/test-pv64-cpuid.cfg
test-pv64-cpuid took 0s
Parsing config from dist/tests/cpuid/test-pv32pae-cpuid.cfg
test-pv32pae-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm64-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not 
find user xen-qemuuser-shared, starting QEMU as root
test-hvm64-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32pae-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not 
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32pae-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32pse-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not 
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32pse-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not 
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32-cpuid took 0s
test-pv64-cpuid:SUCCESS
test-hvm64-cpuid:   SUCCESS
test-hvm32-cpuid:   SUCCESS
test-hvm32pse-cpuid:SUCCESS
test-hvm32pae-cpuid:SUCCESS
test-pv32pae-cpuid: SUCCESS
Test cpuid return code: 0
[...]

Note that the specific runes to interact with xl have been placed in a
separate file, and that other backends could be easily added provided that
config files suitable for them are also added to XTF tests. A new
--toolstack option should be added then in order to tell the launcher which
toolstack to use.

Signed-off-by: Roger Pau Monné 
---
Cc: andrew.coop...@citrix.com
Cc: ian.jack...@eu.citrix.com
Cc: wei.l...@citrix.com
Cc: anshul.mak...@citrix.com
---
 Makefile   |   2 +-
 tools/launcher/Makefile|  12 
 tools/launcher/backends/__init__.py|   0
 tools/launcher/backends/return_code.py |  28 +
 tools/launcher/backends/xl.py  |  59 +++
 tools/launcher/xtf-launcher.py | 101 +
 6 files changed, 201 insertions(+), 1 deletion(-)
 create mode 100644 tools/launcher/Makefile
 create mode 100644 tools/launcher/backends/__init__.py
 create mode 100644 tools/launcher/backends/return_code.py
 create mode 100644 tools/launcher/backends/xl.py
 create mode 100644 tools/launcher/xtf-launcher.py

diff --git a/Makefile b/Makefile
index fd8c3e0..eda9a25 100644
--- a/Makefile
+++ b/Makefile
@@ -9,7 +9,7 @@ all:
 
 .PHONY: install
 install:
-   @for D in $(wildcard tests/*); do \
+   @for D in $(wildcard tests/* tools/*); do \
[ ! -e $$D/Makefile ] && continue; \
$(MAKE) -C $$D install; \
done
diff --git a/tools/launcher/Makefile b/tools/launcher/Makefile
new file mode 100644
index 000..2c07604
--- /dev/null
+++ b/tools/launcher/Makefile
@@ -0,0 +1,12 @@
+ROOT := $(abspath $(CURDIR)/../..)
+
+include $(ROOT)/build/common.mk
+
+TOOLS := xtf-launcher.py
+BACKENDS := __init__.py xl.py return_code.py
+
+install: $(TOOLS) $(addprefix backends/,$(BACKENDS))
+   @mkdir -p $(DESTDIR)/bin
+   @mkdir -p $(DESTDIR)/bin/backends
+   install -m775 -p $(TOOLS) $(DESTDIR)/bin
+   install -m664 -p $(addprefix backends/,$(BACKENDS)) 
$(DESTDIR)/bin/backends/
diff --git a/tools/launcher/backends/__init__.py 
b/tools/launcher/backends/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/tools/launcher/backends/return_code.py 
b/tools/launcher/backends/return_code.py
new file mode 100644
index 000..509460a
--- /dev/null
+++ b/tools/launcher/backends/return_code.py
@@ -0,0 +1,28 @@
+#
+# Error codes for XTF launcher
+#
+
+# All went fine.
+SUCCESS = 0
+
+# Bug in the launcher.
+ERROR_LAUNCHER = 1
+
+# Test cannot be completed.
+ERROR_SKIP = 2
+
+# Bug in the test code or environment.
+ERROR_ERROR = 3
+
+# Bug in the code under test.
+ERROR_FAILURE = 4
+
+def code_to_str(code):
+   

[Xen-devel] [PATCH 0/2] xtf: add launcher (+1 bugfix)

[Roger Pau Monne]

Hello,

This series contains a bugfix for the build infrastructure and a basic 
launcher for XTF. Patches can also be found in the following git repo:

git://xenbits.xen.org/people/royger/xen-test-framework.git launcher_v1

Thanks, Roger.

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

[Xen-devel] [PATCH 1/2] xtf: remove setting ROOT path in common.mk

[Roger Pau Monne]

Since it might be included from different paths that have different levels
of nestedness. Also all makefiles that include common.mk already define ROOT
on their own.

Signed-off-by: Roger Pau Monné 
---
Cc: andrew.coop...@citrix.com
---
 build/common.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/build/common.mk b/build/common.mk
index 13c468e..6d4c8e8 100644
--- a/build/common.mk
+++ b/build/common.mk
@@ -1,4 +1,3 @@
-ROOT := $(abspath $(CURDIR)/../..)
 DESTDIR ?= $(ROOT)/dist
 PREFIX ?= $(ROOT)
 CC ?= gcc
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86

[Boris Ostrovsky]

On 05/19/2016 09:26 AM, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
>
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

I think this also needs to be acked by (or at least copied to) generic
Linux maintainers.

> ---
>  arch/arm/xen/enlighten.c| 17 ++---
>  arch/x86/xen/time.c | 44 ++--
>  drivers/xen/time.c  | 20 
>  include/linux/kernel_stat.h |  1 -
>  include/xen/xen-ops.h   |  1 +
>  kernel/sched/cputime.c  | 10 --
>  6 files changed, 25 insertions(+), 68 deletions(-)

...

>  }
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 7107842..2257b66 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
>   return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
>  }

(Unrelated to this patch.) Should this include RUNSTATE_offline as well?

-boris


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

From: Oleksandr Dmytryshyn 

This setting is used to adjust starting memory address allocated
for kernel Dom0. To use 'rambase_pfn' setting just add for example
'dom0_rambase_pfn=0x8' to the hypervisor command line. Note that
'dom0_rambase_pfn' should be aligned with the smallest memory chunk
which use xen memory allocator.


Why would a user want to allocate DOM0 RAM bank to a specific address?

If I understand correctly your patch, DOM0 will only able to allocate 
one bank of the given size at the specific address. You also add this 
possibility for guest domain (see patch #4) and try to control where the 
guest memory will be allocated. This will increase a lot the chance of 
the memory allocation to fail.


For instance, the RAM region requested for DOM0 may have been used to 
allocate memory for Xen internal. So you need a way to reserve memory in 
order to avoid Xen using it.


I expect most of the users who want to use direct memory mapped guest to 
know the number of guests which will use this feature.


A such feature is only useful when pass-through a device to the guest on 
platfom without SMMU, so it is by default insecure.


So I would suggest to create a new device-tree binding (or re-use an 
actual one) to reserve memory region to be used for direct memory mapped 
domain.


Those regions could have an identifier to be used later during the 
allocation. This would avoid memory fragmentation, allow multiple RAM 
bank for DOM0,...


Any opinions?



Signed-off-by: Oleksandr Dmytryshyn 
---
  xen/arch/arm/domain_build.c | 24 +---
  xen/common/page_alloc.c | 68 +++--
  xen/include/xen/mm.h|  2 ++
  3 files changed, 75 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2937ff7..b48718d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
  static unsigned int __initdata opt_dom0_max_vcpus;
  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);

+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
+
  int dom0_11_mapping = 1;

  #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
  const unsigned int min_order = get_order_from_bytes(MB(4));
  struct page_info *pg;
  unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;
+paddr_t mem_size = kinfo->unassigned_mem;
  int i;

  bool_t lowmem = is_32bit_domain(d);
@@ -267,7 +272,7 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
  {
  for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
  {
-pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+pg = alloc_domheap_pages_pfn(d, order, MEMF_bits(bits), 
rambase_pfn);
  if ( pg != NULL )
  goto got_bank0;
  }
@@ -284,16 +289,21 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
  /* Now allocate more memory and fill in additional banks */

  order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+
  while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
  {
-pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
+pg = alloc_domheap_pages_pfn(d, order, lowmem ? MEMF_bits(32) : 0,
+ rambase_pfn);


From my understanding, when rambase_pfn is not 0, the memory must be 
allocated contiguously at this specific address. So if the first call of 
alloc_domheap_pages (see a bit above) as failed, then this one will 
always fail because it means that someone has allocated some page in 
this region.



  if ( !pg )
  {
  order --;

  if ( lowmem && order < min_low_order)
  {
-D11PRINT("Failed at min_low_order, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Failed at min_low_order, allow high 
allocations\n");
  order = get_11_allocation_size(kinfo->unassigned_mem);
  lowmem = false;
  continue;
@@ -313,7 +323,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)

  if ( lowmem )
  {
-D11PRINT("Allocation below bank 0, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Allocation below bank 0, allow high 
allocations\n");
  order = 

[Xen-devel] [xen-unstable-smoke test] 94579: tolerable all pass - PUSHED

[osstest service owner]

flight 94579 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94579/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2bb230972c5ddb1ca823f47750b5d46a9d302d0e
baseline version:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4

Last test of basis94557  2016-05-18 19:02:02 Z0 days
Testing same since94579  2016-05-19 11:01:49 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ branch=xen-unstable-smoke
+ revision=2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x2bb230972c5ddb1ca823f47750b5d46a9d302d0e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [PATCH v3] xen: add steal_clock support on x86

[Juergen Gross]

The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.

Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.

Signed-off-by: Juergen Gross 
---
V3: add #include  to avoid build error on arm
V2: remove the x86 do_stolen_accounting() hack
---
 arch/arm/xen/enlighten.c| 17 ++---
 arch/x86/xen/time.c | 44 ++--
 drivers/xen/time.c  | 20 
 include/linux/kernel_stat.h |  1 -
 include/xen/xen-ops.h   |  1 +
 kernel/sched/cputime.c  | 10 --
 6 files changed, 25 insertions(+), 68 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
 
-static unsigned long long xen_stolen_accounting(int cpu)
-{
-   struct vcpu_runstate_info state;
-
-   BUG_ON(cpu != smp_processor_id());
-
-   xen_get_runstate_snapshot();
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
 static void xen_read_wallclock(struct timespec64 *ts)
 {
u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
 
register_cpu_notifier(_cpu_notifier);
 
-   pv_time_ops.steal_clock = xen_stolen_accounting;
-   static_key_slow_inc(_steal_enabled);
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,44 +29,6 @@
 
 /* Xen may fire a timer up to this many ns early */
 #define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
-   struct vcpu_runstate_info state;
-   struct vcpu_runstate_info *snap;
-   s64 runnable, offline, stolen;
-   cputime_t ticks;
-
-   xen_get_runstate_snapshot();
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   snap = this_cpu_ptr(_runstate_snapshot);
-
-   /* work out how much time the VCPU has not been runn*ing*  */
-   runnable = state.time[RUNSTATE_runnable] - 
snap->time[RUNSTATE_runnable];
-   offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
-   *snap = state;
-
-   /* Add the appropriate number of ticks of stolen time,
-  including any left-overs from last time. */
-   stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
-
-   if (stolen < 0)
-   stolen = 0;
-
-   ticks = iter_div_u64_rem(stolen, NS_PER_TICK, );
-   __this_cpu_write(xen_residual_stolen, stolen);
-   account_steal_ticks(ticks);
-}
 
 /* Get the TSC speed from Xen */
 static unsigned long xen_tsc_khz(void)
@@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
*dev_id)
ret = IRQ_HANDLED;
}
 
-   do_stolen_accounting();
-
return ret;
 }
 
@@ -431,6 +389,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
 
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 }
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 7107842..2257b66 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
 }
 
+static u64 xen_steal_clock(int cpu)
+{
+   struct vcpu_runstate_info state;
+
+   BUG_ON(cpu != smp_processor_id());
+   xen_get_runstate_snapshot();
+   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+}
+
 void xen_setup_runstate_info(int cpu)
 {
struct vcpu_register_runstate_memory_area area;
@@ -86,3 +96,13 @@ void xen_setup_runstate_info(int cpu)
BUG();
 }
 
+void __init xen_time_setup_guest(void)
+{
+   pv_time_ops.steal_clock = xen_steal_clock;
+
+   static_key_slow_inc(_steal_enabled);
+   /*
+* We can't set 

Re: [Xen-devel] [PATCH v2] xen: add steal_clock support on x86

[Juergen Gross]

On 19/05/16 07:43, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
> 
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
> 
> Signed-off-by: Juergen Gross 

After creating an arm cross environment I found a build error on arm.
V3 coming soon.


Juergen

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

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

[osstest service owner]

flight 94563 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94563/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 94487

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail blocked in 94487
 build-i386-rumpuserxen6 xen-buildfail   like 94487
 build-amd64-rumpuserxen   6 xen-buildfail   like 94487
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94487
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94487

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
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4
baseline version:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83

Last test of basis94487  2016-05-16 15:18:47 Z2 days
Failing since 94495  2016-05-17 00:15:00 Z2 days4 attempts
Testing same since94563  2016-05-18 23:44:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Edgar E. Iglesias 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Peng Fan 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Jan Beulich]

>>> On 19.05.16 at 14:26,  wrote:
> On 19/05/16 10:41, Jan Beulich wrote:
> On 18.05.16 at 18:32,  wrote:
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -27,6 +27,9 @@
>>>   static unsigned int __initdata opt_dom0_max_vcpus;
>>>   integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>>
>>> +static u64 __initdata opt_dom0_rambase_pfn = 0;
>>> +integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
>>
>> Any addition of a command line option needs to be accompanied by
>> an entry in the command line doc.
>>
>>> @@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
>>> kernel_info *kinfo)
>>>   const unsigned int min_order = get_order_from_bytes(MB(4));
>>>   struct page_info *pg;
>>>   unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
>>> +u64 rambase_pfn = opt_dom0_rambase_pfn;
>>
>> Use of __initdata in a non-__init function.
> 
> All the functions within domain_build.c should have the attributes 
> __init. However, it has been forgotten for half of them.
> 
> I am planning to send a patch to enforce it using the Makefile rules.

I have such a work item (low) on my todo list too, actually.

Jan


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

[Xen-devel] [ovmf baseline-only test] 44433: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44433 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44433/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 81c1460695f783a3f91431b2babea623556a7f5d
baseline version:
 ovmf 720eea6aa80b48acb05c1adc0f835e849d71da97

Last test of basis44430  2016-05-18 20:20:23 Z0 days
Testing same since44433  2016-05-19 06:55:07 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Ma, Maurice 
  Maurice Ma 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 81c1460695f783a3f91431b2babea623556a7f5d
Author: Dandan Bi 
Date:   Tue May 17 11:25:34 2016 +0800

MdeModulePkg/UiApp: Exit function when parameter is unsupported or invalid

When the parameter is unsupported or invalid,
should exit the function.

Cc: Qiu Shumin 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Qiu Shumin 

commit c28306c3d6e0c7721abc937d8f47c3f1ccecf323
Author: Ma, Maurice 
Date:   Tue May 17 05:26:06 2016 +0800

MdeModulePkg: Skip invalid bus number scanning in PciBusDxe driver

When PcdPciDisableBusEnumeration is enabled, the PciBus driver
might get into a dead loop if the secondary bus register on PCI
bridge is not programmed or programmed improperly. Adding this
check to avoid any potential dead loop caused by this.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Lee Leahy 

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

[Xen-devel] [xen-4.6-testing baseline-only test] 44431: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44431 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44431/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44401
 build-armhf   3 host-install(3) broken REGR. vs. 44401
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44401

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44401
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44401
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44401
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 44401

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  aa3cdb6cb666400768950503863b7c3cf508f581
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis44401  2016-05-10 17:29:14 Z8 days
Testing same since44431  2016-05-19 05:19:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kyle J. Temkin 
  Kyle Temkin 
  Shanker Donthineni 
  Stefano Stabellini 
  Stefano Stabellini 
  Vikram Sethi 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Julien Grall]

Hi Jan,

On 19/05/16 10:41, Jan Beulich wrote:

On 18.05.16 at 18:32,  wrote:

--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
  static unsigned int __initdata opt_dom0_max_vcpus;
  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);

+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);


Any addition of a command line option needs to be accompanied by
an entry in the command line doc.


@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
  const unsigned int min_order = get_order_from_bytes(MB(4));
  struct page_info *pg;
  unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;


Use of __initdata in a non-__init function.


All the functions within domain_build.c should have the attributes 
__init. However, it has been forgotten for half of them.


I am planning to send a patch to enforce it using the Makefile rules.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 05/18] xen/arm: allow reassigning of hw interrupts to guest domain

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

From: Andrii Tseglytskyi 

Patch allows reassigning of hardware interrupts from dom0 to
other guest domain.


Can you explain why route_irq_to_guest should  be able to cope with 
reassigning an IRQ rather than having dom0 calling 
XEN_DOMCTL_unbind_pt_irq beforehand?


Also, this patch does more than allowing an IRQ to be reassigned from 
DOM0 to DOMU, it also allows DOMU to DOMU.


Regards,


Signed-off-by: Andrii Tseglytskyi 
Signed-off-by: Iurii Konovalenko 
---
  xen/arch/arm/irq.c | 19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 1f38605..c470613 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -481,12 +481,23 @@ int route_irq_to_guest(struct domain *d, unsigned int 
virq,
  }

  if ( test_bit(_IRQ_GUEST, >status) )
-printk(XENLOG_G_ERR "IRQ %u is already used by domain %u\n",
-   irq, ad->domain_id);
+{
+printk(XENLOG_G_DEBUG "IRQ %u is reassigned from domain %u to domain 
%u\n",
+irq, ad->domain_id, d->domain_id);
+
+retval = gic_remove_irq_from_guest(ad, irq, desc);
+if ( retval )
+printk(XENLOG_G_ERR "failed to remove IRQ %u from domain %u 
(%d)\n",
+irq, ad->domain_id, retval);
+xfree(desc->action);
+desc->action = NULL;
+}
  else
+{
  printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
-retval = -EBUSY;
-goto out;
+   retval = -EBUSY;
+   goto out;
+}
  }

  retval = __setup_irq(desc, 0, action);



--
Julien Grall

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

Re: [Xen-devel] Resend: [PATCH] v3 - Add exclusive locking option to block-iscsi

[Wei Liu]

On Thu, May 19, 2016 at 11:29:32AM +1000, Steven Haigh wrote:
> On 2016-05-09 14:22, Steven Haigh wrote:
> >On 2016-05-05 15:52, Steven Haigh wrote:
> >>On 2016-05-05 12:32, Steven Haigh wrote:
> >>>Overview
> >>>
> >>>If you're using iSCSI, you can mount a target by multiple Dom0
> >>>machines on the same target. For non-cluster aware filesystems, this
> >>>can lead to disk corruption and general bad times by all. The iSCSI
> >>>protocol allows the use of persistent reservations as per the SCSI
> >>>disk spec. Low level SCSI commands for locking are handled by the
> >>>sg_persist program (bundled with sg3_utils package in EL).
> >>>
> >>>The aim of this patch is to create a 'locktarget=y' option specified
> >>>within the disk 'target' command for iSCSI to lock the target in
> >>>exclusive mode on VM start with a key generated from the local systems
> >>>IP, and release this lock on the shutdown of the DomU.
> >>>
> >>>Example Config:
> >>>disk=
> >>>['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']
> >>>
> >>>In writing this, I have also re-factored parts of the script to put
> >>>some things in what I believe to be a better place to make expansion
> >>>easier. This is mainly in removing functions that purely call other
> >>>functions with no actual code execution.
> >>>
> >>>Signed-off-by: Steven Haigh 
> >>>
> >>>(on a side note, first time I've submitted a patch to the list and I'm
> >>>currently stuck on a webmail client, so apologies in advance if this
> >>>all goes wrong ;)
> >>
> >>Changes in v2:
> >>Bugfix: Call find_device to locate the /dev/sdX component of the iSCSI
> >>target before trying to run unlock_device().
> >>
> >>Apologies for this oversight.
> >>
> >
> >Changes in v3:
> >* Split the block-iscsi cleanup into a seperate patch
> >(block-iscsi-locking-v3_01_simplify_block-iscsi.patch).
> >* Add locking in second patch file
> >(block-iscsi-locking-v3_02_add_locking.patch)
> 
> Resend of patches.
> 
> There was a mention of having to add further documentation to
> xl-disk-configuration.txt - however there are no mentions of block-iscsi
> script within the documentation to add. As such, it probably would be out of
> place to add things here.
> 
> The locktarget option is presented directly to the block-iscsi script and
> not evaluated anywhere outside this script.
> 

Sorry I dropped the ball. I think it would be helpful if you or Roger
can send a patch to document all the knobs for block-iscsi. It doesn't
have to be in that file, we can figure out where to add.

FYI we are in the process of making 4.7 release, so the response here
might take a bit longer. FAOD this patch is not targeting 4.7, right?

I'm not too familiar with block script so I think I will
defer this to Roger.  I've also CC'ed Ian for you.

To make a proper patch, please could you read:

http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

Wei.


> -- 
> Steven Haigh
> 
> Email: net...@crc.id.au
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897

> --- block-iscsi.orig2016-05-09 15:12:02.489495212 +1000
> +++ block-iscsi 2016-05-09 15:16:35.447480532 +1000
> @@ -31,16 +31,6 @@
>  echo $1 | sed "s/^\("$2"\)//"
>  }
>  
> -check_tools()
> -{
> -if ! command -v iscsiadm > /dev/null 2>&1; then
> -fatal "Unable to find iscsiadm tool"
> -fi
> -if [ "$multipath" = "y" ] && ! command -v multipath > /dev/null 2>&1; 
> then
> -fatal "Unable to find multipath"
> -fi
> -}
> -
>  # Sets the following global variables based on the params field passed in as
>  # a parameter: iqn, portal, auth_method, user, multipath, password
>  parse_target()
> @@ -52,12 +42,18 @@
>  case $param in
>  iqn=*)
>  iqn=$(remove_label $param "iqn=")
> +if ! command -v iscsiadm > /dev/null 2>&1; then
> +fatal "Could not find iscsiadm tool."
> +fi
>  ;;
>  portal=*)
>  portal=$(remove_label $param "portal=")
>  ;;
>  multipath=*)
>  multipath=$(remove_label $param "multipath=")
> +if ! command -v multipath > /dev/null 2>&1; then
> +fatal "Multipath selected, but no multipath tools found"
> +fi
>  ;;
>  esac
>  done
> @@ -96,40 +92,6 @@
>  fi
>  }
> 
> -# Attaches the target $iqn in $portal and sets $dev to point to the
> -# multipath device
> -attach()
> -{
> -do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --login > 
> /dev/null
> -find_device
> -}
> -
> -# Discovers targets in $portal and checks that $iqn is one of those targets
> -# Also sets the auth parameters to attach the device
> -prepare()
> -{
> -# Check if target is already opened
> -iscsiadm -m session 2>&1 | grep -q "$iqn" && fatal "Device already 
> opened"
> -# Discover portal targets
> -iscsiadm -m 

Re: [Xen-devel] [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

From: Oleksandr Tyshchenko 
In case of missing required property in cfg file
the default value (0x4) should be used.


The memory layout for the guest is static and may change between 
version. By allowing the user to specify the base of the RAM, you expose 
the Xen internal. The user cannot use this option without knowing the 
version of Xen 4.4 and looking at xen/include/public/arch-arm.h.


Also, you need to explain why a user would want to change the 
rambase_pfn. I suspect it is for supporting direct mapped domain. If so, 
I think the way forward is to expose the same memory layout as the 
hardware rather than trying to make the layout half-static/dynamic.


Exposing the same layout as the hardware would allow you to map the 
device MMIOs 1:1 and avoid unnecessary IPA -> PA translation via an 
hypercall (see patch #10).


Lastly, the commit message should explain the restriction. For instance, 
I would have expect to be able to specify any value. However based on 
the check in xl, this is not possible.




Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
  tools/libxc/xc_dom_arm.c | 13 +++--
  tools/libxl/libxl_arm.c  | 10 --
  tools/libxl/libxl_create.c   |  5 +
  tools/libxl/libxl_dom.c  |  6 +++---
  tools/libxl/libxl_internal.h |  1 +
  tools/libxl/libxl_types.idl  |  1 +
  tools/libxl/xl_cmdimpl.c | 13 +
  7 files changed, 38 insertions(+), 11 deletions(-)libxc

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 5ee8eef..96df669 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -415,9 +415,12 @@ int arch_setup_meminit(struct xc_dom_image *dom)
  uint64_t modbase;

  uint64_t ramsize = (uint64_t)dom->total_pages << XC_PAGE_SHIFT;
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+uint64_t guest_ramsize = (GUEST_RAM0_BASE + GUEST_RAM0_SIZE) -
+  guest_rambase;

-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-const uint64_t bankmax[] = GUEST_RAM_BANK_SIZES;
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
+const uint64_t bankmax[] = {guest_ramsize, GUEST_RAM1_SIZE};

  /* Convenient */
  const uint64_t kernbase = dom->kernel_seg.vstart;
@@ -433,8 +436,6 @@ int arch_setup_meminit(struct xc_dom_image *dom)
  xen_pfn_t p2m_size;
  uint64_t bank0end;

-assert(dom->rambase_pfn << XC_PAGE_SHIFT == bankbase[0]);
-
  if ( modsize + kernsize > bankmax[0] )
  {
  DOMPRINTF("%s: Not enough memory for the kernel+dtb+initrd",
@@ -448,11 +449,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
  return -1;
  }

-if ( ramsize > GUEST_RAM_MAX )
+if ( ramsize > (bankmax[0] + bankmax[1]) )
  {
  DOMPRINTF("%s: ram size is too large for guest address space: "
"%"PRIx64" > %llx",
-  __FUNCTION__, ramsize, GUEST_RAM_MAX);
+  __FUNCTION__, ramsize, bankmax[0] + bankmax[1]);
  return -1;
  }

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0af8010..7f9547b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -372,7 +372,10 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
  {
  int res, i;
  const char *name;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};

  for (i = 0; i < GUEST_RAM_BANKS; i++) {
  name = GCSPRINTF("memory@%"PRIx64, bankbase[i]);
@@ -914,7 +917,10 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
  {
  void *fdt = dom->devicetree_blob;
  int i;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};

  const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
  >ramdisk_seg : NULL;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 350e274..1c0579c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -182,6 +182,11 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
  if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
  b_info->target_memkb = b_info->max_memkb;

+#ifdef GUEST_RAM_BASE
+if (b_info->rambase == LIBXL_INVALID_RAM_BASE)
+b_info->rambase = GUEST_RAM0_BASE;


xl is not the only front-end for libxl. So you need to validate the 
value of rambase here.



+#endif
+
  libxl_defbool_setdefault(_info->claim_mode, false);

  

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Jan Beulich]

>>> On 19.05.16 at 13:26,  wrote:
> On May 19, 2016 2:13 PM, Jan Beulich  wrote:
>> >>> "Xu, Quan"  05/19/16 3:35 AM >>>
>> >On May 19, 2016 8:33 AM, Tian, Kevin  wrote:
>> >> A single default value for both IOMMU-side and device-side is anyway
>> >> not optimal. What about introducing a new knob e.g.
>> >> vtd_qi_device_timeout specifically for device-side flush while using
>> >> vtd_qi_timeout for other places? If device-side timeout is not specified, 
>> >> it is
>> then default to vtd_qi_timeout.
>> 
>> There should imo be a single command line option, allowing for two values to
>> be passed (e.g. comma-separated).
> 
> As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation, so we 
> are no need to increasing the value of timeout or introduce a boot-time 
> changed parameter.
> What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC 
> invalidation timeout.

If you're absolutely certain no-one will ever find a need to increase
that value - sure.

> For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout', which 
> is boot-time changed, and 1 ms by default.

One question is whether making this a VT-d specific command line
option is a good idea: Other IOMMU implementations ought to be
in need of doing device IOTLB invalidation too, at least sooner or
later.

The other question is whether any timeout lower than the current
one can be considered safe (and hence is usable as a default).

Jan


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

Re: [Xen-devel] [PATCH RFC 17/18] tools: Introduce ARM32_SEPAR_MEM_SPLIT option

[Wei Liu]

On Wed, May 18, 2016 at 07:32:40PM +0300, Andrii Anisov wrote:
> From: Iurii Mykhalskyi 
> 
> This option enables separate memory allocation in
> low & over 4GB address space.
> With this option enabled in domain config files
> "memory" parameter are used to specify domain low memory
> "memory_high" - to specify over 4GB allocated memory
> 
> If you didn't specify high memory with this option enabled,
> domain memory will be limited to 4GB (zone 20)
> 

I don't think such option is future proof enough -- what if you suddenly
want several memory regions?

I haven't actually looked at the code, merely asking some (perhaps dumb)
questions first.

Wei.

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

Re: [Xen-devel] [PATCH RFC 12/18] libxl: Fix unneeded domain reboot during destroy routine

[Wei Liu]

On Wed, May 18, 2016 at 07:32:35PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik 
> 
> During domain destroy we should change its state from "alive"
> to "dying" to prevent reboot because of watchdog timeout.
> 
> Signed-off-by: Viktor Kleinik 
> ---
>  tools/libxl/libxl.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 1366177..ac50bda 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1634,6 +1634,10 @@ void libxl__destroy_domid(libxl__egc *egc, 
> libxl__destroy_domid_state *dis)
>  dis->drs.callback = devices_destroy_cb;
>  dis->drs.force = 1;
>  libxl__devices_destroy(egc, >drs);
> +rc = xc_domain_destroy(ctx->xch, domid);
> +if (rc < 0) {
> +LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy 
> failed for %d", domid);
> +}

What is the code path here? Have you checked the other place which calls
xc_domain_destroy? Now there are two calls to xc_domain_destroy, which
doesn't seem right to me.

Wei.

>  return;
>  
>  out:
> -- 
> 2.8.2
> 
> 
> ___
> 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 RFC 04/18] libxl: add ability to set rambase_pfn via cfg file

[Wei Liu]

On Wed, May 18, 2016 at 07:32:27PM +0300, Andrii Anisov wrote:
> From: Oleksandr Tyshchenko 
> 
> In case of missing required property in cfg file
> the default value (0x4) should be used.

Assuming this is absolutely needed (whether it is the case I don't
know, I will leave that to ARM maintainers)...

> 
> Signed-off-by: Oleksandr Tyshchenko 
> Signed-off-by: Iurii Konovalenko 
> Signed-off-by: Iurii Mykhalskyi 
[...]
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1699f32..5b0b50a 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -100,6 +100,7 @@
>  #define LIBXL_HVM_EXTRA_MEMORY 2048
>  #define LIBXL_MIN_DOM0_MEM (128*1024)
>  #define LIBXL_INVALID_GFN (~(uint64_t)0)
> +#define LIBXL_INVALID_RAM_BASE (~(uint64_t)0)
>  /* use 0 as the domid of the toolstack domain for now */
>  #define LIBXL_TOOLSTACK_DOMID 0
>  #define QEMU_SIGNATURE "DeviceModelRecord0002"
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 502a148..b6cc8d2 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -416,6 +416,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("target_memkb",MemKB),
>  ("video_memkb", MemKB),
>  ("shadow_memkb",MemKB),
> +("rambase", uint64, {'init_val': 'LIBXL_INVALID_RAM_BASE'}),

Please make this ARM specific.

You would also need to provide a LIBXL_HAVE macro in libxl.h. See
various examples there.


>  ("rtc_timeoffset",  uint32),
>  ("exec_ssidref",uint32),
>  ("exec_ssid_label", string),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 9a2870e..28d57c3 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include  /* for utsname in xl info */
>  #include 
> +#include 

I don't think you need this. In fact, please don't do this. :-)

>  #include 
>  #include 
>  #include 
> @@ -1352,6 +1353,18 @@ static void parse_config_data(const char 
> *config_source,
>  if (!xlu_cfg_get_long (config, "maxmem", , 0))
>  b_info->max_memkb = l * 1024;
>  
> +#ifdef GUEST_RAM_BASE
> +if (!xlu_cfg_get_long (config, "rambase_pfn", , 0)) {
> +/* TODO add more detailed check for valid value */
> +uint64_t rambase = (uint64_t)l << XC_PAGE_SHIFT;
> +if (rambase > (GUEST_RAM0_BASE + GUEST_RAM0_SIZE)) {
> +fprintf(stderr, "ERROR: invalid value 0x%lx for 
> \"rambase_pfn\"\n", l);
> +exit (1);
> +}
> +b_info->rambase = rambase;
> +}
> +#endif
> +
>  if (!xlu_cfg_get_long (config, "vcpus", , 0)) {
>  vcpus = l;
>  if (libxl_cpu_bitmap_alloc(ctx, _info->avail_vcpus, l)) {
> -- 
> 2.8.2
> 
> 
> ___
> 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 RFC 06/18] libxl: parse config data during domain reboot

[Wei Liu]

On Wed, May 18, 2016 at 07:32:29PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik 
> 
> We need to parse config data during domain reboot
> to get correct I/O memory regions for mapping.
> 
> Signed-off-by: Viktor Kleinik 
> ---
>  tools/libxl/xl_cmdimpl.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 28d57c3..98a46bc 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2988,6 +2988,21 @@ start:
>  d_config.c_info.name = strdup(common_domname);
>  }
>  
> + if (config_file) {
> + libxl_domain_config_init(_config);
> +
> + ret = libxl_read_file_contents(ctx, config_file,
> +_data, _len);
> + if (ret) {
> + LOG("Failed to read config file: %s: %s\n",
> + config_file, strerror(errno));
> + goto out;
> + }
> +
> + parse_config_data(config_file, config_data, config_len,
> +   _config);
> + }
> +

I think libxl has already preserve the configuration for you?

This will break device hotplug I think.

Wei.

>  /*
>   * XXX FIXME: If this sleep is not there then domain
>   * re-creation fails sometimes.
> -- 
> 2.8.2
> 
> 
> ___
> 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 RFC 01/18] xen/tools: Fix virtual disks helper scripts.

[Wei Liu]

On Wed, May 18, 2016 at 07:32:24PM +0300, Andrii Anisov wrote:
> This patch makes virtual disks helper scripts be functional
> in busybox environment. Actually we call sh insteand of bash and
> rewrite loop with counter to be properly parsed by ash.
> 
> Signed-off-by: Andrii Anisov 
> Signed-off-by: Andrii Tseglytskyi 
> ---
>  tools/hotplug/Linux/block| 2 +-
>  tools/hotplug/Linux/locking.sh   | 9 +++--
>  tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
> index 8d2ee9d..6a725db 100644
> --- a/tools/hotplug/Linux/block
> +++ b/tools/hotplug/Linux/block
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/sh
>  
>  dir=$(dirname "$0")
>  . "$dir/block-common.sh"
> diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
> index c6a7e96..b8e9515 100644
> --- a/tools/hotplug/Linux/locking.sh
> +++ b/tools/hotplug/Linux/locking.sh
> @@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
>  
>  _setlockfd()
>  {
> +local lock_
>  local i
> -for ((i = 0; i < ${#_lockdict}; i++))
> -do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> +let i=0
> +
> +for lock_ in _lockdict ;
> +do
> +[ -z "$lock_" -o "$lock_" = "$1" ] && break
> +(( i++ ))
>  done
>  _lockdict[$i]="$1"
>  let _lockfd=200+i
> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in 
> b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> index d5d0b69..42e46e3 100644
> --- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> @@ -51,7 +51,7 @@ sigerr() {
>fatal "$0 failed; error detected."
>  }
>  
> -trap sigerr ERR
> +#trap sigerr ERR

I know why you want to comment this out but you basically break the
error handling protocol. See the fatal function at the beginning of this
file.

So we can't take this patch. And you should probably fix your own
environment, too.

Wei.

>  
>  
>  ##
> -- 
> 2.8.2
> 
> 
> ___
> 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 RFC 09/18] tools: Allow to cross-compile xentop

[Wei Liu]

On Wed, May 18, 2016 at 07:32:32PM +0300, Andrii Anisov wrote:
> From: Oleksandr Dmytryshyn 
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Iurii Konovalenko 
> ---
>  tools/xenstat/Makefile | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/tools/xenstat/Makefile b/tools/xenstat/Makefile
> index 901be4a..440b1b7 100644
> --- a/tools/xenstat/Makefile
> +++ b/tools/xenstat/Makefile
> @@ -4,12 +4,10 @@ include $(XEN_ROOT)/tools/Rules.mk
>  SUBDIRS :=
>  SUBDIRS += libxenstat
>  
> -# This doesn't cross-compile (cross-compile environments rarely have curses)
> -ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> +# This compiles if compiler environment has curses

You should have a option that is set by configure to guard this.

Wei.

>  ifeq ($(wildcard /usr/include/curses.h),/usr/include/curses.h)
>  SUBDIRS += xentop
>  endif
> -endif
>  
>  .PHONY: all install clean distclean
>  
> -- 
> 2.8.2
> 
> 
> ___
> 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 RFC 07/18] tools/misc: Modify Xen watchdog daemon

[Wei Liu]

On Wed, May 18, 2016 at 07:32:30PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik 
> 
> This change allows watchdog daemon to work thru watchdog device
> on the file system.
> 
> Signed-off-by: Viktor Kleinik 

The commit message is not clear enough as to why you want to delete a
bunch of code. I'm afraid I'm not able to review a patch like this.

Doesn't this patch break existing behaviour?

Wei.

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

Re: [Xen-devel] [PATCH RFC 08/18] tools/misc: Set timeout value from watchdog daemon

[Wei Liu]

On Wed, May 18, 2016 at 07:32:31PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik 
> 
> Signed-off-by: Viktor Kleinik 

I have a feeling this can probably be squashed into previous patch. But
please don't squash this yet, let's start with better commit message.

Wei.

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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Xu, Quan]

On May 19, 2016 2:13 PM, Jan Beulich  wrote:
> >>> "Xu, Quan"  05/19/16 3:35 AM >>>
> >On May 19, 2016 8:33 AM, Tian, Kevin  wrote:
> >> A single default value for both IOMMU-side and device-side is anyway
> >> not optimal. What about introducing a new knob e.g.
> >> vtd_qi_device_timeout specifically for device-side flush while using
> >> vtd_qi_timeout for other places? If device-side timeout is not specified, 
> >> it is
> then default to vtd_qi_timeout.
> 
> There should imo be a single command line option, allowing for two values to
> be passed (e.g. comma-separated).
> 

As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation, so we are 
no need to increasing the value of timeout or introduce a boot-time changed 
parameter.
What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC 
invalidation timeout.

For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout', which is 
boot-time changed, and 1 ms by default.

Quan

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

Re: [Xen-devel] [PATCH RFC 03/18] xen/arm: allow to allocate 1/128/256/512 Mb memory chunks

[Julien Grall]

Hello,

On 18/05/16 17:32, Andrii Anisov wrote:

From: Andrii Tseglytskyi 

This is done to allow possibility of having 1 to 1 memory mapping chunks
with size 1/128/256/512 Mb what can sagnificantly decrease time of memory


significantly


allocation and fragmentation for 1-to-1 mapped domains.


I cannot find any patch in this series to add support for direct memory 
mapped guest.


Can you give details on why this patch would be an improvement for any 
guest and how you choose the new allocations size?


Regards,



Signed-off-by: Andrii Tseglytskyi 
Signed-off-by: Iurii Konovalenko 
---
  tools/libxc/xc_dom_arm.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index aeaba54..5ee8eef 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -33,7 +33,11 @@
  #define LPAE_SHIFT 9

  #define PFN_4K_SHIFT  (0)
+#define PFN_1M_SHIFT  (PFN_4K_SHIFT + 8)
  #define PFN_2M_SHIFT  (PFN_4K_SHIFT+LPAE_SHIFT)
+#define PFN_128M_SHIFT  (PFN_2M_SHIFT + 6)
+#define PFN_256M_SHIFT  (PFN_128M_SHIFT + 1)
+#define PFN_512M_SHIFT  (PFN_256M_SHIFT + 1)
  #define PFN_1G_SHIFT  (PFN_2M_SHIFT+LPAE_SHIFT)
  #define PFN_512G_SHIFT (PFN_1G_SHIFT+LPAE_SHIFT)

@@ -359,11 +363,31 @@ static int populate_guest_memory(struct xc_dom_image *dom,
  if ( rc < 0 ) break;
  if ( rc > 0 ) continue;

+rc = populate_one_size(dom, PFN_512M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_256M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_128M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
  rc = populate_one_size(dom, PFN_2M_SHIFT,
 base_pfn + pfn, , extents);
  if ( rc < 0 ) break;
  if ( rc > 0 ) continue;

+rc = populate_one_size(dom, PFN_1M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
  rc = populate_one_size(dom, PFN_4K_SHIFT,
 base_pfn + pfn, , extents);
  if ( rc < 0 ) break;



--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()

[Wei Liu]

On Thu, May 19, 2016 at 10:11:35AM +0200, Dario Faggioli wrote:
> or (even in cases where there is no race, e.g., outside
> of Credit2) avoid using a time sample which may be rather
> old, and hence stale.
> 
> In fact, we should only sample NOW() from _inside_
> the critical region within which the value we read is
> used. If we don't, in case we have to spin for a while
> before entering the region, when actually using it:
> 
>  1) we will use something that, at the veryy least, is
> not really "now", because of the spinning,
> 
>  2) if someone else sampled NOW() during a critical
> region protected by the lock we are spinning on,
> and if we compare the two samples when we get
> inside our region, our one will be 'earlier',
> even if we actually arrived later, which is a
> race.
> 
> In Credit2, we see an instance of 2), in runq_tickle(),
> when it is called by csched2_context_saved() as it samples
> NOW() before acquiring the runq lock. This makes things
> look like the time went backwards, and it confuses the
> algorithm (there's even a d2printk() about it, which would
> trigger all the time, if enabled).
> 
> In RTDS, something similar happens in repl_timer_handler(),
> and there's another instance in schedule() (in generic code),
> so fix these cases too.
> 
> While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
> a little as well (removing a pointless initialization, and
> moving the sampling a bit closer to its use). These two hunks
> entail no further functional changes.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Wei Liu 


Subject to review from Meng and George:

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Julien Grall]

Hello,

On 18/05/16 20:17, Meng Xu wrote:

On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
 wrote:

This series RFC patches from the currently ongoing production project.
This patch series presents changes needed to fit the system into
customer requirements as well as workaround limitations of the
Jacinto6 SoC.


IMHO, it will be better, if possible, to describe the exact customer
requirements this patch series tries to satisfy. I'm curious at what
the requirements are and if the requirements are general enough for
many other customers. :-)


I agree with Meng here. We need to understand the use case and see if it 
is possible to generalize it for everyone.


I looked quickly at this patch series and noticed that most of patches 
miss details on why it is necessary and what you are trying solve. Can 
you give us more details?



Similarly, what are the limitations for the Jacinto6 SoC that need to
be workaround? If the board is not supported by Xen, can we say Xen
will support the board with the warkaround?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

[Paolo Bonzini]

On 18/05/2016 21:34, Peter Zijlstra wrote:
>> I don't know of any enterprise distro that is shipping anything
>> > more modern than 4.1?
> RHEL 7-- v3.10
> SLES 12   -- v3.12
> Debian Jessie -- v3.16
> Ubuntu 16.04 LTS  -- v4.4
> 
> But waiting for the major enterprise distros (RHEL/SLES) would mean
> another decade or so before people start using it. We don't usually wait
> this long for anything.

We're looking at converting a few specific spinlocks to qspinlock in
RHEL, though we cannot convert all of them due to the spin_lock_t ABI.
It won't get into customer's hands for a while of course.

Thanks,

Paolo

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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Stefano Stabellini]

On Thu, 19 May 2016, Jan Beulich wrote:
> >>> On 19.05.16 at 12:40,  wrote:
> > On Thu, 19 May 2016, Juergen Gross wrote:
> >> > Alternatively, the easiest way will probably be to add a new VMASSIST,
> >> > which allows the guest to opt into the new behaviour.
> >> 
> >> Aah, nice. Yes, this seems to be a sensible option.
> > 
> > If you are referring to VM_ASSIST, it is only available on x86. I
> > suggest we use a feature flag instead.
> 
> A feature flag can only be checked by the guest, not set. How
> about enabling VMASSIST for ARM?

Sure

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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Jan Beulich]

>>> On 19.05.16 at 12:40,  wrote:
> On Thu, 19 May 2016, Juergen Gross wrote:
>> > Alternatively, the easiest way will probably be to add a new VMASSIST,
>> > which allows the guest to opt into the new behaviour.
>> 
>> Aah, nice. Yes, this seems to be a sensible option.
> 
> If you are referring to VM_ASSIST, it is only available on x86. I
> suggest we use a feature flag instead.

A feature flag can only be checked by the guest, not set. How
about enabling VMASSIST for ARM?

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary

[Stefano Stabellini]

On Thu, 19 May 2016, Julien Grall wrote:
> Hi Peng,
> 
> On 19/05/16 10:22, Peng Fan wrote:
> > CPU0 boots up secondary CPUs one by one. Before booting
> > one secondary CPU, CPU0 will assign hwid to smp_up_cpu
> > and flush cache. After the secondary CPU boots up,
> 
> NIT: s/the/a/
> 
> > CPU0 will assign MPIDR_INVALID to smp_up_cpu and flush
> > cache.
> > 
> > There is no need for secondary CPUs to assign MPIDR_INVALID
> > to smp_up_cpu. So, drop it.
> > 
> > Signed-off-by: Peng Fan 
> > Cc: Julien Grall 
> > Cc: Stefano Stabellini 
> 
> Reviewed-by: Julien Grall 


This is a cleanup, no need to commit it now. I'll add it to the 4.8
branch.



> 
> > ---
> >   xen/arch/arm/smpboot.c | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index c5109bf..6b3c157 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -309,7 +309,6 @@ void start_secondary(unsigned long boot_phys_offset,
> >   smp_wmb();
> > 
> >   /* Now report this CPU is up */
> > -smp_up_cpu = MPIDR_INVALID;
> >   cpumask_set_cpu(cpuid, _online_map);
> >   smp_wmb();
> > 
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Stefano Stabellini]

On Thu, 19 May 2016, Juergen Gross wrote:
> > Alternatively, the easiest way will probably be to add a new VMASSIST,
> > which allows the guest to opt into the new behaviour.
> 
> Aah, nice. Yes, this seems to be a sensible option.

If you are referring to VM_ASSIST, it is only available on x86. I
suggest we use a feature flag instead.

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

Re: [Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary

[Julien Grall]

Hi Peng,

On 19/05/16 10:22, Peng Fan wrote:

CPU0 boots up secondary CPUs one by one. Before booting
one secondary CPU, CPU0 will assign hwid to smp_up_cpu
and flush cache. After the secondary CPU boots up,


NIT: s/the/a/


CPU0 will assign MPIDR_INVALID to smp_up_cpu and flush
cache.

There is no need for secondary CPUs to assign MPIDR_INVALID
to smp_up_cpu. So, drop it.

Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 


Reviewed-by: Julien Grall 

Regards,


---
  xen/arch/arm/smpboot.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c5109bf..6b3c157 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -309,7 +309,6 @@ void start_secondary(unsigned long boot_phys_offset,
  smp_wmb();

  /* Now report this CPU is up */
-smp_up_cpu = MPIDR_INVALID;
  cpumask_set_cpu(cpuid, _online_map);
  smp_wmb();




--
Julien Grall

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

Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus

[Dario Faggioli]

Since, AFAIUI, you're interested in non-Linux guests' perspective, I'm
adding Roger (and avoiding trimming, for his benefit), who can tell us
what he thinks of this all, from the FreeBSD point of view.

On Thu, May 19, 2016 at 10:49 AM, Juergen Gross  wrote:
> On 19/05/16 10:09, Andrew Cooper wrote:
>> On 19/05/2016 08:53, Juergen Gross wrote:
>>> A guest kernel can use the vcpu_op hypercall sub-op
>>> VCPUOP_register_runstate_memory_area to get a copy of the
>>> vcpu_runstate_info of a vcpu mapped into its memory. As this structure
>>> has no update indicator it is only save to be read by the vcpu it is
>>> containing the runstate information of.
>>>
>>> Being able to read the runstate info of another cpu is required e.g.
>>> by the Linux kernel to be able to calculate vruntime: see
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html
>>>
>>> I'd suggest to add an "update in progress" indicator in the highest
>>> bit of vcpu_runstate_info->state_entry_time as this structure element is
>>> already used to detect vcpu scheduling when vcpu_runstate_info is read
>>> by the owning vcpu.
>>>
>>> The question is how to enable setting this indicator, as the guest must
>>> be able to cope with it (I believe the Linux kernel would just run fine,
>>> but we can't be sure this is true for all guests).
>>>
>>> I see the following possible solutions:
>>>
>>> a) Introduce a new vcpu_op hypercall sub-op for mapping the
>>>vcpu_runstate_info with update indicator support (a guest supporting
>>>this would try the new sub-op first and could fall back to
>>>VCPUOP_register_runstate_memory_area in case of ENOSYS).
>>>
>>> b) Add a virtual MSR to switch on the feature (not being able to set the
>>>appropriate bit would indicate the feature not being available). This
>>>is the variant KVM is using. Does ARM have something like MSRs?
>>>
>>> c) Add another hypercall to switch on the feature (similar to
>>>XENVER_get_features we could have a XENVER_set_features).
>>>
>>> Any preferences?
>>
>> However, irrespective of how you signal the request for new behaviour,
>> you should see about using a lockless clock rather than a single bit, as
>> a single bit can't indicate the case where a complete update has
>> occurred between two samplings.  This will probably require an extension
>> to the current implementation, at which point you might be able to add a
>> capability field as well.
>
> That's the reason I've chosen state_entry_time as the home for the new
> bit. state_entry_time is guaranteed to change between two updates. So
> the logic would look like the following:
>
> do {
>   old_entry_time = READ_ONCE(r->state_entry_time);
>   rmb();
>   new_state = READ_ONCE(*r);
>   rmb();
> } while (new_state.state_entry_time != old_entry_time ||
>  (old_entry_time >> 63));
>
>> Alternatively, the easiest way will probably be to add a new VMASSIST,
>> which allows the guest to opt into the new behaviour.
>
> Aah, nice. Yes, this seems to be a sensible option.
>
FWIW, this looks a good approach to me as well.

Regards,
Dario

-- 
<> (Raistlin Majere)
---
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94573: trouble: blocked/broken

[osstest service owner]

flight 94573 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94573/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  102 days
Testing same since93977  2016-05-10 11:09:16 Z8 days   23 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space

[Jan Beulich]

>>> On 18.05.16 at 18:32,  wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI)   += -DHAS_PCI
>  CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
>  CFLAGS-$(HAS_PDX)   += -DHAS_PDX
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> +CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB

Things like this should be done via Kconfig nowadays.

Jan


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Jan Beulich]

>>> On 18.05.16 at 18:32,  wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -27,6 +27,9 @@
>  static unsigned int __initdata opt_dom0_max_vcpus;
>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>  
> +static u64 __initdata opt_dom0_rambase_pfn = 0;
> +integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);

Any addition of a command line option needs to be accompanied by
an entry in the command line doc.

> @@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct 
> kernel_info *kinfo)
>  const unsigned int min_order = get_order_from_bytes(MB(4));
>  struct page_info *pg;
>  unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
> +u64 rambase_pfn = opt_dom0_rambase_pfn;

Use of __initdata in a non-__init function.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -583,16 +583,17 @@ static void check_low_mem_virq(void)
>  }
>  }
>  
> -/* Allocate 2^@order contiguous pages. */
> -static struct page_info *alloc_heap_pages(
> +/* Allocate 2^@order contiguous pages at given pfn. */
> +static struct page_info *alloc_heap_pages_pfn(
>  unsigned int zone_lo, unsigned int zone_hi,
>  unsigned int order, unsigned int memflags,
> -struct domain *d)
> +struct domain *d, xen_pfn_t pfn)

Altering generic allocation interfaces like this, for a boot time only
purpose, doesn't seem warranted. Please reconsider the entire
approach.

Jan


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

Re: [Xen-devel] [PATCH RFC 10/18] xen: arm: add batch support to the XENMEM_p2m_lookup operation

[Jan Beulich]

>>> On 18.05.16 at 18:32,  wrote:

First of all, the description is misleading: You don't add anything
_to_ XENMEM_p2m_lookup, you simply add this new sub-op.

And then, we've had requests to add something like this more
than once, and so far they've always got rejected. See the
removed XENMEM_translate_gpfn_list. Hence an empty
description here is definitely insufficient, as you'll need to
explain why _now_ all of the sudden this is needed. Perhaps
it would have been a good idea if you had asked up front
whether something like this can be re-added, or what
alternatives there are without doing so.

I'll therefore not comment on the actual patch, which also has
issues (but which aren't worth addressing if the whole thing is
going to get dropped).

Jan


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

Re: [Xen-devel] [PATCH RFC 02/18] kbdif: add raw events passing

[Jan Beulich]

>>> On 18.05.16 at 18:32,  wrote:
> xenkbd_raw carries raw linux event structure -- type, code & value,
> which allows support of more devices (e.g. touchscreens).

The "raw Linux event structure" may change, so you can't defer to
it. All related definitions would need to be added here, namely ...

> @@ -68,6 +70,13 @@ struct xenkbd_position
>  int32_t rel_z;   /* relative Z motion (wheel) */
>  };
>  
> +struct xenkbd_raw {
> +uint8_t type;/* XENKBD_TYPE_RAW */
> +uint16_t input_type;
> +uint16_t code;
> +int32_t value;
> +};

... values to be contained in the three fields which don't have a
comment.

Furthermore it looks like it's the backend that would produce the
new type, and hence there would need to be a means for the
frontend to enable their producing (or else an unsuspecting
frontend might get confused). The way such negotiation works
(likely through xenbus) would need to be documented here, too.

Jan


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

Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()

[George Dunlap]

On 19/05/16 09:11, Dario Faggioli wrote:
> or (even in cases where there is no race, e.g., outside
> of Credit2) avoid using a time sample which may be rather
> old, and hence stale.
> 
> In fact, we should only sample NOW() from _inside_
> the critical region within which the value we read is
> used. If we don't, in case we have to spin for a while
> before entering the region, when actually using it:
> 
>  1) we will use something that, at the veryy least, is
> not really "now", because of the spinning,
> 
>  2) if someone else sampled NOW() during a critical
> region protected by the lock we are spinning on,
> and if we compare the two samples when we get
> inside our region, our one will be 'earlier',
> even if we actually arrived later, which is a
> race.
> 
> In Credit2, we see an instance of 2), in runq_tickle(),
> when it is called by csched2_context_saved() as it samples
> NOW() before acquiring the runq lock. This makes things
> look like the time went backwards, and it confuses the
> algorithm (there's even a d2printk() about it, which would
> trigger all the time, if enabled).
> 
> In RTDS, something similar happens in repl_timer_handler(),
> and there's another instance in schedule() (in generic code),
> so fix these cases too.
> 
> While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
> a little as well (removing a pointless initialization, and
> moving the sampling a bit closer to its use). These two hunks
> entail no further functional changes.
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

I agree this is a fairly low-risk bugfix that should be considered for 4.7.

 -George

> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Wei Liu 
> ---
>  xen/common/sched_credit2.c |4 ++--
>  xen/common/sched_rt.c  |7 +--
>  xen/common/schedule.c  |4 +++-
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index f95e509..1933ff1 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1028,7 +1028,7 @@ static void
>  csched2_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
> -s_time_t now = 0;
> +s_time_t now;
>  
>  /* Schedule lock should be held at this point. */
>  
> @@ -1085,8 +1085,8 @@ static void
>  csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
> -s_time_t now = NOW();
>  spinlock_t *lock = vcpu_schedule_lock_irq(vc);
> +s_time_t now = NOW();
>  
>  BUG_ON( !is_idle_vcpu(vc) && svc->rqd != RQD(ops, vc->processor));
>  
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index aa3ffd2..0946101 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1198,7 +1198,7 @@ static void
>  rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
>  {
>  struct rt_vcpu * const svc = rt_vcpu(vc);
> -s_time_t now = NOW();
> +s_time_t now;
>  bool_t missed;
>  
>  BUG_ON( is_idle_vcpu(vc) );
> @@ -1225,6 +1225,7 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu 
> *vc)
>   * If a deadline passed while svc was asleep/blocked, we need new
>   * scheduling parameters (a new deadline and full budget).
>   */
> +now = NOW();
>  
>  missed = ( now >= svc->cur_deadline );
>  if ( missed )
> @@ -1394,7 +1395,7 @@ rt_dom_cntl(
>   * from the replq and does the actual replenishment.
>   */
>  static void repl_timer_handler(void *data){
> -s_time_t now = NOW();
> +s_time_t now;
>  struct scheduler *ops = data;
>  struct rt_private *prv = rt_priv(ops);
>  struct list_head *replq = rt_replq(ops);
> @@ -1406,6 +1407,8 @@ static void repl_timer_handler(void *data){
>  
>  spin_lock_irq(>lock);
>  
> +now = NOW();
> +
>  /*
>   * Do the replenishment and move replenished vcpus
>   * to the temporary list to tickle.
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 80fea39..5e35310 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1320,7 +1320,7 @@ static void vcpu_periodic_timer_work(struct vcpu *v)
>  static void schedule(void)
>  {
>  struct vcpu  *prev = current, *next = NULL;
> -s_time_t  now = NOW();
> +s_time_t  now;
>  struct scheduler *sched;
>  unsigned long*tasklet_work = _cpu(tasklet_work_to_do);
>  bool_ttasklet_work_scheduled = 0;
> @@ -1355,6 +1355,8 @@ static void schedule(void)
>  
>  lock = pcpu_schedule_lock_irq(cpu);
>  
> +now = NOW();
> +
>  stop_timer(>s_timer);
>  
>  /* get policy-specific decision on scheduling... */
>