[Xen-devel] [linux-4.1 test] 87295: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 86830 pass in 
87295
 test-armhf-armhf-xl-xsm  16 guest-start.2  fail in 87117 pass in 86830
 test-armhf-armhf-xl  11 guest-startfail in 87117 pass in 87295
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 87117 pass 
in 87295
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail in 87204 pass in 87295
 test-armhf-armhf-xl   15 guest-start/debian.repeat fail in 87204 pass in 87295
 test-armhf-armhf-xl-cubietruck 11 guest-start  fail in 87204 pass in 87295
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 87117
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 87117
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87204
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 87204
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
87204
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat  fail pass in 87204

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 87117 like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 87204 like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399

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

version targeted for testing:
 linux7f30737678023b5becaf0e2e012665f71b886a7d
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z  101 days

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 20d00edf21d2f2144921622891d8b59a1553cd83
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  108 days
Failing since 65593  2015-12-08 23:44:51 Z  108 days  121 attempts
Testing same since87299  2016-03-25 10:15:49 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Juliano Ciocari 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leo Duran 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Marvin Häuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org

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

[osstest service owner]

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

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  04119085f5a2a135e5161535b8821e1aa0d7db8a
baseline version:
 xen  a67e68c6310e983c76a63cc4863b46ddde6d84db

Last test of basis87332  2016-03-25 16:08:28 Z0 days
Testing same since87360  2016-03-25 21:11:11 Z0 days2 attempts


People who touched revisions under test:
  George Dunlap 
  George Dunlap 
  Ian Jackson 

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=04119085f5a2a135e5161535b8821e1aa0d7db8a
+ . ./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 
04119085f5a2a135e5161535b8821e1aa0d7db8a
+ branch=xen-unstable-smoke
+ revision=04119085f5a2a135e5161535b8821e1aa0d7db8a
+ . ./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
+ '[' x04119085f5a2a135e5161535b8821e1aa0d7db8a = 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 $!;

[Xen-devel] [xen-unstable-smoke test] 87360: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 87332

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  04119085f5a2a135e5161535b8821e1aa0d7db8a
baseline version:
 xen  a67e68c6310e983c76a63cc4863b46ddde6d84db

Last test of basis87332  2016-03-25 16:08:28 Z0 days
Testing same since87360  2016-03-25 21:11:11 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  George Dunlap 
  Ian Jackson 

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


Not pushing.


commit 04119085f5a2a135e5161535b8821e1aa0d7db8a
Author: George Dunlap 
Date:   Thu Mar 24 17:17:24 2016 +

xl: Return an error on failed cd-insert

This makes xl more useful in scripts.

The strange thing about this is that the internal cd_insert function
*already* returned something appropriate, and cd-eject was using it,
but cd-insert wasn't.

Also:

* Rework cd_insert to return EXIT_FAILURE and EXIT_SUCCESS rather than
magic constants

* Use 'r' for non-libxl return code, as specified in CODING_STYLE

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 

commit 0614c454209ac67016e2296577abfee9e9dcb012
Author: George Dunlap 
Date:   Thu Mar 24 17:17:23 2016 +

xl: Make set_memory_target return an error code on failure

Also move the rc -> shell code translation into set_memory_max() to
make the two functions consistent with each other, and with other
similar examples in xl_cmdimpl.c

Change a 'long long' to "int64_t" while we're at it.

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 

commit 26dbc93a9205e4a08fe12aac3efed980ae3e1ce5
Author: George Dunlap 
Date:   Thu Mar 24 17:17:22 2016 +

libxl: Remove pointless hypercall from libxl_set_memory_target

There's no obvious reason for the call to xc_domain_getinfolist -- all
it seems to be doing is checking that the domain exists; but if it
doesn't exist, it will have already failed by this point.

NB that this will change the return value for libxl_set_memory_target:
now it will return 0 on success, rather than returning 1 (which was
the previous behavior).  This is more in line with expected behavior,
and also allows the caller to distingiush between success and other
failure modes (some of which also return 1).

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 
(qemu changes not included)

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 12 guest-saverestore  fail REGR. vs. 86491
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail REGR. vs. 86491
 test-armhf-armhf-libvirt-qcow2  5 xen-install fail REGR. vs. 86491
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 86491

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

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

version targeted for testing:
 xen  0d42d461c21685258ac9c17bec7eaeb9ac2fce4c
baseline version:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f

Last test of basis86491  2016-03-17 15:24:59 Z8 days
Failing since 86560  2016-03-18 10:56:34 Z7 days9 attempts
Testing same since87287  2016-03-25 08:12:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chunyan Liu 
  Dagaen Golomb 
  Daniel De Graaf 
  Dario Faggioli 
  Dave Scott 
  David Scott 
  David Vrabel 
  Doug Goldstein 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Jonathan Davies 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Olaf Hering 
  Paul Durrant 
  Roger Pau 

[Xen-devel] debug xen with GNU DDD

[tutu sky]

Hi, there is a question.
I need to observe some Xen internals, so i thought debugging might be useful. i 
tried using gdb, kdb, ... but they are complicated and not obvious. there is a  
debugging 
tool, GNU DDD, which may be suitable (although some simple) for that. but 
unfortunately i can not find any other who has experience of this tool for Xen 
debugging.
I come here to ask if there is a person who has such a experience (debugging 
Xen with GNU DDD). If so, would you please give me a start point with it?

if NOT, it would be helpful if you can give me a little clear and less 
confusing way for debugging xen using gdb or kdb or ... . Information which can 
be used around this subject among the google searches or forums are not 
integrated, mean no good documentation on Xen debugging or it's debugging tools 
unfortunately (i tried them, nothing earned).

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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[Steven Haigh]

On 26/03/2016 3:20 AM, Boris Ostrovsky wrote:
> On 03/25/2016 12:04 PM, Steven Haigh wrote:
>> It may not actually be the full logs. Once the system gets really upset,
>> you can't run anything - as such, grabbing anything from dmesg is not
>> possible.
>>
>> The logs provided above is all that gets spat out to the syslog server.
>>
>> I'll try tinkering with a few things to see if I can get more output -
>> but right now, that's all I've been able to achieve. So far, my only
>> ideas are to remove the 'quiet' options from the kernel command line -
>> but I'm not sure how much that would help.
>>
>> Suggestions gladly accepted on this front.
> 
> You probably want to run connected to guest serial console ("
> serial='pty' " in guest config file and something like 'loglevel=7
> console=tty0 console=ttyS0,38400n8' on guest kernel commandline). And
> start the guest with 'xl create -c ' or connect later with 'xl
> console '.

Ok thanks, I've booted the DomU with:

$ cat /proc/cmdline
root=UUID=63ade949-ee67-4afb-8fe7-ecd96faa15e2 ro enforcemodulesig=1
selinux=0 fsck.repair=yes loglevel=7 console=tty0 console=ttyS0,38400n8

I've left a screen session attached to the console (via xl console) and
I'll see if that turns anything up. As this seems to be rather
unpredictable when it happens, it may take a day or two to get anything.
I just hope its more than the syslog output :)

-- 
Steven Haigh

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



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig

[Doug Goldstein]

On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote:
>> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
>> was previously togglable on the command line so this adds a message for
>> users enabling it from the command line to tell them to enable it from
>> make menuconfig.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> This is an example of using the debug menu.
>>
>>
>> CC: Keir Fraser 
>> CC: Jan Beulich 
>> CC: Andrew Cooper 
>> ---
>>  docs/misc/crashdb.txt  |  4 ++--
>>  xen/Kconfig.debug  | 11 +++
>>  xen/Rules.mk   |  5 +++--
>>  xen/arch/x86/Makefile  |  3 +--
>>  xen/arch/x86/x86_64/Makefile   |  2 +-
>>  xen/common/Makefile|  2 +-
>>  xen/include/asm-x86/debugger.h |  2 +-
>>  xen/include/xen/gdbstub.h  |  2 +-
>>  8 files changed, 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/docs/misc/crashdb.txt b/docs/misc/crashdb.txt
>> index b41a538..9733666 100644
>> --- a/docs/misc/crashdb.txt
>> +++ b/docs/misc/crashdb.txt
>> @@ -5,7 +5,7 @@ Xen has a simple gdb stub for doing post-mortem debugging 
>> i.e. once
>>  you've crashed it, you get to poke around and find out why.  There's
>>  also a special key handler for making it crash, which is handy.
>>  
>> -You need to have crash_debug=y set when compiling , and you also need
>> +You need to have CRASH_DEBUG=y set when compiling, and you also need
>>  to enable it on the Xen command line, eg by gdb=com1.
>>  
>>  If you need to have a serial port shared between gdb and the console,
>> @@ -19,7 +19,7 @@ if you have a simple null modem connection between the 
>> test box and
>>  the workstation, and aren't using a H/L split console:
>>  
>>* Set debug=y in Config.mk
>> -  * Set crash_debug=y in xen/Rules.mk
>> +  * Set CRASH_DEBUG=y with `make -C xen menuconfig`
>>* Make the changes in the attached patch, and build.
>>* Arrange to pass gdb=com1 as a hypervisor command line argument
>>  (I already have com1=38400,8n1 console=com1,vga sync_console)
>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>> index 36890bd..3336a64 100644
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -4,3 +4,14 @@ menuconfig DEBUG
>>  ---help---
>>If you want to debug Xen say Y and select any additional debugging
>>support options.
>> +
>> +if DEBUG
> 
> Perhaps if !defined then atuomatically enable it? Looking at Config.mk
> it seems you could do crash_debug without debug=y?

debug=y unfortunately is more than just a "meta" option that selects
verbose=y and frame_pointer=y. It also turns off NDEBUG so that debug
messages appear. I'm not sure how that should be mapped in the context
of this patch. Should the messages be enabled when DEBUG is enabled or
should there be another option?

If debug messages are enabled with DEBUG that would certainly be a
behavior change since now someone could have crash_debug=y debug=n but
I'm not sure if that's desired?

> 
> Why is this called crash_debug and not 'crash_gdb' ..? Ah [after reading the 
> docs]
> it can't do breakpoints or any of that. Just to pour over the data after a 
> crash.
> Ah, you can resume the hypervisor after this. OK, definitly not for field
> analysis.
> 
> And kexec/kdump is much more powerful than this.

yeah I wondered that myself as well and came to the conclusion it was
limited. Good point about kexec/kdump. I should definitely update the
description to be more verbose.

> 
> 
>> +
>> +config CRASH_DEBUG
>> +bool "Crash Debugging Support"
>> +depends on X86
>> +---help---
>> +  If you want to be able to attach gdb to Xen to be able to debug
>> +  Xen if it crashes then say Y.
> 
> Should it have a link to the docs ? On how to use it?

yeah I think maybe just pointing someone to docs/misc/crashdb.txt cause
its not immediately obvious that's the doc file to go with crash_debug.

> 
> And maybe mention that kexec/kdump is better suited for capturing the whole
> machine and one can do post-mortem analysis much more intensly?

Yeah that's a really good point. I didn't think of that.


-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.

[Daniel De Graaf]

On 03/18/2016 05:48 AM, Fu Wei wrote:

Hi Jan,

On 18 March 2016 at 16:24, Jan Beulich  wrote:

On 18.03.16 at 08:41,  wrote:

--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -163,6 +163,36 @@ static void __init process_memory_node(const void *fdt, 
int node,
  }
  }

+static bool __init check_xsm_signature(const void *fdt, int node,
+   const char *name,
+   u32 address_cells, u32 size_cells)
+{
+uint32_t selinux_magic = 0xf97cff8c;


So this would be the 3rd instance of this literal number in the source
base. I would have wanted to suggest using one of the two
constants we already have, but I don't know which one to pick.

Daniel - why do we have both XSM_MAGIC and FLASK_MAGIC?


I think the intent was that FLASK_MAGIC be the primary source of the
constant with XSM_MAGIC set to that value when FLASK was the chosen
XSM module.  With the relative locations of the definitions in Xen,
this ended up duplicating the literal which isn't quite as nice.  I
would be fine with consolidating either way; perhaps move FLASK_MAGIC
into xsm.h and conditionally define XSM_MAGIC to reference it?


Ah, Sorry for that , I didn't know we already have these definition.

OK, I think we should use XSM_MAGIC,
and I think  FLASK_MAGIC should be "XenFlask".
Please correct me if I misunderstand something.


These constants are also defined as POLICYDB_MAGIC and POLICYDB_STRING
in xen/xsm/flask/ss/policydb.h (that will probably need to be moved if
you want to use them elsewhere).

The hypervisor also supports loading policies whose magic type declares
them to be SELinux policy, but I think it's fine if ARM requires that
the policy be built targeting Xen - the build has done that for a while,
and the original reason (older versions of checkpolicy didn't support
creating xen-type policy) is no longer an issue.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [RFC PATCH 1/2] build: add debug menu to Kconfig

[Doug Goldstein]

On 3/25/16 2:42 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 11:48:18AM -0500, Doug Goldstein wrote:
>> There are a number of debugging options for Xen so the idea is to have a
>> menu to group them all together.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> This is more of an RFC than a merge request. If this seems reasonable I'll
>> add all the other debugging options under this menu as well. Obviously if
>> this seems reasonable and the patch is fine we can merge it and I'll submit
>> the others as a follow up.
> 
> There would be more I presume - the lock profile, gcov, crash, etc..

Yes. I just wanted to do one to get an idea of how people felt about the
menu.

> 
> And with the 'randconfig' that means we can turn on/off various options and
> find interesting dependencies (if any).

Exactly. We've found a number of interesting cases with randconfig
already and fixed them. I previously checked some of them against some
of the stable trees and found the combos failed so Travis CI +
randconfig are finding issues but not commonly used ones.

Anyway back to this patch.

> 
> 
> Anyhow back to this patch.

:-D

> 
> The usual method for distros of compiling an Xen with and without debug (like 
> Xenserver)
> is:
> 

This feels very... http://xkcd.com/1172/


> make %{?_smp_mflags} max_phys_cpus=384 xen tools

So two comments on this line.

1) ick! "xen" and "tools" targets have been marked as Legacy since
October 5th 2005!
2) That's been broken since I got rid of max_phys_cpus and moved it to
CONFIG_NR_CPUS (I think that's the name).

spec files for things like busybox include the config file and just copy
it in before running make

cp someplace/config.release xen/.config
make %{?_smp_mflags} dist-xen dist-tools

> 
> make %{?_smp_mflags} -C xen clean

why use the directory here but not in the first step?

make %{?_smp_mflags} clean-xen

would be the matching target

> make %{?_smp_mflags} -C xen debug=y max_phys_cpus=384

ok mind blown. We build xen in the first step with the Legacy target and
then changing to the directory here.

> 
> It would be preferrable to still have this functionality. As in, if we
> do 'debug=y' then verbose=y and frame_pointer=y are automatically enabled?
> 
> Is that something the Kconfig magic can still do?

I could do some wizard-y to allow debug=y to turn things on. Not sure if
the lowercase will work but I can definitely think of a way to make the
uppercase DEBUG=y work. But at that point I don't see the point. I see
the point of debug=y since that's a top level thing.



>>
>>
>> CC: Ian Jackson 
>> CC: Jan Beulich 
>> CC: Keir Fraser 
>> CC: Tim Deegan 
>> ---
>>  xen/Kconfig   | 2 ++
>>  xen/Kconfig.debug | 6 ++
>>  2 files changed, 8 insertions(+)
>>  create mode 100644 xen/Kconfig.debug
>>
>> diff --git a/xen/Kconfig b/xen/Kconfig
>> index fa8b27c..0fe7a1a 100644
>> --- a/xen/Kconfig
>> +++ b/xen/Kconfig
>> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>>  config EXPERT
>>  string
>>  option env="XEN_CONFIG_EXPERT"
>> +
>> +source "Kconfig.debug"
>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>> new file mode 100644
>> index 000..36890bd
>> --- /dev/null
>> +++ b/xen/Kconfig.debug
>> @@ -0,0 +1,6 @@
>> +
>> +menuconfig DEBUG
>> +bool "Debugging Options"
>> +---help---
>> +  If you want to debug Xen say Y and select any additional debugging
>> +  support options.
> 
> .. You can also add:
> 
> Should not be used for production builds.
> 
> Note that any _ASSERTS_ in the code without debug are emitted.
> 
>> -- 
>> 2.7.3
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Fri, Mar 25, 2016 at 12:28:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 18, 2016 at 06:00:23PM +0100, Daniel Kiper wrote:
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. 
> > Relocator
> > will set lower parts of %rax and %rbx accordingly to multiboot2 
> > specification.
> > On the other hand processor mode, just before jumping into loaded image, 
> > will
> > be set accordingly to Unified Extensible Firmware Interface Specification,
> > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> > loaded image will be able to use EFI boot services without any issues.
> >
> > Signed-off-by: Daniel Kiper 
>
> Reviewed-by: Konrad Rzeszutek Wilk 
>
> .. with one modification:
> .. snip..
> > diff --git a/grub-core/lib/x86_64/efi/relocator.c 
> > b/grub-core/lib/x86_64/efi/relocator.c
> > new file mode 100644
> > index 000..c93d061
> > --- /dev/null
> > +++ b/grub-core/lib/x86_64/efi/relocator.c
> > +grub_err_t
> > +grub_relocator64_efi_boot (struct grub_relocator *rel,
> > +  struct grub_relocator64_efi_state state)
> > +{
> > +  grub_err_t err;
> > +  void *relst;
> > +  grub_relocator_chunk_t ch;
> > +
> > +  err = grub_relocator_alloc_chunk_align (rel, , 0,
> > + 0x4000 - RELOCATOR_SIZEOF 
> > (64_efi),
>   ^^ - why the 1GB?
>
> Could you give a bit details on it? Or preferrable have a comment right
> above saying what that value is used?

I took this from BSD loader. I assumed that if it uses this value then
it is safe to do the same here. However, it looks that we can safely use
"4 GiB - RELOCATOR_SIZEOF (64_efi)" too (probably higher value is also
good but I do not think we should go that way). If there are not
objections then I will repost fixed patch series next week.

Daniel

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

Re: [Xen-devel] [PATCH v8 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 04:38:05PM +0100, Dario Faggioli wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> > If Device-TLB flush timed out, we would hide the target ATS
> > device and crash the domain owning this ATS device. If impacted
> > domain is hardware domain, just throw out a warning.
> > 
> > The hidden device should be disallowed to be further assigned
> > to any domain.
> > 
> What is "should be disallowed" supposed to mean here? Isn't the
> situation that, by hiding the device, which this patch is doing, we
> actually disallow any further assignment?

Yes.

Take a look at device_assigned. This patch reassigns the device to dom_xen
so device_assigned will return -EBUSY.

Actually that information could be part of the commit to get an
idea of the effects of this patch.
> 
> If yes, this should rather be (something like):
> 
> "By hiding the device, we make sure it can't be assigned to any domain
> any longer."
> 
> Other than this, the patch looks good to me, but I'll re-review it when
> the new version comes out (with the other patches from the preliminary
> series folded in), before saying Reviewed-by.
> 
> 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 mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 01:57:59PM +0800, Quan Xu wrote:
> If Device-TLB flush timed out, we would hide the target ATS
> device and crash the domain owning this ATS device. If impacted
> domain is hardware domain, just throw out a warning.
> 
> The hidden device should be disallowed to be further assigned
> to any domain.
> 
> Signed-off-by: Quan Xu 
> ---
>  xen/drivers/passthrough/pci.c |  6 ++--
>  xen/drivers/passthrough/vtd/extern.h  |  3 +-
>  xen/drivers/passthrough/vtd/qinval.c  | 58 
> +--
>  xen/drivers/passthrough/vtd/x86/ats.c | 11 ---
>  xen/include/xen/pci.h |  1 +
>  5 files changed, 68 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 9f1716a..9a214c6 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -420,7 +420,7 @@ static void free_pdev(struct pci_seg *pseg, struct 
> pci_dev *pdev)
>  xfree(pdev);
>  }
>  
> -static void _pci_hide_device(struct pci_dev *pdev)
> +void pci_hide_existing_device(struct pci_dev *pdev)
>  {
>  if ( pdev->domain )
>  return;
> @@ -437,7 +437,7 @@ int __init pci_hide_device(int bus, int devfn)
>  pdev = alloc_pdev(get_pseg(0), bus, devfn);
>  if ( pdev )
>  {
> -_pci_hide_device(pdev);
> +pci_hide_existing_device(pdev);
>  rc = 0;
>  }
>  pcidevs_unlock();
> @@ -467,7 +467,7 @@ int __init pci_ro_device(int seg, int bus, int devfn)
>  }
>  
>  __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
> -_pci_hide_device(pdev);
> +pci_hide_existing_device(pdev);
>  
>  return 0;
>  }
> diff --git a/xen/drivers/passthrough/vtd/extern.h 
> b/xen/drivers/passthrough/vtd/extern.h
> index 6d3187d..94e2c11 100644
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -62,7 +62,8 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
>  int qinval_device_iotlb(struct iommu *iommu,
>  u32 max_invs_pend, u16 sid, u16 size, u64 addr);
>  int qinval_device_iotlb_sync(struct iommu *iommu, u32 max_invs_pend,
> - u16 sid, u16 size, u64 addr);
> + u16 did, u16 seg, u8 bus, u8 devfn,
> + u16 size, u64 addr);
>  
>  unsigned int get_cache_line_size(void);
>  void cacheline_flush(char *);
> diff --git a/xen/drivers/passthrough/vtd/qinval.c 
> b/xen/drivers/passthrough/vtd/qinval.c
> index ad9e265..10c5684 100644
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -216,6 +216,58 @@ static int queue_invalidate_iotlb_sync(struct iommu 
> *iommu,
>  return invalidate_sync(iommu);
>  }
>  
> +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> + u16 seg, u8 bus, u8 devfn)
> +{
> +struct domain *d = NULL;
> +struct pci_dev *pdev;
> +
> +if ( test_bit(did, iommu->domid_bitmap) )
> +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> +
> +if ( d == NULL )
> +return;
> +
> +pcidevs_lock();
> +
> +for_each_pdev(d, pdev)
> +{
> +if ( ( pdev->seg == seg ) &&
> + ( pdev->bus == bus ) &&
> + ( pdev->devfn == devfn ) )
> +{
> +ASSERT ( pdev->domain );

Oddly enough (and I don't see this in the StyleGuide), the ASSERTS
do not require the spaces. So it can be:

ASSERT(pdev->domain);


> +list_del(>domain_list);
> +pdev->domain = NULL;
> +pci_hide_existing_device(pdev);
> +break;
> +}
> +}
> +
> +pcidevs_unlock();
> +
> +if ( !is_hardware_domain(d) )
> +domain_crash(d);

The description said something about 'just throw out a warning' (if
the domain owning it is a hardware domain). That seems to be missing?


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

Re: [Xen-devel] [PATCH v8 1/3] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 01:57:58PM +0800, Quan Xu wrote:

Hey!

Thanks for the patch! 

I see that you have __must_check..

But if you check the callchain:

iommu_flush_iec_[index|global] ->
__iommu_flush_iec->invalidate_sync-> queue_invalidate_wait

you will see that the callers of iommu_flush_iec_[index|global]
ignore the return value.

So ... perhaps you could explain in this commit description on how to address
that? Is there an followup patch (if so just put in the name in here) to
address that?

Or should the top callers: enable_intremap, ioapic_rte_to_remap_entry,
free_remap_entry, msi_msg_to_remap_entry, and pi_update_irte do something?

I guess the 'free_remap_entry' reall can't. As you are suppose to always
be able to free something.


msi_msg_to_remap_entry, _msg_to_remap_entry, and ioapic_rte_to_remap_entry
could return an value... Or considering this is v8 - was there some epic
conversation that went over this quite a lot? In which case I would recommend
you say why it was not attempted this way so that folks six months from
now when reading this patch won't ask again.


> Signed-off-by: Quan Xu 
> ---
>  docs/misc/xen-command-line.markdown  |  7 +++
>  xen/drivers/passthrough/vtd/qinval.c | 17 -
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index ca77e3b..384dde7 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1532,6 +1532,13 @@ Note that if **watchdog** option is also specified 
> vpmu will be turned off.
>  As the virtualisation is not 100% safe, don't use the vpmu flag on
>  production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
>  
> +### vtd\_qi\_timeout (VT-d)
> +> `= `
> +
> +> Default: `1`
> +
> +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
> +
>  ### watchdog
>  > `= force | `
>  
> diff --git a/xen/drivers/passthrough/vtd/qinval.c 
> b/xen/drivers/passthrough/vtd/qinval.c
> index b81b0bd..52ba2c2 100644
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
>  #include "vtd.h"
>  #include "extern.h"
>  
> +static unsigned int __read_mostly vtd_qi_timeout = 1;
> +integer_param("vtd_qi_timeout", vtd_qi_timeout);
> +
> +#define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
> +
>  static void print_qi_regs(struct iommu *iommu)
>  {
>  u64 val;
> @@ -130,10 +135,10 @@ static void queue_invalidate_iotlb(struct iommu *iommu,
>  spin_unlock_irqrestore(>register_lock, flags);
>  }
>  
> -static int queue_invalidate_wait(struct iommu *iommu,
> +static int __must_check queue_invalidate_wait(struct iommu *iommu,
>  u8 iflag, u8 sw, u8 fn)
>  {
> -s_time_t start_time;
> +s_time_t timeout;
>  volatile u32 poll_slot = QINVAL_STAT_INIT;
>  unsigned int index;
>  unsigned long flags;
> @@ -164,13 +169,15 @@ static int queue_invalidate_wait(struct iommu *iommu,
>  if ( sw )
>  {
>  /* In case all wait descriptor writes to same addr with same data */
> -start_time = NOW();
> +timeout = NOW() + IOMMU_QI_TIMEOUT;
>  while ( poll_slot != QINVAL_STAT_DONE )
>  {
> -if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
> +if ( NOW() > timeout )
>  {
>  print_qi_regs(iommu);
> -panic("queue invalidate wait descriptor was not executed");
> +printk(XENLOG_WARNING VTDPREFIX
> +   "Queue invalidate wait descriptor timed out.\n");
> +return -ETIMEDOUT;
>  }
>  cpu_relax();
>  }
> -- 
> 1.9.1
> 
> 
> ___
> 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] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

[Sarah Newman]

On 03/25/2016 12:32 PM, Samuel Thibault wrote:
> Sarah Newman, on Fri 25 Mar 2016 12:19:23 -0700, wrote:
>> I have no objections to backing out additional changes made in 7c8f3483,
> 
> ? My patch doesn't really back out more than what you proposed actually.

It also backs out the #ifdef's on HAVE_LIBC, but yes it's functionally 
equivalent.

--Sarah

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

Re: [Xen-devel] [PATCH v5 0/3] tools: Return failure when the command failed for more xl commands

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 05:17:21PM +, George Dunlap wrote:
> Return failure when the command failed for more xl commands:
> - mem-set
> - cd-insert
> 
> This makes xl more useful for scripting.
> 
> In the case of mem-set, it means first cleaning up
> libxl_set_memory_target() to return useful error codes.
> 
> NB that these three patches are straight forward-ports of
> already-acked patches.  (The other two I'll come back to another time,
> or may make good OPW / GSoC fodder.)

Applied.
> 
> 
> George Dunlap (3):
>   libxl: Remove pointless hypercall from libxl_set_memory_target
>   xl: Make set_memory_target return an error code on failure
>   xl: Return an error on failed cd-insert
> 
>  tools/libxl/libxl.c  |  5 -
>  tools/libxl/xl_cmdimpl.c | 48 
> +---
>  2 files changed, 25 insertions(+), 28 deletions(-)
> 
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote:
> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
> was previously togglable on the command line so this adds a message for
> users enabling it from the command line to tell them to enable it from
> make menuconfig.
> 
> Signed-off-by: Doug Goldstein 
> ---
> This is an example of using the debug menu.
> 
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> ---
>  docs/misc/crashdb.txt  |  4 ++--
>  xen/Kconfig.debug  | 11 +++
>  xen/Rules.mk   |  5 +++--
>  xen/arch/x86/Makefile  |  3 +--
>  xen/arch/x86/x86_64/Makefile   |  2 +-
>  xen/common/Makefile|  2 +-
>  xen/include/asm-x86/debugger.h |  2 +-
>  xen/include/xen/gdbstub.h  |  2 +-
>  8 files changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/docs/misc/crashdb.txt b/docs/misc/crashdb.txt
> index b41a538..9733666 100644
> --- a/docs/misc/crashdb.txt
> +++ b/docs/misc/crashdb.txt
> @@ -5,7 +5,7 @@ Xen has a simple gdb stub for doing post-mortem debugging 
> i.e. once
>  you've crashed it, you get to poke around and find out why.  There's
>  also a special key handler for making it crash, which is handy.
>  
> -You need to have crash_debug=y set when compiling , and you also need
> +You need to have CRASH_DEBUG=y set when compiling, and you also need
>  to enable it on the Xen command line, eg by gdb=com1.
>  
>  If you need to have a serial port shared between gdb and the console,
> @@ -19,7 +19,7 @@ if you have a simple null modem connection between the test 
> box and
>  the workstation, and aren't using a H/L split console:
>  
>* Set debug=y in Config.mk
> -  * Set crash_debug=y in xen/Rules.mk
> +  * Set CRASH_DEBUG=y with `make -C xen menuconfig`
>* Make the changes in the attached patch, and build.
>* Arrange to pass gdb=com1 as a hypervisor command line argument
>  (I already have com1=38400,8n1 console=com1,vga sync_console)
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 36890bd..3336a64 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -4,3 +4,14 @@ menuconfig DEBUG
>   ---help---
> If you want to debug Xen say Y and select any additional debugging
> support options.
> +
> +if DEBUG

Perhaps if !defined then atuomatically enable it? Looking at Config.mk
it seems you could do crash_debug without debug=y?

Why is this called crash_debug and not 'crash_gdb' ..? Ah [after reading the 
docs]
it can't do breakpoints or any of that. Just to pour over the data after a 
crash.
Ah, you can resume the hypervisor after this. OK, definitly not for field
analysis.

And kexec/kdump is much more powerful than this.


> +
> +config CRASH_DEBUG
> + bool "Crash Debugging Support"
> + depends on X86
> + ---help---
> +   If you want to be able to attach gdb to Xen to be able to debug
> +   Xen if it crashes then say Y.

Should it have a link to the docs ? On how to use it?

And maybe mention that kexec/kdump is better suited for capturing the whole
machine and one can do post-mortem analysis much more intensly?

> +
> +endif # DEBUG
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index f29491e..b5d8d33 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -7,7 +7,6 @@ verbose   ?= n
>  perfc ?= n
>  perfc_arrays  ?= n
>  lock_profile  ?= n
> -crash_debug   ?= n
>  frame_pointer ?= n
>  lto   ?= n
>  
> @@ -30,6 +29,9 @@ endif
>  ifneq ($(origin kexec),undefined)
>  $(error "You must use 'make menuconfig' to enable/disable kexec now.")
>  endif
> +ifneq ($(origin crash_debug),undefined)
> +$(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
> +endif
>  
>  # Set ARCH/SUBARCH appropriately.
>  override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
> @@ -53,7 +55,6 @@ CFLAGS += -pipe -g -D__XEN__ -include 
> $(BASEDIR)/include/xen/config.h
>  CFLAGS += '-D__OBJECT_FILE__="$@"'
>  
>  CFLAGS-$(verbose)   += -DVERBOSE
> -CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
>  CFLAGS-$(perfc) += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 1bcb08b..21d7e5f 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -24,6 +24,7 @@ obj-y += domain_page.o
>  obj-y += e820.o
>  obj-y += extable.o
>  obj-y += flushtlb.o
> +obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
>  obj-y += i387.o
>  obj-y += i8259.o
>  obj-y += io_apic.o
> @@ -62,8 +63,6 @@ obj-y += hpet.o
>  obj-y += vm_event.o
>  obj-y += xstate.o
>  
> -obj-$(crash_debug) += gdbstub.o
> -
>  x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
>  
>  efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
> diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
> index 

Re: [Xen-devel] [RFC PATCH 1/2] build: add debug menu to Kconfig

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 11:48:18AM -0500, Doug Goldstein wrote:
> There are a number of debugging options for Xen so the idea is to have a
> menu to group them all together.
> 
> Signed-off-by: Doug Goldstein 
> ---
> This is more of an RFC than a merge request. If this seems reasonable I'll
> add all the other debugging options under this menu as well. Obviously if
> this seems reasonable and the patch is fine we can merge it and I'll submit
> the others as a follow up.

There would be more I presume - the lock profile, gcov, crash, etc..

And with the 'randconfig' that means we can turn on/off various options and
find interesting dependencies (if any).


Anyhow back to this patch.

The usual method for distros of compiling an Xen with and without debug (like 
Xenserver)
is:

make %{?_smp_mflags} max_phys_cpus=384 xen tools

make %{?_smp_mflags} -C xen clean
make %{?_smp_mflags} -C xen debug=y max_phys_cpus=384

It would be preferrable to still have this functionality. As in, if we
do 'debug=y' then verbose=y and frame_pointer=y are automatically enabled?

Is that something the Kconfig magic can still do?
> 
> 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Keir Fraser 
> CC: Tim Deegan 
> ---
>  xen/Kconfig   | 2 ++
>  xen/Kconfig.debug | 6 ++
>  2 files changed, 8 insertions(+)
>  create mode 100644 xen/Kconfig.debug
> 
> diff --git a/xen/Kconfig b/xen/Kconfig
> index fa8b27c..0fe7a1a 100644
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>  config EXPERT
>   string
>   option env="XEN_CONFIG_EXPERT"
> +
> +source "Kconfig.debug"
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> new file mode 100644
> index 000..36890bd
> --- /dev/null
> +++ b/xen/Kconfig.debug
> @@ -0,0 +1,6 @@
> +
> +menuconfig DEBUG
> + bool "Debugging Options"
> + ---help---
> +   If you want to debug Xen say Y and select any additional debugging
> +   support options.

.. You can also add:

Should not be used for production builds.

Note that any _ASSERTS_ in the code without debug are emitted.

> -- 
> 2.7.3
> 
> 
> ___
> 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] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

[Samuel Thibault]

Sarah Newman, on Fri 25 Mar 2016 12:19:23 -0700, wrote:
> I have no objections to backing out additional changes made in 7c8f3483,

? My patch doesn't really back out more than what you proposed actually.

> The patch tests OK with GNT_DEBUG enabled.

Good :)

Samuel

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

Re: [Xen-devel] [PATCH 6/6] xentrace: ARM platform timestamp support

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2016 at 01:51:39PM -0700, Benjamin Sanda wrote:
> From: bensanda 
> 
> Modified to provide support for xentrace on the ARM platform. Changed 
> get_cycles() to return the core timestamp tick count for use by the trace 
> buffer timestamping routines in xentrace.
> 
> Signed-off-by: Benjamin Sanda 

That is missing the CC to Stefano or Julien. CC-ing them.
> ---
>  xen/include/asm-arm/time.h | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
> index 5b9a31d..f3a22d5 100644
> --- a/xen/include/asm-arm/time.h
> +++ b/xen/include/asm-arm/time.h
> @@ -1,15 +1,21 @@
>  #ifndef __ARM_TIME_H__
>  #define __ARM_TIME_H__
>  
> +#include 
> +
>  #define DT_MATCH_TIMER  \
>  DT_MATCH_COMPATIBLE("arm,armv7-timer"), \
>  DT_MATCH_COMPATIBLE("arm,armv8-timer")
>  
> -typedef unsigned long cycles_t;
> +/* Counter value at boot time */
> +extern uint64_t boot_count;
> +
> +typedef uint64_t cycles_t;
>  
>  static inline cycles_t get_cycles (void)
>  {
> -return 0;
> +/* return raw tick count of main timer */
> +return READ_SYSREG64(CNTPCT_EL0) - boot_count;
>  }
>  
>  /* List of timer's IRQ */
> @@ -34,9 +40,6 @@ unsigned int timer_get_irq(enum timer_ppi ppi);
>  /* Set up the timer interrupt on this CPU */
>  extern void init_timer_interrupt(void);
>  
> -/* Counter value at boot time */
> -extern uint64_t boot_count;
> -
>  extern s_time_t ticks_to_ns(uint64_t ticks);
>  extern uint64_t ns_to_ticks(s_time_t ns);
>  
> -- 
> 2.7.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 1/6] Flask: Support for ARM xentrace

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2016 at 01:51:34PM -0700, Benjamin Sanda wrote:
> From: bensanda 
> 
> Modified to provide support for xentrace on the ARM platform. Added flask 
> credential to allow dom0 dom_xen mapping and write access for trace buffers.

So .. what does that mean?

Is that something xentrace requests? Why is this ARM specific?
Looking at xsm_sysctl and how the trace is setup it checks for
XEN__TBUFCONTROL?

But this is more specific?
> 
> Signed-off-by: Benjamin Sanda 
> ---
>  tools/flask/policy/policy/modules/xen/xen.te | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
> b/tools/flask/policy/policy/modules/xen/xen.te
> index d35ae22..41d276a 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -90,6 +90,8 @@ allow dom0_t dom0_t:domain2 {
>  };
>  allow dom0_t dom0_t:resource { add remove };
>  
> +allow dom0_t domxen_t:mmu { memorymap map_write };
> +
>  # These permissions allow using the FLASK security server to compute access
>  # checks locally, which could be used by a domain or service (such as 
> xenstore)
>  # that does not have its own security server to make access decisions based 
> on
> -- 
> 2.7.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] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

[Sarah Newman]

On 03/25/2016 11:33 AM, Samuel Thibault wrote:
> Wei Liu, on Fri 25 Mar 2016 13:09:07 +, wrote:
>> CC Samuel
> 
> Thanks.
> 
>> On Wed, Mar 23, 2016 at 02:26:51PM -0700, Sarah Newman wrote:
>>> 7c8f3483 introduced a break within a loop in netfront.c such that
>>> cons and nr_consumed were no longer always being incremented. The
>>> offset at cons will be processed multiple times with the break in
>>> place.
>>>
>>> Remove the break and re-add "some !=0" in the loop for HAVE_LIBC.
> 
> Mmm, right.
> 
> That ifdef makes things even more difficult to understand then. That
> however makes me think: how about the attached patch, which actually
> simplifies the rest.
> 
> Thanks!
> Samuel
> 

I have no objections to backing out additional changes made in 7c8f3483, but I 
wasn't the person who submitted that patch.

The patch tests OK with GNT_DEBUG enabled.

--Sarah

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

Re: [Xen-devel] pv-grub guest booting fail with recent qemu-xen

[Konrad Rzeszutek Wilk]

On Wed, Mar 02, 2016 at 07:16:40AM +, Hao, Xudong wrote:
> Hi,
> For Xen upstream master branch with commit 1949868d, After updating qemu-xen 
> version from fcf6ac57 to 2ce1d30e, booting a pv-grub guest will fail.
> Attach the guest config file and Xen log.

Is this still an issue? I saw an MiniOS patch go by..
> 
> 
> Best Regards,
> Xudong
> 

> (XEN) Bad console= option '115200'
> (XEN) Bad console= option '8n1'

Also your options are incorrect.

>  Xen 4.7-unstable
> (XEN) Xen version 4.7-unstable (build@) (gcc (GCC) 4.4.7 20120313 (Red Hat 
> 4.4.7-16)) debug=y Fri Jan 29 09:38:36 EST 2016
> (XEN) Latest ChangeSet: Sun Jan 24 19:45:51 2016 -0500 git:9937763-dirty
> (XEN) Console output is synchronous.
> (XEN) Bootloader: GNU GRUB 0.97
> (XEN) Command line: dom0_mem=4096M loglvl=all guest_loglvl=all 
> unrestricted_guest=1 msi=1 console=com1,115200,8n1 sync_console hap_1gb=1 
> conring_size=128M iommu=on,intpost psr=cmt psr=cat psr=cdp 
> cpufreq=performance vpid=1

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

Re: [Xen-devel] [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 10:14:22AM -0600, Jan Beulich wrote:

Something is off with your patch. This is 5/4 :-)

> Instead of addressing these fields via the base of the stack (which
> uniformly requires 4-byte displacements), address them from the end
> (which for everything other than guest_cpu_user_regs requires just
> 1-byte ones). This yields a code size reduction somewhere between 8k
> and 12k in my builds.

Also you made the macro a bit different - the %r is removed.

Particular reason? 

> 
> Signed-off-by: Jan Beulich 
> ---
> Note that just like patch 4 of the series this also isn't directly
> related to the SMEP/SMAP issue, but is again just a result of things
> realized while doing that work, and again depends on the earlier
> patches to apply cleanly.
> 

.. snip..
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -127,19 +127,19 @@ void ret_from_intr(void);
>  UNLIKELY_DONE(mp, tag);   \
>  __UNLIKELY_END(tag)
>  
> -#define STACK_CPUINFO_FIELD(field) 
> (STACK_SIZE-CPUINFO_sizeof+CPUINFO_##field)
> -#define GET_STACK_BASE(reg)   \
> -movq $~(STACK_SIZE-1),reg;\
> -andq %rsp,reg
> +#define STACK_CPUINFO_FIELD(field) (1 - CPUINFO_sizeof + CPUINFO_##field)
> +#define GET_STACK_END(reg)\
> +movl $STACK_SIZE-1, %e##reg;  \
> +orq  %rsp, %r##reg
>  
>  #define GET_CPUINFO_FIELD(field, reg) \
> -GET_STACK_BASE(reg);  \
> -addq $STACK_CPUINFO_FIELD(field),reg
> +GET_STACK_END(reg);   \
> +addq $STACK_CPUINFO_FIELD(field), %r##reg

Not subq? The GET_STACK_END gets us ..[ edit: missed first time
the change to STACK_CPUINFO_FIELD].


Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

[Samuel Thibault]

Wei Liu, on Fri 25 Mar 2016 13:09:07 +, wrote:
> CC Samuel

Thanks.

> On Wed, Mar 23, 2016 at 02:26:51PM -0700, Sarah Newman wrote:
> > 7c8f3483 introduced a break within a loop in netfront.c such that
> > cons and nr_consumed were no longer always being incremented. The
> > offset at cons will be processed multiple times with the break in
> > place.
> > 
> > Remove the break and re-add "some !=0" in the loop for HAVE_LIBC.

Mmm, right.

That ifdef makes things even more difficult to understand then. That
however makes me think: how about the attached patch, which actually
simplifies the rest.

Thanks!
Samuel
netfront: fix off-by-one error introduced in 7c8f3483

7c8f3483 introduced a break within a loop in netfront.c such that
cons and nr_consumed were no longer always being incremented. The
offset at cons will be processed multiple times with the break in
place.

Remove the break and re-add "some !=0" in the loop for HAVE_LIBC,
rename it into dobreak to mitigate confusion.

Signed-off-by: Sarah Newman 
Signed-off-by: Samuel Thibault 

diff --git a/netfront.c b/netfront.c
index 0eca5b5..b8fac62 100644
--- a/netfront.c
+++ b/netfront.c
@@ -97,19 +97,15 @@ void network_rx(struct netfront_dev *dev)
 {
 RING_IDX rp,cons,req_prod;
 int nr_consumed, more, i, notify;
-#ifdef HAVE_LIBC
-int some;
-#endif
+int dobreak;
 
 nr_consumed = 0;
 moretodo:
 rp = dev->rx.sring->rsp_prod;
 rmb(); /* Ensure we see queued responses up to 'rp'. */
 
-#ifdef HAVE_LIBC
-some = 0;
-#endif
-for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
+dobreak = 0;
+for (cons = dev->rx.rsp_cons; cons != rp && !dobreak; nr_consumed++, 
cons++)
 {
 struct net_buffer* buf;
 unsigned char* page;
@@ -134,8 +130,8 @@ moretodo:
len = dev->len;
memcpy(dev->data, page+rx->offset, len);
dev->rlen = len;
-   some = 1;
-break;
+   /* No need to receive the rest for now */
+   dobreak = 1;
} else
 #endif
dev->netif_rx(page+rx->offset,rx->status);
@@ -144,11 +140,7 @@ moretodo:
 dev->rx.rsp_cons=cons;
 
 RING_FINAL_CHECK_FOR_RESPONSES(>rx,more);
-#ifdef HAVE_LIBC
-if(more && !some) goto moretodo;
-#else
-if(more) goto moretodo;
-#endif
+if(more && !dobreak) goto moretodo;
 
 req_prod = dev->rx.req_prod_pvt;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

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  a67e68c6310e983c76a63cc4863b46ddde6d84db
baseline version:
 xen  0d42d461c21685258ac9c17bec7eaeb9ac2fce4c

Last test of basis87229  2016-03-24 20:01:45 Z0 days
Testing same since87332  2016-03-25 16:08:28 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Doug Goldstein 

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=a67e68c6310e983c76a63cc4863b46ddde6d84db
+ . ./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 
a67e68c6310e983c76a63cc4863b46ddde6d84db
+ branch=xen-unstable-smoke
+ revision=a67e68c6310e983c76a63cc4863b46ddde6d84db
+ . ./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
+ '[' xa67e68c6310e983c76a63cc4863b46ddde6d84db = 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/
+++ '[' 

Re: [Xen-devel] [PATCH v8 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS

[Chong Li]

On Mon, Mar 21, 2016 at 11:25 AM, Jan Beulich  wrote:
 On 21.03.16 at 17:03,  wrote:
>> On Mon, Mar 21, 2016 at 10:49 AM, Jan Beulich  wrote:
>> On 21.03.16 at 16:18,  wrote:
 On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich  wrote:
 On 18.03.16 at 22:26,  wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -338,24 +338,64 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t);
>>  #define XEN_SCHEDULER_ARINC653 7
>>  #define XEN_SCHEDULER_RTDS 8
>>
>> -/* Set or get info? */
>> +typedef struct xen_domctl_sched_credit {
>> +uint16_t weight;
>> +uint16_t cap;
>> +} xen_domctl_sched_credit_t;
>> +
>> +typedef struct xen_domctl_sched_credit2 {
>> +uint16_t weight;
>> +} xen_domctl_sched_credit2_t;
>> +
>> +typedef struct xen_domctl_sched_rtds {
>> +uint32_t period;
>> +uint32_t budget;
>> +} xen_domctl_sched_rtds_t;
>> +
>> +typedef struct xen_domctl_schedparam_vcpu {
>> +union {
>> +xen_domctl_sched_credit_t credit;
>> +xen_domctl_sched_credit2_t credit2;
>> +xen_domctl_sched_rtds_t rtds;
>> +} u;
>> +uint32_t vcpuid;
>> +uint16_t padding[2];
>
> So why uint16_t[2] instead of just uint32_t? And what's the
> padding needed for in the first place?

 You're right. It's better to use uint32_t, which pads (the struct) to
 the 64-bit boundary.
>>>
>>> Which doesn't answer the "why in the first place" part - I don't
>>> see why structure size needs to be a multiple of 64 bits.
>>>
>> In this patch post,
>>
>> http://lists.xen.org/archives/html/xen-devel/2015-07/msg02334.html
>>
>> you had a comment about the structure size, which I think you mean
>> the struct size should be a multiple of 64 bits.
>
> Looks like I had got mislead by there being struct
> xen_domctl_sched_sedf, but it not being part of the union. I'm
> sorry for that.
>
Ok. I've already fixed all problems pointed out by George and Jan.

Dario and Meng, do you have any other comments on this patch?

Chong



-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis

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

Re: [Xen-devel] [PATCH v3 4/4] x86: use 32-bit loads for 32-bit PV guest state reload

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 02:04:25AM -0600, Jan Beulich wrote:
> This is slightly more efficient than loading 64-bit quantities.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Konrad Rzeszutek Wilk]

> @@ -174,10 +174,61 @@ compat_bad_hypercall:
>  /* %rbx: struct vcpu, interrupts disabled */
>  ENTRY(compat_restore_all_guest)
>  ASSERT_INTERRUPTS_DISABLED
> +.Lcr4_orig:
> +ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */
> +ASM_NOP2 /* jpe   .Lcr4_alt_end */
> +ASM_NOP8 /* mov   CPUINFO_cr4...(%rsp), %rax */
> +ASM_NOP6 /* and   $..., %rax */
> +ASM_NOP8 /* mov   %rax, CPUINFO_cr4...(%rsp) */
> +ASM_NOP3 /* mov   %rax, %cr4 */
> +.Lcr4_orig_end:
> +.pushsection .altinstr_replacement, "ax"
> +.Lcr4_alt:
> +testb $3,UREGS_cs(%rsp)
> +jpe   .Lcr4_alt_end

This would jump if the last operation had even bits set. And the
'testb' is 'and' operation which would give us the '011' (for $3).

Why not just depend on the ZF ? Other places that test UREGS_cs()
look to be using that?

> +mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> +and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
> +mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> +mov   %rax, %cr4
> +.Lcr4_alt_end:
> +.section .altinstructions, "a"
> +altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMEP, \
> + (.Lcr4_orig_end - .Lcr4_orig), \
> + (.Lcr4_alt_end - .Lcr4_alt)
> +altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMAP, \
> + (.Lcr4_orig_end - .Lcr4_orig), \
> + (.Lcr4_alt_end - .Lcr4_alt)
> +.popsection
>  RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
>  _ASM_PRE_EXTABLE(.Lft0, handle_exception)
>  
> +/* This mustn't modify registers other than %rax. */
> +ENTRY(cr4_pv32_restore)
> +push  %rdx
> +GET_CPUINFO_FIELD(cr4, %rdx)
> +mov   (%rdx), %rax
> +test  $X86_CR4_SMEP|X86_CR4_SMAP,%eax
> +jnz   0f
> +orcr4_pv32_mask(%rip), %rax
> +mov   %rax, %cr4
> +mov   %rax, (%rdx)

Here you leave %rax with the cr4_pv32_mask value, but:

> +pop   %rdx
> +ret
> +0:
> +#ifndef NDEBUG
> +/* Check that _all_ of the bits intended to be set actually are. */
> +mov   %cr4, %rax
> +and   cr4_pv32_mask(%rip), %eax
> +cmp   cr4_pv32_mask(%rip), %eax
> +je1f
> +BUG
> +1:
> +#endif
> +pop   %rdx
> +xor   %eax, %eax

.. Here you clear it. Any particular reason?

> +ret
> +
>  /* %rdx: trap_bounce, %rbx: struct vcpu */
>  ENTRY(compat_post_handle_exception)
>  testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
.. snip..
> -.macro LOAD_C_CLOBBERED compat=0
> +.macro LOAD_C_CLOBBERED compat=0 ax=1
>  .if !\compat
>  movq  UREGS_r11(%rsp),%r11
>  movq  UREGS_r10(%rsp),%r10
>  movq  UREGS_r9(%rsp),%r9
>  movq  UREGS_r8(%rsp),%r8
> -.endif
> +.if \ax
>  movq  UREGS_rax(%rsp),%rax
> +.endif

Why the .endif here considering you are doing an:

> +.elseif \ax

an else if here?
> +movl  UREGS_rax(%rsp),%eax
> +.endif

Actually, Why two 'if ax' ? checks?

Or am I reading this incorrect?


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

[Xen-devel] compilation fail, xen staging-4.6, vnc.c, qemu-tradintional issues under ubuntu 16.04

[Éliás Tamás]

Hi.

Previously I was using debian 8 to compile my xen 4.6 with hvm
stubdomain support. We recently switched to ubuntu servers, thus I
needed to change my compilation environment not to have lib dependency
issues.

My problem is: I get the staging 4.6 xen
(http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=8e89d43867922abaa67e894938c655a6fa82affe;sf=tgz),
installed all required prereqs for my compilaton environment, but during
compilation I get errors (I do not get them using debian 8). I'm sure
that all prereq is met, becasuse ./configure runs correctly, I'm using
--enable-systemd --enable-stubdom )

Most of the problems could be solved by dirty hacks for myself, but I
belive they require some attention of qemu/xen developers to make
compilation work under ubuntu 16.04 out of the box:

The first issue

/usr/src/xen-staging-4.6/tools/qemu-xen-traditional-dir/vnc.c:2180:
undefined reference to `gnutls_kx_set_priority'

could be solved by applying these patches over the auto downloaded qemu
sources:

https://gitlab.com/johnth/aur-xen/raw/f9d0b40e240add9a136483a450c6a1b39a685808/qemu-xen-traditional-gnutls-compilation.patch

https://gitlab.com/johnth/aur-xen/raw/f9d0b40e240add9a136483a450c6a1b39a685808/qemu-xen-traditional-gnutls-functions.patch

after that I got

vl.c:2784:5: error: ‘g_mem_set_vtable’ is deprecated
[-Werror=deprecated-declarations]
 g_mem_set_vtable(_trace);


I had to apply

https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01262.html

which seemes that only partially been applied (has rejects), but after
modifying the sources by hand, it seemes working.

Just after this, Mini-OS failed to compile:

Makefile:17: /config/MiniOS.mk: No such file or directory

But, the MiniOS.mk DOES exists.

I had to manually add

XEN_ROOT=mysourcedir

to mini-os/Config.mk to continue. and now I'm stuck here:

gcc -mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone
-fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs   -fno-stack-protector -fno-exceptions
-DCONFIG_BLKFRONT -DCONFIG_TPMFRONT -DCONFIG_NETFRONT -DCONFIG_KBDFRONT
-DCONFIG_FBFRONT -DCONFIG_CONSFRONT -DCONFIG_XENBUS -fno-builtin -Wall
-Werror -Wredundant-decls -Wno-format -Wno-redundant-decls -Wformat
-fno-stack-protector -fgnu89-inline -Wstrict-prototypes -Wnested-externs
-Wpointer-arith -Winline -g -D__INSIDE_MINIOS__ -m64 -mno-red-zone
-fno-reorder-blocks -fno-asynchronous-unwind-tables -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC
-isystem /usr/src/xen-staging-4.6/extras/mini-os/include/posix -isystem
/usr/src/xen-staging-4.6/tools/xenstore/include  -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include/x86 -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include/x86/x86_64 -U __linux__
-U __FreeBSD__ -U __sun__ -nostdinc -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include/posix -isystem
/usr/src/xen-staging-4.6/stubdom/cross-root-x86_64/x86_64-xen-elf/include 
-isystem
/usr/lib/gcc/x86_64-linux-gnu/5/include -isystem
/usr/src/xen-staging-4.6/stubdom/lwip-x86_64/src/include -isystem
/usr/src/xen-staging-4.6/stubdom/lwip-x86_64/src/include/ipv4
-I/usr/src/xen-staging-4.6/stubdom/include
-I/usr/src/xen-staging-4.6/xen/include -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC
-isystem /usr/src/xen-staging-4.6/extras/mini-os/include/posix -isystem
/usr/src/xen-staging-4.6/tools/xenstore/include
-D__XEN_INTERFACE_VERSION__=0x00030205  -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include/x86 -isystem
/usr/src/xen-staging-4.6/extras/mini-os/include/x86/x86_64 -c
console/xenbus.c -o
/usr/src/xen-staging-4.6/stubdom/mini-os-x86_64-grub/console/xenbus.o
ld -r -d -nostdlib
-L/usr/src/xen-staging-4.6/stubdom/cross-root-x86_64/x86_64-xen-elf/lib
 -m elf_x86_64 -\( /usr/src/xen-staging-4.6/stubdom/grub-x86_64/main.a
app.lds -\)  -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/toollog
-whole-archive -lxentoollog -no-whole-archive
-L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/evtchn -whole-archive
-lxenevtchn -no-whole-archive
-L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/gnttab -whole-archive
-lxengnttab -no-whole-archive
-L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/call -whole-archive
-lxencall -no-whole-archive
-L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/foreignmemory
-whole-archive -lxenforeignmemory -no-whole-archive
-L/usr/src/xen-staging-4.6/stubdom/libxc-x86_64 -whole-archive
-lxenguest -lxenctrl -no-whole-archive -lpci -lz -lm --undefined main -o
/usr/src/xen-staging-4.6/stubdom/mini-os-x86_64-grub/mini-os_app.o
ld: warning: app.lds contains output sections; did you forget -T?
ld: cannot find -lxentoollog
ld: cannot find -lxenevtchn
ld: cannot find -lxengnttab
ld: cannot find -lxencall
ld: cannot find -lxenforeignmemory
Makefile:186: recipe for target

[Xen-devel] [linux-mingo-tip-master test] 87263: regressions - FAIL

[osstest service owner]

flight 87263 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87263/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 
60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

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-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  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-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  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

version targeted for testing:
 linuxee16c664e643b9f42296cc6f1dca230a39a9679b
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  225 days
Failing since 60712  2015-08-15 18:33:48 Z  222 days  168 attempts
Testing same since87263  2016-03-25 04:22:21 Z0 days1 attempts

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

Re: [Xen-devel] [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen

[Bjorn Helgaas]

On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
> 
> CC: "Rafael J. Wysocki"  (supporter:ACPI)
> CC: Len Brown  (supporter:ACPI)
> CC: linux-a...@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao 
> ---
>  drivers/acpi/scan.c | 68 
> +
>  1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>  DEFINE_MUTEX(acpi_device_lock);
>  LIST_HEAD(acpi_wakeup_device_list);
>  static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>  
>  struct acpi_dep_data {
>   struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device 
> **child,
>   return 0;
>  }
>  
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +  acpi_get_resource_memory, );
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table 
> will be hidden\n");

Can we at least print out the ACPI device path and address here for
debugging purposes?  IMHO, kernel messages that contain only static
text are always dubious.  There's almost always a useful address, IRQ,
return value, etc., that could be included.

> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>   unsigned long long *sta)
>  {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
> int *type,
>   switch (acpi_type) {
>   case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
>   case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
>   *type = ACPI_BUS_TYPE_DEVICE;
>   status = acpi_bus_get_status_handle(handle, sta);
>   if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
>   return result < 0 ? result : 0;
>  }
>  
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
> missing\n");
> +}
> +
>  int __init acpi_scan_init(void)
>  {
>   int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>  
>   acpi_pci_root_init();
>   acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>  
>   acpi_scan_add_handler(_device_handler);
>  
> + /*
> +  * If there is STAO table, check whether it needs to ignore the UART
> +  * device in SPCR table.
> +  */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet 
> supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }

This all seems sort of ad hoc.  Are UARTs the only things that can be
listed in STAO?  If STAO can contain things other than UARTs, are we
going to see more patches adding special-case code like this?

>   mutex_lock(_scan_lock);
>   /*
>* Enumerate devices in the ACPI namespace.
> -- 
> 2.0.4
> 
> 
> --
> To unsubscribe from this list: send the 

Re: [Xen-devel] [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen

[Rafael J. Wysocki]

On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
> 
> CC: "Rafael J. Wysocki"  (supporter:ACPI)
> CC: Len Brown  (supporter:ACPI)
> CC: linux-a...@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao 

So I said it looked good, but now that I think about it, I have a question. ->

> ---
>  drivers/acpi/scan.c | 68 
> +
>  1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>  DEFINE_MUTEX(acpi_device_lock);
>  LIST_HEAD(acpi_wakeup_device_list);
>  static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>  
>  struct acpi_dep_data {
>   struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device 
> **child,
>   return 0;
>  }
>  
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;

-> It looks like this will terminate on the first memory resource found,
but what if there are more of them?

Or is it guaranteed that there will be only one for the device objects in
question?

If not, then it would better to check res.start == spcr_uart_addr here too
and only terminate if there's a match.

> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +  acpi_get_resource_memory, );
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table 
> will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>   unsigned long long *sta)
>  {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
> int *type,
>   switch (acpi_type) {
>   case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
>   case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
>   *type = ACPI_BUS_TYPE_DEVICE;
>   status = acpi_bus_get_status_handle(handle, sta);
>   if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
>   return result < 0 ? result : 0;
>  }
>  
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
> missing\n");
> +}
> +
>  int __init acpi_scan_init(void)
>  {
>   int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>  
>   acpi_pci_root_init();
>   acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>  
>   acpi_scan_add_handler(_device_handler);
>  
> + /*
> +  * If there is STAO table, check whether it needs to ignore the UART
> +  * device in SPCR table.
> +  */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet 
> supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
>   mutex_lock(_scan_lock);
>   /*
>* Enumerate devices in the ACPI namespace.
> 


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

Re: [Xen-devel] [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 06:00:27PM +0100, Daniel Kiper wrote:
> Currently multiboot2 protocol loads image exactly at address specified in
> ELF or multiboot2 header. This solution works quite well on legacy BIOS
> platforms. It is possible because memory regions are placed at predictable
> addresses (though I was not able to find any spec which says that it is
> strong requirement, so, it looks that it is just a goodwill of hardware
> designers). However, EFI platforms are more volatile. Even if required
> memory regions live at specific addresses then they are sometimes simply
> not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> OVMF). This means that you are not able to just set up final image
> destination on build time. You have to provide method to relocate image
> contents to real load address which is usually different than load address
> specified in ELF and multiboot2 headers.
> 
> This patch provides all needed machinery to do self relocation in image code.
> First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
> align (required image alignment), preference (it says which memory regions are
> preferred by image, e.g. none, low, high) from 
> multiboot_header_tag_relocatable
> header tag contained in binary (at this stage load addresses from multiboot2
> and/or ELF headers are ignored). Later loader tries to fulfill request (not 
> only
> that one) and if it succeeds then it informs image about real load address via
> multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. 
> Starting
> from now executable must cope with relocations itself using whole static and
> dynamic knowledge provided by boot loader.
> 
> This patch does not provide functionality which could do relocations using
> ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and 
> Vladimir
> 'phcoder' Serbinenko to investigate that thing. It looks that relevant 
> machinery
> could be added to existing code (including this patch) without huge effort.
> Additionally, ELF relocation could live in parallel with self relocation 
> provided
> by this patch. However, during research I realized that first of all we should
> establish the details how ELF relocatable image should look like and how it 
> should
> be build. At least to build proper test/example files.
> 
> So, this patch just provides support for self relocatable images. If ELF file
> with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
> such files will be added later.
> 
> This patch was tested with Xen image which uses that functionality. However, 
> this Xen
> feature is still under development and new patchset will be released in about 
> 3-4 weeks.

> index e3a39b6..8a9ab0c 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c

..snip..
>  static grub_err_t
> -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, 
> void *buffer)
> +CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
>  {
> +#ifdef MULTIBOOT_LOAD_ELF64
> +  if (highest_load >= 0x1)
> +return grub_error (GRUB_ERR_BAD_OS, "segment cross 4 GiB border");

segment crosses 4GiB border!

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

Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block

[Wei Liu]

On Fri, Mar 25, 2016 at 12:34:29PM -0400, Ross Philipson wrote:
> On 03/25/2016 12:11 PM, Wei Liu wrote:
> > On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote:
> >> It seems the logic is meant to detect sector unaligned buffers for block
> >> writes. The NOTing of the logic instead masks off any unaligned bits and
> >> also would cause the function to always fail. It seems the function is not
> >> used in any of the tools so that is probably why the problem is not seen.
> >> In the vhd_read_block function it is correct.
> >>
> >> Signed-off-by: Ross Philipson 
> > 
> > This seems to fall under tools umbrella. I've look at blktap2 code,
> > the reasoning is convincing to me so:
> > 
> >   Acked-by: Wei Liu 
> > 
> > But I've never used blktap2 and we don't normally test it so I would
> > also wait a bit longer to see if anybody objects to this change.
> > 
> > OOI if no code was using this, how did you discover this problem?
> 
> We have an old fork of blktap2 from way back when. I was working to extract 
> our
> changes and turn them into patches so we could rebase on upstream blktap2.
> Someone long ago found that - I have no idea how but it was a valid fix so I
> upstreamed it.
> 
> There are a number of other ones that were found that are still in upstream
> blktap2 - I plan to send them too.
> 

Alright, much appreciated!

Wei.

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

Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block

[Ross Philipson]

On 03/25/2016 12:11 PM, Wei Liu wrote:
> On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote:
>> It seems the logic is meant to detect sector unaligned buffers for block
>> writes. The NOTing of the logic instead masks off any unaligned bits and
>> also would cause the function to always fail. It seems the function is not
>> used in any of the tools so that is probably why the problem is not seen.
>> In the vhd_read_block function it is correct.
>>
>> Signed-off-by: Ross Philipson 
> 
> This seems to fall under tools umbrella. I've look at blktap2 code,
> the reasoning is convincing to me so:
> 
>   Acked-by: Wei Liu 
> 
> But I've never used blktap2 and we don't normally test it so I would
> also wait a bit longer to see if anybody objects to this change.
> 
> OOI if no code was using this, how did you discover this problem?

We have an old fork of blktap2 from way back when. I was working to extract our
changes and turn them into patches so we could rebase on upstream blktap2.
Someone long ago found that - I have no idea how but it was a valid fix so I
upstreamed it.

There are a number of other ones that were found that are still in upstream
blktap2 - I plan to send them too.

> 
> Wei.
> 
>> ---
>> diff --git a/tools/blktap2/vhd/lib/libvhd.c b/tools/blktap2/vhd/lib/libvhd.c
>> index 1fd5b4e..4ebe012 100644
>> --- a/tools/blktap2/vhd/lib/libvhd.c
>> +++ b/tools/blktap2/vhd/lib/libvhd.c
>> @@ -2188,7 +2188,7 @@ vhd_write_block(vhd_context_t *ctx, uint32_t block, 
>> char *data)
>> if (block >= ctx->bat.entries)
>> return -ERANGE;
>>
>> -   if ((unsigned long)data & ~(VHD_SECTOR_SIZE -1))
>> +   if ((unsigned long)data & (VHD_SECTOR_SIZE -1))
>> return -EINVAL;
>>
>> blk  = ctx->bat.bat[block];
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


-- 
Ross Philipson

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

Re: [Xen-devel] [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 06:00:23PM +0100, Daniel Kiper wrote:
> Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
> will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
> On the other hand processor mode, just before jumping into loaded image, will
> be set accordingly to Unified Extensible Firmware Interface Specification,
> Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> loaded image will be able to use EFI boot services without any issues.
> 
> Signed-off-by: Daniel Kiper 

Reviewed-by: Konrad Rzeszutek Wilk 

.. with one modification:
.. snip..
> diff --git a/grub-core/lib/x86_64/efi/relocator.c 
> b/grub-core/lib/x86_64/efi/relocator.c
> new file mode 100644
> index 000..c93d061
> --- /dev/null
> +++ b/grub-core/lib/x86_64/efi/relocator.c
> +grub_err_t
> +grub_relocator64_efi_boot (struct grub_relocator *rel,
> +struct grub_relocator64_efi_state state)
> +{
> +  grub_err_t err;
> +  void *relst;
> +  grub_relocator_chunk_t ch;
> +
> +  err = grub_relocator_alloc_chunk_align (rel, , 0,
> +   0x4000 - RELOCATOR_SIZEOF 
> (64_efi),
  ^^ - why the 1GB?

Could you give a bit details on it? Or preferrable have a comment right
above saying what that value is used?

Thanks.

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

Re: [Xen-devel] [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.

[Daniel De Graaf]

On 03/24/2016 04:00 PM, Konrad Rzeszutek Wilk wrote:

The VERSION hypercall provides the flexibility to expose
the size of the build-id (so the callers can allocate the
proper size before trying to retrieve it). It also allows
in one nice swoop to retrieve the hypervisor build-id in the
provided buffer.

Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[Boris Ostrovsky]

On 03/25/2016 12:04 PM, Steven Haigh wrote:


It may not actually be the full logs. Once the system gets really upset,
you can't run anything - as such, grabbing anything from dmesg is not
possible.

The logs provided above is all that gets spat out to the syslog server.

I'll try tinkering with a few things to see if I can get more output -
but right now, that's all I've been able to achieve. So far, my only
ideas are to remove the 'quiet' options from the kernel command line -
but I'm not sure how much that would help.

Suggestions gladly accepted on this front.


You probably want to run connected to guest serial console (" 
serial='pty' " in guest config file and something like 'loglevel=7 
console=tty0 console=ttyS0,38400n8' on guest kernel commandline). And 
start the guest with 'xl create -c ' or connect later with 'xl 
console '.


-boris



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

Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block

[Wei Liu]

On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote:
> It seems the logic is meant to detect sector unaligned buffers for block
> writes. The NOTing of the logic instead masks off any unaligned bits and
> also would cause the function to always fail. It seems the function is not
> used in any of the tools so that is probably why the problem is not seen.
> In the vhd_read_block function it is correct.
> 
> Signed-off-by: Ross Philipson 

This seems to fall under tools umbrella. I've look at blktap2 code,
the reasoning is convincing to me so:

  Acked-by: Wei Liu 

But I've never used blktap2 and we don't normally test it so I would
also wait a bit longer to see if anybody objects to this change.

OOI if no code was using this, how did you discover this problem?

Wei.

> ---
> diff --git a/tools/blktap2/vhd/lib/libvhd.c b/tools/blktap2/vhd/lib/libvhd.c
> index 1fd5b4e..4ebe012 100644
> --- a/tools/blktap2/vhd/lib/libvhd.c
> +++ b/tools/blktap2/vhd/lib/libvhd.c
> @@ -2188,7 +2188,7 @@ vhd_write_block(vhd_context_t *ctx, uint32_t block, 
> char *data)
> if (block >= ctx->bat.entries)
> return -ERANGE;
> 
> -   if ((unsigned long)data & ~(VHD_SECTOR_SIZE -1))
> +   if ((unsigned long)data & (VHD_SECTOR_SIZE -1))
> return -EINVAL;
> 
> blk  = ctx->bat.bat[block];
> 
> ___
> 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] 4.4: INFO: rcu_sched self-detected stall on CPU

[Steven Haigh]

On 26/03/2016 1:44 AM, Boris Ostrovsky wrote:
> On 03/25/2016 10:05 AM, Steven Haigh wrote:
>> On 25/03/2016 11:23 PM, Boris Ostrovsky wrote:
>>> On 03/24/2016 10:53 PM, Steven Haigh wrote:
 Hi all,

 Firstly, I've cross-posted this to xen-devel and the lkml - as this
 problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
 I have also CC'ed Greg KH for his awesome insight as maintainer.

 Please CC myself into replies - as I'm not a member of the kernel
 mailing list - I may miss replies from monitoring the archives.

 I've noticed recently that heavy disk IO is causing rcu_sched to detect
 stalls. The process mentioned usually goes to 100% CPU usage, and
 eventually processes start segfaulting and dying. The only fix to
 recover the system is to use 'xl destroy' to force-kill the VM and to
 start it again.

 The majority of these issues seem to mention ext4 in the trace. This
 may
 indicate an issue there - or may be a red herring.

 The gritty details:
 INFO: rcu_sched self-detected stall on CPU
 #0110-...: (20999 ticks this GP) idle=327/141/0
 softirq=1101493/1101493 fqs=6973
 #011 (t=21000 jiffies g=827095 c=827094 q=524)
 Task dump for CPU 0:
 rsync   R  running task0  2446   2444 0x0088
 818d0c00 88007fc03c58 810a625f 
 818d0c00 88007fc03c70 810a8699 0001
 88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
 Call Trace:
   [] sched_show_task+0xaf/0x110
 [] dump_cpu_task+0x39/0x40
 [] rcu_dump_cpu_stacks+0x8a/0xc0
 [] rcu_check_callbacks+0x424/0x7a0
 [] ? account_system_time+0x81/0x110
 [] ? account_process_tick+0x61/0x160
 [] ? tick_sched_do_timer+0x30/0x30
 [] update_process_times+0x39/0x60
 [] tick_sched_handle.isra.15+0x36/0x50
 [] tick_sched_timer+0x3d/0x70
 [] __hrtimer_run_queues+0xf2/0x250
 [] hrtimer_interrupt+0xa8/0x190
 [] xen_timer_interrupt+0x2e/0x140
 [] handle_irq_event_percpu+0x55/0x1e0
 [] handle_percpu_irq+0x3a/0x50
 [] generic_handle_irq+0x22/0x30
 [] __evtchn_fifo_handle_events+0x15f/0x180
 [] evtchn_fifo_handle_events+0x10/0x20
 [] __xen_evtchn_do_upcall+0x43/0x80
 [] xen_evtchn_do_upcall+0x30/0x50
 [] xen_hvm_callback_vector+0x82/0x90
   [] ? queued_write_lock_slowpath+0x3d/0x80
 [] _raw_write_lock+0x1e/0x30
>>> This looks to me like ext4 failing to grab a lock. Everything above it
>>> (in Xen code) is regular tick interrupt handling which detects the
>>> stall.
>>>
>>> Your config does not have CONFIG_PARAVIRT_SPINLOCKS so that eliminates
>>> any possible issues with pv locks.
>>>
>>> Do you see anything "interesting" in dom0? (e.g. dmesg, xl dmesg,
>>> /var/log/xen/) Are you oversubscribing your guest (CPU-wise)?
>> There is nothing special being logged anywhere that I can see. dmesg /
>> xl dmesg on the Dom0 show nothing unusual.
>>
>> I do share CPUs - but I don't give any DomU more than 2 vcpus. The
>> physical host has 4 cores - 1 pinned to the Dom0.
>>
>> I log to a remote syslog on this system - and I've uploaded the entire
>> log to a pastebin (don't want to do a 45Kb attachment here):
>>  http://paste.fedoraproject.org/345095/58914452
> 
> That doesn't look like a full log. In any case, the RCU stall may be a
> secondary problem --- there is a bunch of splats before the stall.

It may not actually be the full logs. Once the system gets really upset,
you can't run anything - as such, grabbing anything from dmesg is not
possible.

The logs provided above is all that gets spat out to the syslog server.

I'll try tinkering with a few things to see if I can get more output -
but right now, that's all I've been able to achieve. So far, my only
ideas are to remove the 'quiet' options from the kernel command line -
but I'm not sure how much that would help.

Suggestions gladly accepted on this front.

>>
>> Not sure if it makes any difference at all, but my DomU config is:
>> # cat /etc/xen/backup.vm
>> name= "backup.vm"
>> memory  = 2048
>> vcpus   = 2
>> cpus= "1-3"
>> disk= [ 'phy:/dev/vg_raid1_new/backup.vm,xvda,w' ]
>> vif = [ "mac=00:11:36:35:35:09, bridge=br203,
>> vifname=vm.backup, script=vif-bridge" ]
>> bootloader  = 'pygrub'
>> pvh = 1
>>
>> on_poweroff = 'destroy'
>> on_reboot   = 'restart'
>> on_crash= 'restart'
>> cpu_weight  = 64
>>
>> I never had this problem when running kernel 4.1.x - it only started
>> when I upgraded everything to 4.4 - not exactly a great help - but may
>> help narrow things down?
>>
 [] ext4_es_remove_extent+0x43/0xc0
 [] ext4_clear_inode+0x39/0x80
 [] ext4_evict_inode+0x8d/0x4e0
 [] evict+0xb7/0x180
 [] dispose_list+0x36/0x50
 [] prune_icache_sb+0x4b/0x60
 [] 

Re: [Xen-devel] [PATCH] tools/python/xc: fix tmem_control parameter parsing

[Wei Liu]

On Wed, Mar 23, 2016 at 01:45:37PM -0400, Zhigang Wang wrote:
> There should be 6 instead of 7 arguments now for tmem_control().
> 
> Signed-off-by: Zhigang Wang 

Acked-by: Wei Liu 

> ---
>  tools/python/xen/lowlevel/xc/xc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c 
> b/tools/python/xen/lowlevel/xc/xc.c
> index c40a4e9..ff714d7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1620,7 +1620,7 @@ static PyObject *pyxc_tmem_control(XcObject *self,
>  
>  static char *kwd_list[] = { "pool_id", "subop", "cli_id", "arg1", 
> "arg2", "buf", NULL };
>  
> -if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iis", kwd_list,
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
>  _id, , _id, , , ) )
>  return NULL;
>  
> -- 
> 2.5.5
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v13 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service

[Wei Liu]

On Fri, Mar 25, 2016 at 02:44:07PM +0800, Changlong Xie wrote:
> This patchset implemented the COLO feature for Xen.
> For detail/install/use of COLO feature, refer to:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
> 
> You can get the codes from here:
> https://github.com/Pating/xen/tree/changlox/colo_v13
> 
> Changlog from v12 to v13
> 1. Rebase to the upstream xen
> 2. Address commnets from Ian and Liu Wei.
> p7, Add A-B
> p8, Add A-B
> p10, Add A-B
> p11, Add A-B
> p12, Add LOG(ERROR, ) 
> p13, Add A-B
> p14, Remove libxl__ao_complete(xxx)
> p15, Add A-B
> p16, Add A-B
> p17, Add A-B, replace "-c" with "--colo" for migrate-receive()
> p19, Add A-B, introduce "switch ... case ..." 
> p21, Add A-B
> p22, Add A-B
> p23, replace "forwarddev" with "coloft_fowarddev" 
> p24, Add A-B
> p25, Add A-B
> p26, replace "--script" with "--coloft-script" 

I went over those unacked patches. The major thing I found is that you
didn't add in the warning text as Ian suggested. I've pointed out one
instance where you should add that. However, xl manage and libxl header
file changes are spread across multiple commits, so I'm not quite sure
which particular commit you should add in warning text.

I propose that you submit a separate patch to xl manpage and libxl
header file for adding warning text after the majority part of this
series is merged.

Wei.

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

Re: [Xen-devel] [PATCH 2/2] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()

[Konrad Rzeszutek Wilk]

On Fri, Mar 25, 2016 at 11:08:32AM -0400, Boris Ostrovsky wrote:
> On 03/25/2016 10:53 AM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Mar 17, 2016 at 09:03:25AM -0400, Boris Ostrovsky wrote:
> >>This call has always been missing from xen_play dead() but until
> >>recently this was rather benign. With new cpu hotplug framework
> >>however this call is required, otherwise a hot-plugged CPU will not
> >Could you include the commit id of the 'new cpu hotplug' in case
> >anybody wants to backport this?
> 
> Sure.
> 
> It's commit 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully
> up").
> 
> Do you (or David) want me to re-send it?

That is OK. I've updated the patch and committed both of them in for-linus-4.6.

Thanks!
> 
> -boris
> 
> 
> 
> >
> >Thanks!
> >>be properly brough up (by never calling cpuhp_online_idle())
> >>
> >>Signed-off-by: Boris Ostrovsky 
> >>---
> >>  arch/x86/xen/smp.c |2 ++
> >>  1 files changed, 2 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> >>index 3c6d17f..719cf29 100644
> >>--- a/arch/x86/xen/smp.c
> >>+++ b/arch/x86/xen/smp.c
> >>@@ -545,6 +545,8 @@ static void xen_play_dead(void) /* used only with 
> >>HOTPLUG_CPU */
> >> * data back is to call:
> >> */
> >>tick_nohz_idle_enter();
> >>+
> >>+   cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
> >>  }
> >>  #else /* !CONFIG_HOTPLUG_CPU */
> >>-- 
> >>1.7.1
> >>
> 

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

Re: [Xen-devel] [PATCH v2 1/2] xsm: only define XSM_MAGIC in xsm.h

[Konrad Rzeszutek Wilk]

On Fri, Mar 25, 2016 at 11:07:19AM -0400, Daniel De Graaf wrote:
> On 03/16/2016 03:18 PM, Doug Goldstein wrote:
> >Rather than have XSM_MAGIC set in the global xen/config.h and set in
> >xsm.h if it's unset, just set it once in xsm.h since its only used in
> >files that already include xsm.h
> >
> >Signed-off-by: Doug Goldstein 
> 
> Acked-by: Daniel De Graaf 

Both patches applied.
> 
> ___
> 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 v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id

[Wei Liu]

On Fri, Mar 25, 2016 at 09:25:22AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 04:00:33PM -0400, Konrad Rzeszutek Wilk wrote:
> > If the hypervisor is built with we will display it.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > Acked-by: Wei Liu 
> 
> Hey Wei,
> 
> It has you Ack, but I think when I carried over the change (it used
> to be its own function with switch) I messed up the Style:
> 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index 6c3ec40..310a7f3 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5277,8 +5278,24 @@ const libxl_version_info* 
> > libxl_get_version_info(libxl_ctx *ctx)
> >  
> >  info->virt_start = val;
> >  
> > -(void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> > -info->pagesize, >commandline);
> > +if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> > +  info->pagesize, >commandline) < 0)
> > +goto out;
> > +
> > +r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> > +if (r < 0)
> > +{
> > +info->build_id = libxl__strdup(NOGC, "");
> > +}
> > +else if (r > 0)
> > +{
> > +unsigned int i;
> > +
> > +info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> > +
> > +for (i = 0; i < r; i++)
> > +snprintf(>build_id[i * 2], 3, "%02hhx", buf[i]);
> > +}
> >   out:
> >  GC_FREE;
> >  return info;
> 
> So I fixed it up to be:
> 
> From bc4ed9d93162325342a37122fcab7223fcd61430 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Fri, 18 Mar 2016 14:56:13 -0400
> Subject: [PATCH] libxl: info: Display build_id of the hypervisor using
>  XEN_VERSION_build_id
> 
> If the hypervisor is built with we will display it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> 

I skim-read it. Looks fine:

Acked-by: Wei Liu 

> ---
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> 
> v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
> v3: Retry with different size if 1020 is not enough.
> v4: Use VERSION_OP subops instead of the XENVER_ subops
> v5: Change it per Wei's review. s/VERSION_OP/VERSION/
> And actually use the proper Style!
> ---
>  tools/libxl/libxl.c | 18 --
>  tools/libxl/libxl.h |  6 ++
>  tools/libxl/libxl_types.idl |  1 +
>  tools/libxl/xl_cmdimpl.c|  1 +
>  4 files changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 704e7b4..dea5d25 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5233,6 +5233,7 @@ const libxl_version_info* 
> libxl_get_version_info(libxl_ctx *ctx)
>  GC_INIT(ctx);
>  char *buf;
>  xen_version_op_val_t val = 0;
> +int r;
>  libxl_version_info *info = >version_info;
>  
>  if (info->xen_version_extra != NULL)
> @@ -5275,8 +5276,21 @@ const libxl_version_info* 
> libxl_get_version_info(libxl_ctx *ctx)
>  
>  info->virt_start = val;
>  
> -(void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> -info->pagesize, >commandline);
> +if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> +  info->pagesize, >commandline) < 0)
> +goto out;
> +
> +r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> +if (r < 0) {
> +info->build_id = libxl__strdup(NOGC, "");
> +} else if (r > 0) {
> +unsigned int i;
> +
> +info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> +
> +for (i = 0; i < r; i++)
> +snprintf(>build_id[i * 2], 3, "%02hhx", buf[i]);
> +}
>   out:
>  GC_FREE;
>  return info;
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index f61bc4b..5baffdf 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -230,6 +230,12 @@
>  #define LIBXL_HAVE_APIC_ASSIST 1
>  
>  /*
> + * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
> + * field for the hypervisor build_id.
> + */
> +#define LIBXL_HAVE_BUILD_ID 1
> +
> +/*
>   * libxl ABI compatibility
>   *
>   * The only guarantee which libxl makes regarding ABI compatibility
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 59b183c..e3a5707 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -363,6 +363,7 @@ libxl_version_info = Struct("version_info", [
>  ("virt_start",uint64),
>  ("pagesize",  integer),
>  ("commandline",   string),
> +("build_id",  string),
>  ], dir=DIR_OUT)
>  
>  libxl_domain_create_info = Struct("domain_create_info",[
> diff --git 

Re: [Xen-devel] [PATCH 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()

[Boris Ostrovsky]

On 03/25/2016 11:10 AM, Konrad Rzeszutek Wilk wrote:

On Thu, Mar 17, 2016 at 09:33:32AM -0400, Boris Ostrovsky wrote:

Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around
__cpu_up() and move it to x86 for now") reverted irq locking
introduced by commit a89941816726 ("hotplug: Prevent alloc/free
of irq descriptors during cpu up/down") because of Xen allocating
irqs in both of its cpu_up ops.

We can move those allocations into CPU notifiers so that original
patch can be reinstated.

Original being "hotplug: Prevent alloc/free..." ?


Yes.



-static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long 
action,
- void *hcpu)
+static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
+ void *hcpu)
  {
int cpu = (long)hcpu;
+   int rc;
+
switch (action) {
case CPU_UP_PREPARE:
-   xen_vcpu_setup(cpu);
-   if (xen_have_vector_callback) {
-   if (xen_feature(XENFEAT_hvm_safe_pvclock))
-   xen_setup_timer(cpu);
+   if (xen_hvm_domain()) {
+   /*
+* This can happen if CPU was offlined earlier and
+* offlining timed out in common_cpu_die().
+*/
+   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
+   }
+
+   xen_vcpu_setup(cpu);
}
+
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
+   xen_setup_timer(cpu);
+
+   rc = xen_smp_intr_init(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
+cpu, rc);
+   return NOTIFY_BAD;
+   }
+
+   break;
+   case CPU_ONLINE:
+   xen_init_lock_cpu(cpu);
+   break;
+   case CPU_UP_CANCELED:
+   xen_smp_intr_free(cpu);
xen_uninit_lock_cpu ?


I don't think this is needed: we initialize lock in CPU_ONLINE notifier 
which can only be called after CPU_UP_CANCELED would have run (in which 
case we'll never do CPU_ONLINE)


-boris





+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
+   xen_teardown_timer(cpu);
break;
default:
break;



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

[Xen-devel] [qemu-mainline test] 87241: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 86454
 test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 86454
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 86454
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install   fail REGR. vs. 86454
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 86454
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 86454
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86454

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-amd64-amd64-libvirt-vhd 11 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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 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
 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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub68a80139e37e806f004237e55311ebc42151434
baseline version:
 qemuud1f8764099022bc1173f2413331b26d4ff609a0c

Last test of basis86454  2016-03-17 06:01:30 Z8 days
Failing since 86547  2016-03-18 07:12:41 Z7 days7 attempts
Testing same since87241  2016-03-24 22:14:40 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alexey Kardashevskiy 
  Andrew Baumann 
  Bastian Koppelmann 
  Benjamin Herrenschmidt 
  Christophe Fergeau 
  Cornelia Huck 

Re: [Xen-devel] [PATCH 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 09:33:32AM -0400, Boris Ostrovsky wrote:
> Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around
> __cpu_up() and move it to x86 for now") reverted irq locking
> introduced by commit a89941816726 ("hotplug: Prevent alloc/free
> of irq descriptors during cpu up/down") because of Xen allocating
> irqs in both of its cpu_up ops.
> 
> We can move those allocations into CPU notifiers so that original
> patch can be reinstated.

Original being "hotplug: Prevent alloc/free..." ?

> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/enlighten.c |   53 ++---
>  arch/x86/xen/smp.c   |   45 +-
>  arch/x86/xen/smp.h   |3 ++
>  3 files changed, 49 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 2c26108..d1a86db 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -137,6 +137,8 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  
> +static struct notifier_block xen_cpu_notifier;
> +
>  /*
>   * Point at some empty memory to start with. We map the real shared_info
>   * page as soon as fixmap is up and running.
> @@ -1596,6 +1598,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
>   xen_initial_gdt = _cpu(gdt_page, 0);
>  
>   xen_smp_init();
> + register_cpu_notifier(_cpu_notifier);
>  
>  #ifdef CONFIG_ACPI_NUMA
>   /*
> @@ -1783,17 +1786,49 @@ static void __init init_hvm_pv_info(void)
>   xen_domain_type = XEN_HVM_DOMAIN;
>  }
>  
> -static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long 
> action,
> -   void *hcpu)
> +static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
> +   void *hcpu)
>  {
>   int cpu = (long)hcpu;
> + int rc;
> +
>   switch (action) {
>   case CPU_UP_PREPARE:
> - xen_vcpu_setup(cpu);
> - if (xen_have_vector_callback) {
> - if (xen_feature(XENFEAT_hvm_safe_pvclock))
> - xen_setup_timer(cpu);
> + if (xen_hvm_domain()) {
> + /*
> +  * This can happen if CPU was offlined earlier and
> +  * offlining timed out in common_cpu_die().
> +  */
> + if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
> + xen_smp_intr_free(cpu);
> + xen_uninit_lock_cpu(cpu);
> + }
> +
> + xen_vcpu_setup(cpu);
>   }
> +
> + if (xen_pv_domain() ||
> + (xen_have_vector_callback &&
> +  xen_feature(XENFEAT_hvm_safe_pvclock)))
> + xen_setup_timer(cpu);
> +
> + rc = xen_smp_intr_init(cpu);
> + if (rc) {
> + WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
> +  cpu, rc);
> + return NOTIFY_BAD;
> + }
> +
> + break;
> + case CPU_ONLINE:
> + xen_init_lock_cpu(cpu);
> + break;
> + case CPU_UP_CANCELED:
> + xen_smp_intr_free(cpu);

xen_uninit_lock_cpu ?


> + if (xen_pv_domain() ||
> + (xen_have_vector_callback &&
> +  xen_feature(XENFEAT_hvm_safe_pvclock)))
> + xen_teardown_timer(cpu);
>   break;
>   default:
>   break;
> @@ -1801,8 +1836,8 @@ static int xen_hvm_cpu_notify(struct notifier_block 
> *self, unsigned long action,
>   return NOTIFY_OK;
>  }
>  
> -static struct notifier_block xen_hvm_cpu_notifier = {
> - .notifier_call  = xen_hvm_cpu_notify,
> +static struct notifier_block xen_cpu_notifier = {
> + .notifier_call  = xen_cpu_notify,
>  };
>  
>  #ifdef CONFIG_KEXEC_CORE
> @@ -1834,7 +1869,7 @@ static void __init xen_hvm_guest_init(void)
>   if (xen_feature(XENFEAT_hvm_callback_vector))
>   xen_have_vector_callback = 1;
>   xen_hvm_smp_init();
> - register_cpu_notifier(_hvm_cpu_notifier);
> + register_cpu_notifier(_cpu_notifier);
>   xen_unplug_emulated_devices();
>   x86_init.irqs.intr_init = xen_init_IRQ;
>   xen_hvm_init_time_ops();
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 719cf29..09d5cc0 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -115,7 +115,7 @@ asmlinkage __visible void cpu_bringup_and_idle(int cpu)
>   cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
>  }
>  
> -static void xen_smp_intr_free(unsigned int cpu)
> +void xen_smp_intr_free(unsigned int cpu)
>  {
>   if (per_cpu(xen_resched_irq, cpu).irq >= 0) {
>   unbind_from_irqhandler(per_cpu(xen_resched_irq, 

Re: [Xen-devel] [PATCH 2/2] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()

[Boris Ostrovsky]

On 03/25/2016 10:53 AM, Konrad Rzeszutek Wilk wrote:

On Thu, Mar 17, 2016 at 09:03:25AM -0400, Boris Ostrovsky wrote:

This call has always been missing from xen_play dead() but until
recently this was rather benign. With new cpu hotplug framework
however this call is required, otherwise a hot-plugged CPU will not

Could you include the commit id of the 'new cpu hotplug' in case
anybody wants to backport this?


Sure.

It's commit 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself 
fully up").


Do you (or David) want me to re-send it?

-boris





Thanks!

be properly brough up (by never calling cpuhp_online_idle())

Signed-off-by: Boris Ostrovsky 
---
  arch/x86/xen/smp.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3c6d17f..719cf29 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -545,6 +545,8 @@ static void xen_play_dead(void) /* used only with 
HOTPLUG_CPU */
 * data back is to call:
 */
tick_nohz_idle_enter();
+
+   cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
  }
  
  #else /* !CONFIG_HOTPLUG_CPU */

--
1.7.1




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

Re: [Xen-devel] [PATCH v2 1/2] xsm: only define XSM_MAGIC in xsm.h

[Daniel De Graaf]

On 03/16/2016 03:18 PM, Doug Goldstein wrote:

Rather than have XSM_MAGIC set in the global xen/config.h and set in
xsm.h if it's unset, just set it once in xsm.h since its only used in
files that already include xsm.h

Signed-off-by: Doug Goldstein 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 2/2] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 09:03:25AM -0400, Boris Ostrovsky wrote:
> This call has always been missing from xen_play dead() but until
> recently this was rather benign. With new cpu hotplug framework
> however this call is required, otherwise a hot-plugged CPU will not

Could you include the commit id of the 'new cpu hotplug' in case
anybody wants to backport this?

Thanks!
> be properly brough up (by never calling cpuhp_online_idle())
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/smp.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3c6d17f..719cf29 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -545,6 +545,8 @@ static void xen_play_dead(void) /* used only with 
> HOTPLUG_CPU */
>* data back is to call:
>*/
>   tick_nohz_idle_enter();
> +
> + cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
>  }
>  
>  #else /* !CONFIG_HOTPLUG_CPU */
> -- 
> 1.7.1
> 

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

Re: [Xen-devel] [PATCH 1/2] xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 09:03:24AM -0400, Boris Ostrovsky wrote:
> Currently Xen uses default_cpu_present_to_apicid() which will always
> report BAD_APICID for PV guests since x86_bios_cpu_apic_id is initialised
> to that value and is never updated.
> 
> With commit 1f12e32f4cd5 ("x86/topology: Create logical package id"), this
> op is now called by smp_init_package_map() when deciding whether to call
> topology_update_package_map() which sets cpu_data(cpu).logical_proc_id.
> The latter (as topology_logical_package_id(cpu)) may be used, for example,
> by cpu_to_rapl_pmu() as an array index. Since uninitialized
> logical_package_id is set to -1, the index will become 64K which is
> obviously problematic.
> 
> While RAPL code (and any other users of logical_package_id) should be
> careful in their assumptions about id's validity, Xen's
> cpu_present_to_apicid op should still provide value consistent with its
> own xen_apic_read(APIC_ID).
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  arch/x86/xen/apic.c |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
> index abf4901..db52a7f 100644
> --- a/arch/x86/xen/apic.c
> +++ b/arch/x86/xen/apic.c
> @@ -66,7 +66,7 @@ static u32 xen_apic_read(u32 reg)
>  
>   ret = HYPERVISOR_platform_op();
>   if (ret)
> - return 0;
> + op.u.pcpu_info.apic_id = BAD_APICID;
>  
>   return op.u.pcpu_info.apic_id << 24;
>  }
> @@ -142,6 +142,14 @@ static void xen_silent_inquire(int apicid)
>  {
>  }
>  
> +static int xen_cpu_present_to_apicid(int cpu)
> +{
> + if (cpu_present(cpu))
> + return xen_get_apic_id(xen_apic_read(APIC_ID));
> + else
> + return BAD_APICID;
> +}
> +
>  static struct apic xen_pv_apic = {
>   .name   = "Xen PV",
>   .probe  = xen_apic_probe_pv,
> @@ -162,7 +170,7 @@ static struct apic xen_pv_apic = {
>  
>   .ioapic_phys_id_map = default_ioapic_phys_id_map, /* Used 
> on 32-bit */
>   .setup_apic_routing = NULL,
> - .cpu_present_to_apicid  = default_cpu_present_to_apicid,
> + .cpu_present_to_apicid  = xen_cpu_present_to_apicid,
>   .apicid_to_cpu_present  = physid_set_mask_of_physid, /* Used on 
> 32-bit */
>   .check_phys_apicid_present  = default_check_phys_apicid_present, /* 
> smp_sanity_check needs it */
>   .phys_pkg_id= xen_phys_pkg_id, /* detect_ht */
> -- 
> 1.7.1
> 

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

[Xen-devel] [libvirt test] 87264: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 87134
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 87134

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  3e5b35a538f507ed23d4130b6aa5dfcee28b7c67
baseline version:
 libvirt  360229e8b4c0d99cb90ae83875566170187d6bb1

Last test of basis87134  2016-03-24 04:31:59 Z1 days
Testing same since87264  2016-03-25 04:21:34 Z0 days1 attempts


People who touched revisions under test:
  Erik Skultety 
  Jovanka Gulicoska 
  Michal Privoznik 
  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


Not pushing.


commit 3e5b35a538f507ed23d4130b6aa5dfcee28b7c67
Author: Jovanka Gulicoska 
Date:   Wed Mar 23 19:32:13 2016 +0100

qemu: Replace some VIR_ERROR with vir*Error

qemuStateInitialize uses a mix of VIR_ERROR and standard vir*Error
calls. Prefer the standard vir*Error

commit 2c20574d5b5c8448cf4e4da6c5bd964ada8f09d4
Author: Jovanka Gulicoska 
Date:   Wed Mar 23 19:31:50 2016 +0100

qemu: Don't duplicate virGetLastErrorMessage

These uses of virGetLastError message are just duplicating
virGetLastErrorMessage.

commit 98354e362c94ab3053db45aad0c8e4ef352fcdee
Author: Michal Privoznik 

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[Boris Ostrovsky]

On 03/25/2016 10:05 AM, Steven Haigh wrote:

On 25/03/2016 11:23 PM, Boris Ostrovsky wrote:

On 03/24/2016 10:53 PM, Steven Haigh wrote:

Hi all,

Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I have also CC'ed Greg KH for his awesome insight as maintainer.

Please CC myself into replies - as I'm not a member of the kernel
mailing list - I may miss replies from monitoring the archives.

I've noticed recently that heavy disk IO is causing rcu_sched to detect
stalls. The process mentioned usually goes to 100% CPU usage, and
eventually processes start segfaulting and dying. The only fix to
recover the system is to use 'xl destroy' to force-kill the VM and to
start it again.

The majority of these issues seem to mention ext4 in the trace. This may
indicate an issue there - or may be a red herring.

The gritty details:
INFO: rcu_sched self-detected stall on CPU
#0110-...: (20999 ticks this GP) idle=327/141/0
softirq=1101493/1101493 fqs=6973
#011 (t=21000 jiffies g=827095 c=827094 q=524)
Task dump for CPU 0:
rsync   R  running task0  2446   2444 0x0088
818d0c00 88007fc03c58 810a625f 
818d0c00 88007fc03c70 810a8699 0001
88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
Call Trace:
  [] sched_show_task+0xaf/0x110
[] dump_cpu_task+0x39/0x40
[] rcu_dump_cpu_stacks+0x8a/0xc0
[] rcu_check_callbacks+0x424/0x7a0
[] ? account_system_time+0x81/0x110
[] ? account_process_tick+0x61/0x160
[] ? tick_sched_do_timer+0x30/0x30
[] update_process_times+0x39/0x60
[] tick_sched_handle.isra.15+0x36/0x50
[] tick_sched_timer+0x3d/0x70
[] __hrtimer_run_queues+0xf2/0x250
[] hrtimer_interrupt+0xa8/0x190
[] xen_timer_interrupt+0x2e/0x140
[] handle_irq_event_percpu+0x55/0x1e0
[] handle_percpu_irq+0x3a/0x50
[] generic_handle_irq+0x22/0x30
[] __evtchn_fifo_handle_events+0x15f/0x180
[] evtchn_fifo_handle_events+0x10/0x20
[] __xen_evtchn_do_upcall+0x43/0x80
[] xen_evtchn_do_upcall+0x30/0x50
[] xen_hvm_callback_vector+0x82/0x90
  [] ? queued_write_lock_slowpath+0x3d/0x80
[] _raw_write_lock+0x1e/0x30

This looks to me like ext4 failing to grab a lock. Everything above it
(in Xen code) is regular tick interrupt handling which detects the stall.

Your config does not have CONFIG_PARAVIRT_SPINLOCKS so that eliminates
any possible issues with pv locks.

Do you see anything "interesting" in dom0? (e.g. dmesg, xl dmesg,
/var/log/xen/) Are you oversubscribing your guest (CPU-wise)?

There is nothing special being logged anywhere that I can see. dmesg /
xl dmesg on the Dom0 show nothing unusual.

I do share CPUs - but I don't give any DomU more than 2 vcpus. The
physical host has 4 cores - 1 pinned to the Dom0.

I log to a remote syslog on this system - and I've uploaded the entire
log to a pastebin (don't want to do a 45Kb attachment here):
 http://paste.fedoraproject.org/345095/58914452


That doesn't look like a full log. In any case, the RCU stall may be a 
secondary problem --- there is a bunch of splats before the stall.


-boris




Not sure if it makes any difference at all, but my DomU config is:
# cat /etc/xen/backup.vm
name= "backup.vm"
memory  = 2048
vcpus   = 2
cpus= "1-3"
disk= [ 'phy:/dev/vg_raid1_new/backup.vm,xvda,w' ]
vif = [ "mac=00:11:36:35:35:09, bridge=br203,
vifname=vm.backup, script=vif-bridge" ]
bootloader  = 'pygrub'
pvh = 1

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash= 'restart'
cpu_weight  = 64

I never had this problem when running kernel 4.1.x - it only started
when I upgraded everything to 4.4 - not exactly a great help - but may
help narrow things down?


[] ext4_es_remove_extent+0x43/0xc0
[] ext4_clear_inode+0x39/0x80
[] ext4_evict_inode+0x8d/0x4e0
[] evict+0xb7/0x180
[] dispose_list+0x36/0x50
[] prune_icache_sb+0x4b/0x60
[] super_cache_scan+0x141/0x190
[] shrink_slab.part.37+0x1ee/0x390
[] shrink_zone+0x26c/0x280
[] do_try_to_free_pages+0x15c/0x410
[] try_to_free_pages+0xba/0x170
[] __alloc_pages_nodemask+0x525/0xa60
[] ? kmem_cache_free+0xcc/0x2c0
[] alloc_pages_current+0x8d/0x120
[] __page_cache_alloc+0x91/0xc0
[] pagecache_get_page+0x56/0x1e0
[] grab_cache_page_write_begin+0x26/0x40
[] ext4_da_write_begin+0xa1/0x300
[] ? ext4_da_write_end+0x124/0x2b0
[] generic_perform_write+0xc0/0x1a0
[] __generic_file_write_iter+0x188/0x1e0
[] ext4_file_write_iter+0xf0/0x340
[] __vfs_write+0xaa/0xe0
[] vfs_write+0xa2/0x1a0
[] SyS_write+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x71

Some 11 hours later:
sshd[785]: segfault at 1f0 ip 7f03bb94ae5c sp 7ffe9eb54470 error
4 in ld-2.17.so[7f03bb94+21000]
sh[787]: segfault at 1f0 ip 7f6b4a0dfe5c sp 7ffe3d4a71e0 error 4
in ld-2.17.so[7f6b4a0d5000+21000]
systemd-cgroups[788]: segfault at 1f0 ip 7f4baa82ce5c sp
7ffd28e4c4b0 error 4 in 

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[Steven Haigh]

On 25/03/2016 11:23 PM, Boris Ostrovsky wrote:
> On 03/24/2016 10:53 PM, Steven Haigh wrote:
>> Hi all,
>>
>> Firstly, I've cross-posted this to xen-devel and the lkml - as this
>> problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
>> I have also CC'ed Greg KH for his awesome insight as maintainer.
>>
>> Please CC myself into replies - as I'm not a member of the kernel
>> mailing list - I may miss replies from monitoring the archives.
>>
>> I've noticed recently that heavy disk IO is causing rcu_sched to detect
>> stalls. The process mentioned usually goes to 100% CPU usage, and
>> eventually processes start segfaulting and dying. The only fix to
>> recover the system is to use 'xl destroy' to force-kill the VM and to
>> start it again.
>>
>> The majority of these issues seem to mention ext4 in the trace. This may
>> indicate an issue there - or may be a red herring.
>>
>> The gritty details:
>> INFO: rcu_sched self-detected stall on CPU
>> #0110-...: (20999 ticks this GP) idle=327/141/0
>> softirq=1101493/1101493 fqs=6973
>> #011 (t=21000 jiffies g=827095 c=827094 q=524)
>> Task dump for CPU 0:
>> rsync   R  running task0  2446   2444 0x0088
>> 818d0c00 88007fc03c58 810a625f 
>> 818d0c00 88007fc03c70 810a8699 0001
>> 88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
>> Call Trace:
>>   [] sched_show_task+0xaf/0x110
>> [] dump_cpu_task+0x39/0x40
>> [] rcu_dump_cpu_stacks+0x8a/0xc0
>> [] rcu_check_callbacks+0x424/0x7a0
>> [] ? account_system_time+0x81/0x110
>> [] ? account_process_tick+0x61/0x160
>> [] ? tick_sched_do_timer+0x30/0x30
>> [] update_process_times+0x39/0x60
>> [] tick_sched_handle.isra.15+0x36/0x50
>> [] tick_sched_timer+0x3d/0x70
>> [] __hrtimer_run_queues+0xf2/0x250
>> [] hrtimer_interrupt+0xa8/0x190
>> [] xen_timer_interrupt+0x2e/0x140
>> [] handle_irq_event_percpu+0x55/0x1e0
>> [] handle_percpu_irq+0x3a/0x50
>> [] generic_handle_irq+0x22/0x30
>> [] __evtchn_fifo_handle_events+0x15f/0x180
>> [] evtchn_fifo_handle_events+0x10/0x20
>> [] __xen_evtchn_do_upcall+0x43/0x80
>> [] xen_evtchn_do_upcall+0x30/0x50
>> [] xen_hvm_callback_vector+0x82/0x90
>>   [] ? queued_write_lock_slowpath+0x3d/0x80
>> [] _raw_write_lock+0x1e/0x30
> 
> This looks to me like ext4 failing to grab a lock. Everything above it
> (in Xen code) is regular tick interrupt handling which detects the stall.
> 
> Your config does not have CONFIG_PARAVIRT_SPINLOCKS so that eliminates
> any possible issues with pv locks.
> 
> Do you see anything "interesting" in dom0? (e.g. dmesg, xl dmesg,
> /var/log/xen/) Are you oversubscribing your guest (CPU-wise)?

There is nothing special being logged anywhere that I can see. dmesg /
xl dmesg on the Dom0 show nothing unusual.

I do share CPUs - but I don't give any DomU more than 2 vcpus. The
physical host has 4 cores - 1 pinned to the Dom0.

I log to a remote syslog on this system - and I've uploaded the entire
log to a pastebin (don't want to do a 45Kb attachment here):
http://paste.fedoraproject.org/345095/58914452

Not sure if it makes any difference at all, but my DomU config is:
# cat /etc/xen/backup.vm
name= "backup.vm"
memory  = 2048
vcpus   = 2
cpus= "1-3"
disk= [ 'phy:/dev/vg_raid1_new/backup.vm,xvda,w' ]
vif = [ "mac=00:11:36:35:35:09, bridge=br203,
vifname=vm.backup, script=vif-bridge" ]
bootloader  = 'pygrub'
pvh = 1

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash= 'restart'
cpu_weight  = 64

I never had this problem when running kernel 4.1.x - it only started
when I upgraded everything to 4.4 - not exactly a great help - but may
help narrow things down?

>> [] ext4_es_remove_extent+0x43/0xc0
>> [] ext4_clear_inode+0x39/0x80
>> [] ext4_evict_inode+0x8d/0x4e0
>> [] evict+0xb7/0x180
>> [] dispose_list+0x36/0x50
>> [] prune_icache_sb+0x4b/0x60
>> [] super_cache_scan+0x141/0x190
>> [] shrink_slab.part.37+0x1ee/0x390
>> [] shrink_zone+0x26c/0x280
>> [] do_try_to_free_pages+0x15c/0x410
>> [] try_to_free_pages+0xba/0x170
>> [] __alloc_pages_nodemask+0x525/0xa60
>> [] ? kmem_cache_free+0xcc/0x2c0
>> [] alloc_pages_current+0x8d/0x120
>> [] __page_cache_alloc+0x91/0xc0
>> [] pagecache_get_page+0x56/0x1e0
>> [] grab_cache_page_write_begin+0x26/0x40
>> [] ext4_da_write_begin+0xa1/0x300
>> [] ? ext4_da_write_end+0x124/0x2b0
>> [] generic_perform_write+0xc0/0x1a0
>> [] __generic_file_write_iter+0x188/0x1e0
>> [] ext4_file_write_iter+0xf0/0x340
>> [] __vfs_write+0xaa/0xe0
>> [] vfs_write+0xa2/0x1a0
>> [] SyS_write+0x46/0xa0
>> [] entry_SYSCALL_64_fastpath+0x12/0x71
>>
>> Some 11 hours later:
>> sshd[785]: segfault at 1f0 ip 7f03bb94ae5c sp 7ffe9eb54470 error
>> 4 in ld-2.17.so[7f03bb94+21000]
>> sh[787]: segfault at 1f0 ip 7f6b4a0dfe5c sp 7ffe3d4a71e0 error 4
>> in ld-2.17.so[7f6b4a0d5000+21000]
>> systemd-cgroups[788]: 

[Xen-devel] [PATCH v7 17/22] arm/gic: Add a new callback to deny Dom0 access to GIC regions

[Shannon Zhao]

Add a new member in gic_hw_operations which is used to deny Dom0 access
to GIC regions.

Signed-off-by: Shannon Zhao 
---
v7: move them out of CONFIG_ACPI
---
 xen/arch/arm/gic-v2.c | 27 +++
 xen/arch/arm/gic-v3.c | 41 +
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  3 +++
 4 files changed, 76 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 38e3216..450755f 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -684,6 +685,31 @@ static void __init gicv2_dt_init(void)
csize, vsize);
 }
 
+static int gicv2_iomem_deny_access(const struct domain *d)
+{
+int rc;
+unsigned long gfn, nr;
+
+gfn = dbase >> PAGE_SHIFT;
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+gfn = hbase >> PAGE_SHIFT;
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+gfn = cbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+
+gfn = vbase >> PAGE_SHIFT;
+return iomem_deny_access(d, gfn, gfn + nr);
+}
+
 #ifdef CONFIG_ACPI
 static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
 {
@@ -910,6 +936,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
+.iomem_deny_access   = gicv2_iomem_deny_access,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 52ee23c..a095064 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1235,6 +1236,45 @@ static void __init gicv3_dt_init(void)
   , );
 }
 
+static int gicv3_iomem_deny_access(const struct domain *d)
+{
+int rc, i;
+unsigned long gfn, nr;
+
+gfn = dbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(SZ_64K, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+
+for ( i = 0; i < gicv3.rdist_count; i++ )
+{
+gfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(gicv3.rdist_regions[i].size, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+}
+
+if ( cbase != INVALID_PADDR )
+{
+gfn = cbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+}
+
+if ( vbase != INVALID_PADDR )
+{
+gfn = vbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+return iomem_deny_access(d, gfn, gfn + nr);
+}
+
+return 0;
+}
+
 #ifdef CONFIG_ACPI
 static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
 {
@@ -1530,6 +1570,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
+.iomem_deny_access   = gicv3_iomem_deny_access,
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void 
*data)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b3c1eb3..2bfe4de 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -744,6 +744,11 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset)
 return gic_hw_ops->make_hwdom_madt(d, offset);
 }
 
+int gic_iomem_deny_access(const struct domain *d)
+{
+return gic_hw_ops->iomem_deny_access(d);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 8130136..cd97bb2 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -360,6 +360,8 @@ struct gic_hw_operations {
   const struct dt_device_node *gic, void *fdt);
 /* Create MADT table for the hardware domain */
 int (*make_hwdom_madt)(const struct domain *d, u32 offset);
+/* Deny access to GIC regions */
+int (*iomem_deny_access)(const struct domain *d);
 };
 
 void register_gic_ops(const struct gic_hw_operations *ops);
@@ -367,6 +369,7 @@ int gic_make_hwdom_dt_node(const struct domain *d,
const struct dt_device_node *gic,
void *fdt);
 int gic_make_hwdom_madt(const struct domain *d, u32 offset);
+int gic_iomem_deny_access(const struct domain *d);
 
 #endif /* __ASSEMBLY__ */
 #endif
-- 
2.1.4


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

[Xen-devel] xl: improve return codes for more xl comands

[Paulina Szubarczyk]

Hi,

This regards bite-size task for Outreachy program [0].

I followed the patches prepared by Harmandeep [1] where functions in
xl_cmdimpl.c have the pattern:

"*main_foo() is treated somewhat as a regular main(), it is changed to
return EXIT_SUCCESS or EXIT_FAILURE.

*Functions that are not main_foo(), are changed to do 'return 0' or
'return 1', and then 0/1 is taken care in the main_foo() functions
that calls them. "

The changes regard scheduling functions.

But in the preliminary patches [2] there is a notion to change not
main_foo()
to return EXIT_SUCCESS or EXIT_FAILURE, like in [3].

Should not-main functions related to
- mem-set
- cd-insert
- pci-*
return 0/1 or should EXIT_SUCCESS/EXIT_FAILURE be kept?

There is also a patch that change exit code from numeric values or ERROR_*
codes to be either EXIT_SUCCESS or EXIT_FAILURE for migrate related
functions [4].

Could that be applied to those functions too?

Paulina

[0] https://www.mail-archive.com/xen-devel@lists.xen.org/msg61650.html
[1]
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02990.html
[2]
http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02246.html
[3]
http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02243.html
[4]
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03354.html
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 21/22] xen/arm: Add a hypercall for device mmio mapping

[Shannon Zhao]

It needs to map platform or amba device mmio to Dom0 on ARM. But when
booting with ACPI, it can't get the mmio region in Xen due to lack of
AML interpreter to parse DSDT table. Therefore, let Dom0 call a
hypercall to map mmio region when it adds the devices.

Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
mmio region for Dom0.

Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/mm.c   |  3 +++
 xen/arch/arm/p2m.c  | 22 ++
 xen/common/memory.c | 16 
 xen/include/asm-arm/p2m.h   |  5 +
 xen/include/public/memory.h |  1 +
 5 files changed, 47 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 81f9e2e..0aae6c5 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1138,6 +1138,9 @@ int xenmem_add_to_physmap_one(
 rcu_unlock_domain(od);
 break;
 }
+case XENMAPSPACE_dev_mmio:
+rc = map_dev_mmio_region(d, gpfn, 1, idx);
+return rc;
 
 default:
 return -ENOSYS;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 7e5f5d1..0011708 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1270,6 +1271,27 @@ int unmap_mmio_regions(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_dev_mmio_region(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr,
+unsigned long mfn)
+{
+int res;
+
+if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
+return 0;
+
+res = map_mmio_regions(d, start_gfn, nr, mfn);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
+   start_gfn, start_gfn + nr - 1, d->domain_id);
+return res;
+}
+
+return 0;
+}
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gpfn,
 unsigned long mfn,
diff --git a/xen/common/memory.c b/xen/common/memory.c
index c7fca96..25ff86c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -980,6 +980,14 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
+/*
+ * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
+ * to map this kind of space to itself.
+ */
+if ( (xatp.space == XENMAPSPACE_dev_mmio) &&
+ ((d != current->domain) || !is_hardware_domain(d)) )
+return -EACCES;
+
 rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 if ( rc )
 {
@@ -1024,6 +1032,14 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
+/*
+ * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
+ * to map this kind of space to itself.
+ */
+if ( (xatpb.space == XENMAPSPACE_dev_mmio) &&
+ ((d != current->domain) || !is_hardware_domain(d)) )
+return -EACCES;
+
 rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 if ( rc )
 {
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 55626b4..d240d1e 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -154,6 +154,11 @@ int unmap_regions_rw_cache(struct domain *d,
unsigned long nr_mfns,
unsigned long mfn);
 
+int map_dev_mmio_region(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr,
+unsigned long mfn);
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gfn,
 unsigned long mfn,
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f69e92f..fe52ee1 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -220,6 +220,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. 
*/
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
 * XENMEM_add_to_physmap_batch only. */
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 /* ` } */
 
 /*
-- 
2.1.4


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

[Xen-devel] [PATCH v7 22/22] xen/arm64: Add ACPI support

[Shannon Zhao]

Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
Acked-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 
---
v7: Drop CONFIG_ACPI_BOOT
---
 xen/arch/arm/Kconfig |  9 +
 xen/common/efi/runtime.c | 12 +++-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cb99df5..6231cd5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -33,6 +33,15 @@ menu "Architecture Features"
 
 source "arch/Kconfig"
 
+config ACPI
+   bool
+   prompt "ACPI (Advanced Configuration and Power Interface) Support" if 
EXPERT = "y"
+   depends on ARM_64
+   ---help---
+
+ Advanced Configuration and Power Interface (ACPI) support for Xen is
+ an alternative to device tree on ARM64.
+
 # Select HAS_GICV3 if GICv3 is supported
 config HAS_GICV3
bool
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index ae87557..c256814 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -10,14 +10,16 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 
 #ifndef COMPAT
 
-#ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
-#else
+/*
+ * Currently runtime services are not implemented on ARM. To boot Xen with 
ACPI,
+ * set efi_enabled to 1, so that Xen can get the ACPI root pointer from EFI.
+ */
+const bool_t efi_enabled = 1;
+
+#ifndef CONFIG_ARM
 # include 
 # include 
 # include 
-
-const bool_t efi_enabled = 1;
 #endif
 
 unsigned int __read_mostly efi_num_ct;
-- 
2.1.4


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

[Xen-devel] [PATCH v7 15/22] arm/acpi: Permit access all Xen unused SPIs for Dom0

[Shannon Zhao]

Allow DOM0 to use all SPIs but the ones used by Xen. Then when Dom0
configures the interrupt, it could set the interrupt type and route it
to Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: add a TODO for SMMU used SPIs
---
 xen/arch/arm/domain_build.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 58a44ff..28b85e5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1359,6 +1359,37 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 #ifdef CONFIG_ACPI
 #define ACPI_DOM0_FDT_MIN_SIZE 4096
 
+static int acpi_permit_spi_access(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/*
+ * Here just permit Dom0 to access the SPIs which Xen doesn't use. Then 
when
+ * Dom0 configures the interrupt, set the interrupt type and route it to
+ * Dom0.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+/*
+* TODO: Exclude the SPIs SMMU uses which should not be routed to Dom0.
+*/
+desc = irq_to_desc(i);
+if ( desc->action != NULL)
+continue;
+
+res = irq_permit_access(d, i);
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%u access to IRQ %u\n",
+   d->domain_id, i);
+return res;
+}
+}
+
+return 0;
+}
+
 static int acpi_make_chosen_node(const struct kernel_info *kinfo)
 {
 int res;
@@ -1884,6 +1915,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_permit_spi_access(d);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 18/22] arm/acpi: Permit MMIO access of Xen unused devices for Dom0

[Shannon Zhao]

Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO
access of Xen used devices, such as UART, GIC, SMMU. Currently, it only
denies the MMIO access of UART and GIC regions. For other Xen used
devices it could be added later when they are supported.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 28b85e5..f004d92 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1359,6 +1359,38 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 #ifdef CONFIG_ACPI
 #define ACPI_DOM0_FDT_MIN_SIZE 4096
 
+static int acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long gfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+gfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
 static int acpi_permit_spi_access(struct domain *d)
 {
 int i, res;
@@ -1919,6 +1951,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_iomem_deny_access(d);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 16/22] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically

[Shannon Zhao]

Interrupt information is described in DSDT and is not available at the
time of booting. Check if the interrupt is permitted to access and set
the interrupt type, route it to guest dynamically only for SPI
and Dom0.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/vgic.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index ee35683..aa420bb 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -334,6 +336,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 }
 }
 
+#define VGIC_ICFG_MASK(intr) (1 << ((2 * ((intr) % 16)) + 1))
+
+static inline unsigned int get_the_irq_type(struct vcpu *v, int n, int index)
+{
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr = vr->icfg[index >> 4];
+
+if ( tr & VGIC_ICFG_MASK(index) )
+return IRQ_TYPE_EDGE_BOTH;
+else
+return IRQ_TYPE_LEVEL_MASK;
+}
+
 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 const unsigned long mask = r;
@@ -342,9 +357,26 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 unsigned long flags;
 int i = 0;
 struct vcpu *v_target;
+struct domain *d = v->domain;
+int ret;
 
 while ( (i = find_next_bit(, 32, i)) < 32 ) {
 irq = i + (32 * n);
+/* Set the irq type and route it to guest only for SPI and Dom0 */
+if( irq_access_permitted(d, irq) && is_hardware_domain(d) &&
+( irq >= 32 ) && ( !acpi_disabled ) )
+{
+ret = irq_set_spi_type(irq, get_the_irq_type(v, n, i));
+if ( ret )
+gprintk(XENLOG_WARNING, "The irq type is not correct\n");
+
+vgic_reserve_virq(d, irq);
+
+ret = route_irq_to_guest(d, irq, irq, NULL);
+if ( ret )
+gprintk(XENLOG_ERR, "Unable to route IRQ %u to domain %u\n",
+irq, d->domain_id);
+}
 v_target = __vgic_get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, >status);
-- 
2.1.4


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

[Xen-devel] [PATCH v7 13/22] arm/acpi: Map the new created EFI and ACPI tables to Dom0

[Shannon Zhao]

Map the UEFI and ACPI tables which we created to non-RAM space in Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: flush the cache
---
 xen/arch/arm/domain_build.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 954e0e3..70c8421 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1723,6 +1723,25 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 acpi_create_efi_system_table(d, tbl_add);
 acpi_create_efi_mmap_table(d, >mem, tbl_add);
 
+/* Map the EFI and ACPI tables to Dom0 */
+rc = map_regions_rw_cache(d,
+  paddr_to_pfn(d->arch.efi_acpi_gpa),
+  PFN_UP(d->arch.efi_acpi_len),
+  
paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table)));
+if ( rc != 0 )
+{
+printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   d->arch.efi_acpi_gpa & PAGE_MASK,
+   PAGE_ALIGN(d->arch.efi_acpi_gpa + d->arch.efi_acpi_len) - 1,
+   d->domain_id);
+return rc;
+}
+
+/* Flush cache of this region in case Dom0 gets wrong data. */
+clean_and_invalidate_dcache_va_range(d->arch.efi_acpi_table,
+ d->arch.efi_acpi_len);
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.

val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).

Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Signed-off-by: Shannon Zhao 
---
 xen/include/public/hvm/params.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index e69c72c..f7338a3 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -49,11 +49,24 @@
  * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
  */
 
+#if defined(__i386__) || defined(__x86_64__)
 #define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
 /*
  * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
  * if this delivery method is available.
  */
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI  2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ *  bit 8: the PPI is edge(1) or level(0) triggered
+ *  bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#endif
 
 /*
  * These are not used by Xen. They are here for convenience of HVM-guest
-- 
2.1.4


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

[Xen-devel] [PATCH v7 20/22] xen/acpi: Fix event-channel interrupt when booting with ACPI

[Shannon Zhao]

Store the event-channel interrupt number and flag in HVM parameter
HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall
HVMOP_get_param.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f004d92..d9bc3de 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2047,6 +2047,7 @@ static void initrd_load(struct kernel_info *kinfo)
 static void evtchn_fixup(struct domain *d, struct kernel_info *kinfo)
 {
 int res, node;
+u64 val;
 gic_interrupt_t intr;
 
 /*
@@ -2062,6 +2063,19 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
 printk("Allocating PPI %u for event channel interrupt\n",
d->arch.evtchn_irq);
 
+/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
+val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
+val |= (2 << 8); /* Active-low level-sensitive  */
+val |= d->arch.evtchn_irq & 0xff;
+d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
+
+/*
+ * When booting Dom0 using ACPI, Dom0 can only get the event channel
+ * interrupt via hypercall.
+ */
+if ( !acpi_disabled )
+return;
+
 /* Fix up "interrupts" in /hypervisor node */
 node = fdt_path_offset(kinfo->fdt, "/hypervisor");
 if ( node < 0 )
-- 
2.1.4


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

[Xen-devel] [PATCH v7 12/22] arm/acpi: Prepare EFI memory descriptor for Dom0

[Shannon Zhao]

Create EFI memory descriptors to tell Dom0 the RAM region information,
ACPI table regions and EFI tables reserved regions.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: check the size
---
 xen/arch/arm/domain_build.c |  1 +
 xen/arch/arm/efi/efi-dom0.c | 44 
 xen/include/asm-arm/setup.h |  4 
 3 files changed, 49 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f14bc5b..954e0e3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1721,6 +1721,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 
 acpi_map_other_tables(d);
 acpi_create_efi_system_table(d, tbl_add);
+acpi_create_efi_mmap_table(d, >mem, tbl_add);
 
 return 0;
 }
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index f4f84b6..cf71bf4 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -24,6 +24,7 @@
 #include "efi.h"
 #include "efi-dom0.h"
 #include 
+#include 
 #include 
 #include 
 #include "../../../common/decompress.h"
@@ -94,6 +95,49 @@ void __init acpi_create_efi_system_table(struct domain *d,
 tbl_add[TBL_EFIT].size = table_size;
 }
 
+void __init acpi_create_efi_mmap_table(struct domain *d,
+   const struct meminfo *mem,
+   struct membank tbl_add[])
+{
+EFI_MEMORY_DESCRIPTOR *memory_map;
+unsigned int i, offset;
+u8 *base_ptr;
+
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_MMAP);
+memory_map = (EFI_MEMORY_DESCRIPTOR *)base_ptr;
+
+offset = 0;
+for( i = 0; i < mem->nr_banks; i++, offset++ )
+{
+memory_map[offset].Type = EfiConventionalMemory;
+memory_map[offset].PhysicalStart = mem->bank[i].start;
+BUG_ON(mem->bank[i].size & EFI_PAGE_MASK);
+memory_map[offset].NumberOfPages = 
EFI_SIZE_TO_PAGES(mem->bank[i].size);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+}
+
+for( i = 0; i < acpi_mem.nr_banks; i++, offset++ )
+{
+memory_map[offset].Type = EfiACPIReclaimMemory;
+memory_map[offset].PhysicalStart = acpi_mem.bank[i].start;
+BUG_ON(acpi_mem.bank[i].size & EFI_PAGE_MASK);
+memory_map[offset].NumberOfPages = 
EFI_SIZE_TO_PAGES(acpi_mem.bank[i].size);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+}
+
+memory_map[offset].Type = EfiACPIReclaimMemory;
+memory_map[offset].PhysicalStart = d->arch.efi_acpi_gpa;
+BUG_ON(d->arch.efi_acpi_len & EFI_PAGE_MASK);
+memory_map[offset].NumberOfPages = EFI_SIZE_TO_PAGES(d->arch.efi_acpi_len);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+
+tbl_add[TBL_MMAP].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_MMAP);
+tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR)
+ * (mem->nr_banks + acpi_mem.nr_banks + 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index fc9fd7c..9a71e90 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -56,6 +56,10 @@ size_t estimate_efi_size(int mem_nr_banks);
 void acpi_create_efi_system_table(struct domain *d,
   struct membank tbl_add[]);
 
+void acpi_create_efi_mmap_table(struct domain *d,
+const struct meminfo *mem,
+struct membank tbl_add[]);
+
 int construct_dom0(struct domain *d);
 
 void discard_initial_modules(void);
-- 
2.1.4


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

[Xen-devel] [PATCH v7 04/22] arm/gic: Add a new callback for creating MADT table for Dom0

[Shannon Zhao]

Add a new member in gic_hw_operations which is used to create MADT table
for Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: make other fields of GICC zero
---
 xen/arch/arm/gic-v2.c | 42 +++
 xen/arch/arm/gic-v3.c | 56 +++
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  3 +++
 4 files changed, 106 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 0fcb894..38e3216 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -685,6 +685,43 @@ static void __init gicv2_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+u32 i, size, table_len = 0;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+{
+printk("Can't get GICC entry");
+return -EINVAL;
+}
+
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+size = sizeof(struct acpi_madt_generic_interrupt);
+/* Add Generic Interrupt */
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+gicc->parking_version = 0;
+gicc->performance_interrupt = 0;
+gicc->gicv_base_address = 0;
+gicc->gich_base_address = 0;
+gicc->vgic_interrupt = 0;
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -776,6 +813,10 @@ static void __init gicv2_acpi_init(void)
 }
 #else
 static void __init gicv2_acpi_init(void) { }
+static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+return 0;
+}
 #endif
 
 static int __init gicv2_init(void)
@@ -868,6 +909,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_vmcr_priority  = gicv2_read_vmcr_priority,
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
+.make_hwdom_madt = gicv2_make_hwdom_madt,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f83fd88..52ee23c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1236,6 +1236,57 @@ static void __init gicv3_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+struct acpi_madt_generic_redistributor *gicr;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+u32 i, table_len = 0, size;
+
+/* Add Generic Interrupt */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+{
+printk("Can't get GICC entry");
+return -EINVAL;
+}
+
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+size = sizeof(struct acpi_madt_generic_interrupt);
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+gicc->parking_version = 0;
+gicc->performance_interrupt = 0;
+gicc->gicv_base_address = 0;
+gicc->gich_base_address = 0;
+gicc->gicr_base_address = 0;
+gicc->vgic_interrupt = 0;
+table_len += size;
+}
+
+/* Add Generic Redistributor */
+size = sizeof(struct acpi_madt_generic_redistributor);
+for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+{
+gicr = (struct acpi_madt_generic_redistributor *)(base_ptr + 
table_len);
+gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+gicr->header.length = size;
+gicr->base_address = d->arch.vgic.rdist_regions[i].base;
+gicr->length = d->arch.vgic.rdist_regions[i].size;
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1380,6 +1431,10 @@ static void __init gicv3_acpi_init(void)
 }
 #else
 static void __init gicv3_acpi_init(void) { }
+static int 

[Xen-devel] [PATCH v7 09/22] arm/p2m: Add helper functions to map memory regions

[Shannon Zhao]

From: Parth Dixit 

Create a helper function for mapping with cached attributes and
read-write range.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: rename to map_regions_rw_cache
---
 xen/arch/arm/p2m.c| 26 ++
 xen/include/asm-arm/p2m.h | 10 ++
 2 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a2a9c4b..7e5f5d1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1218,6 +1218,32 @@ int p2m_populate_ram(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_regions_rw_cache(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_mmio_direct,
+ p2m_access_rw);
+}
+
+int unmap_regions_rw_cache(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr,
+   unsigned long mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_invalid,
+ p2m_access_rw);
+}
+
 int map_mmio_regions(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 433952a..55626b4 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, 
xen_pfn_t end_mfn);
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 
+int map_regions_rw_cache(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr_mfns,
+ unsigned long mfn);
+
+int unmap_regions_rw_cache(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr_mfns,
+   unsigned long mfn);
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gfn,
 unsigned long mfn,
-- 
2.1.4


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

[Xen-devel] [PATCH v7 02/22] arm/acpi: Add a helper function to get the acpi table offset

[Shannon Zhao]

These tables are aligned with 64bit.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: add commnets to explain what thsi function does
---
 xen/arch/arm/acpi/lib.c| 20 
 xen/include/asm-arm/acpi.h |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index db5c4d8..cee2454 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -60,3 +60,23 @@ bool_t __init acpi_psci_hvc_present(void)
 {
 return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
 }
+
+/*
+ * This function is used to get the offset of some new created ACPI or EFI 
table
+ * in the allocated memory region. Currently the tables should be created in 
the
+ * order of enum EFI_MEM_RES.
+ */
+paddr_t __init acpi_get_table_offset(struct membank tbl_add[],
+ EFI_MEM_RES index)
+{
+int i;
+paddr_t offset = 0;
+
+for ( i = 0; i < index; i++ )
+{
+/* Aligned with 64bit (8 bytes) */
+offset += ROUNDUP(tbl_add[i].size, 8);
+}
+
+return offset;
+}
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 7f59761..569fc31 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #define COMPILER_DEPENDENT_INT64   long long
 #define COMPILER_DEPENDENT_UINT64  unsigned long long
@@ -45,6 +46,7 @@ typedef enum {
 bool_t __init acpi_psci_present(void);
 bool_t __init acpi_psci_hvc_present(void);
 void __init acpi_smp_init_cpus(void);
+paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
 
 #ifdef CONFIG_ACPI
 extern bool_t acpi_disabled;
-- 
2.1.4


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

[Xen-devel] [PATCH v7 14/22] arm/acpi: Create min DT stub for Dom0

[Shannon Zhao]

Create a DT for Dom0 for ACPI-case only. DT contains minimal required
informations such as Dom0 bootargs, initrd, efi description table and
address of uefi memory table.

Also document this device tree bindings of "hypervisor" and
"hypervisor/uefi" node.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: change the function name and address comments
---
 docs/misc/arm/device-tree/guest.txt |  60 +++
 xen/arch/arm/domain_build.c | 142 
 xen/arch/arm/efi/efi-dom0.c |  39 ++
 xen/include/asm-arm/setup.h |   2 +
 4 files changed, 243 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/guest.txt

diff --git a/docs/misc/arm/device-tree/guest.txt 
b/docs/misc/arm/device-tree/guest.txt
new file mode 100644
index 000..418f1e9
--- /dev/null
+++ b/docs/misc/arm/device-tree/guest.txt
@@ -0,0 +1,60 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+the following properties:
+
+- compatible:
+   compatible = "xen,xen-", "xen,xen";
+  where  is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
+  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
+  This property is unnecessary when booting Dom0 using ACPI.
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+  A GIC node is also required.
+  This property is unnecessary when booting Dom0 using ACPI.
+
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+  || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+  || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
+
+Example (assuming #address-cells = <2> and #size-cells = <2>):
+
+hypervisor {
+   compatible = "xen,xen-4.3", "xen,xen";
+   reg = <0 0xb000 0 0x2>;
+   interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
+};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt in Linux, which are provided by the regular Linux
+UEFI stub. However they differ because they are provided by the Xen hypervisor,
+together with a set of UEFI runtime services implemented via hypercalls, see
+xen/include/public/platform.h.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 70c8421..58a44ff 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,144 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int acpi_make_chosen_node(const struct kernel_info *kinfo)
+{
+int res;
+const char *bootargs = NULL;
+const struct bootmodule *mod = kinfo->kernel_bootmodule;
+void *fdt = kinfo->fdt;
+
+DPRINT("Create chosen node\n");
+res = fdt_begin_node(fdt, "chosen");
+if ( res )
+return res;
+
+if ( mod && mod->cmdline[0] )
+{
+bootargs = >cmdline[0];
+res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
+if ( res )
+   return res;
+}
+
+/*
+ * If the bootloader provides an initrd, we must create a placeholder

[Xen-devel] [PATCH v7 11/22] arm/acpi: Prepare EFI system table for Dom0

[Shannon Zhao]

Prepare EFI system table for Dom0 to describe the information of UEFI.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: use domain as parameter
---
 xen/arch/arm/domain_build.c |  1 +
 xen/arch/arm/efi/efi-dom0.c | 45 +
 xen/include/asm-arm/setup.h |  3 +++
 3 files changed, 49 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1bfb2fc..f14bc5b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1720,6 +1720,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 return rc;
 
 acpi_map_other_tables(d);
+acpi_create_efi_system_table(d, tbl_add);
 
 return 0;
 }
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index 021aa02..f4f84b6 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -23,8 +23,12 @@
 
 #include "efi.h"
 #include "efi-dom0.h"
+#include 
 #include 
 #include 
+#include "../../../common/decompress.h"
+#define XZ_EXTERN STATIC
+#include "../../../common/xz/crc32.c"
 
 struct meminfo __initdata acpi_mem;
 /* Constant to indicate "Xen" in unicode u16 format */
@@ -49,6 +53,47 @@ size_t __init estimate_efi_size(int mem_nr_banks)
 return size;
 }
 
+void __init acpi_create_efi_system_table(struct domain *d,
+ struct membank tbl_add[])
+{
+u64 table_addr, table_size, offset = 0;
+u8 *base_ptr;
+EFI_CONFIGURATION_TABLE *efi_conf_tbl;
+EFI_SYSTEM_TABLE *efi_sys_tbl;
+
+table_addr = d->arch.efi_acpi_gpa
+ + acpi_get_table_offset(tbl_add, TBL_EFIT);
+table_size = sizeof(EFI_SYSTEM_TABLE) + sizeof(EFI_CONFIGURATION_TABLE)
+ + sizeof(xen_efi_fw_vendor);
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_EFIT);
+efi_sys_tbl = (EFI_SYSTEM_TABLE *)base_ptr;
+
+efi_sys_tbl->Hdr.Signature = EFI_SYSTEM_TABLE_SIGNATURE;
+/* Specify the revision as 2.5 */
+efi_sys_tbl->Hdr.Revision = (2 << 16 | 50);
+efi_sys_tbl->Hdr.HeaderSize = table_size;
+
+efi_sys_tbl->FirmwareRevision = 1;
+efi_sys_tbl->NumberOfTableEntries = 1;
+offset += sizeof(EFI_SYSTEM_TABLE);
+memcpy(base_ptr + offset, xen_efi_fw_vendor, sizeof(xen_efi_fw_vendor));
+efi_sys_tbl->FirmwareVendor = (CHAR16 *)(table_addr + offset);
+
+offset += sizeof(xen_efi_fw_vendor);
+efi_conf_tbl = (EFI_CONFIGURATION_TABLE *)(base_ptr + offset);
+efi_conf_tbl->VendorGuid = (EFI_GUID)ACPI_20_TABLE_GUID;
+efi_conf_tbl->VendorTable = (VOID *)tbl_add[TBL_RSDP].start;
+efi_sys_tbl->ConfigurationTable = (EFI_CONFIGURATION_TABLE *)(table_addr
+  + offset);
+xz_crc32_init();
+efi_sys_tbl->Hdr.CRC32 = xz_crc32((uint8_t *)efi_sys_tbl,
+  efi_sys_tbl->Hdr.HeaderSize, 0);
+
+tbl_add[TBL_EFIT].start = table_addr;
+tbl_add[TBL_EFIT].size = table_size;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7f233a1..fc9fd7c 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -53,6 +53,9 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len);
 
 size_t estimate_efi_size(int mem_nr_banks);
 
+void acpi_create_efi_system_table(struct domain *d,
+  struct membank tbl_add[]);
+
 int construct_dom0(struct domain *d);
 
 void discard_initial_modules(void);
-- 
2.1.4


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

[Xen-devel] [PATCH v7 07/22] arm/acpi: Prepare XSDT table for Dom0

[Shannon Zhao]

Copy and modify XSDT table before passing it to Dom0. Replace the entry
value of the copied table. Add a new entry for STAO table as well. And
keep entry value of other reused tables unchanged.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 72 +
 1 file changed, 72 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c09fb26..cd501ff 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,74 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static void acpi_xsdt_modify_entry(u64 entry[], unsigned long entry_count,
+   char *signature, u64 addr)
+{
+int i;
+struct acpi_table_header *table;
+u64 size = sizeof(struct acpi_table_header);
+
+for( i = 0; i < entry_count; i++ )
+{
+table = acpi_os_map_memory(entry[i], size);
+if ( ACPI_COMPARE_NAME(table->signature, signature) )
+{
+entry[i] = addr;
+acpi_os_unmap_memory(table, size);
+break;
+}
+acpi_os_unmap_memory(table, size);
+}
+}
+
+static int acpi_create_xsdt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_rsdp *rsdp_tbl;
+struct acpi_table_xsdt *xsdt = NULL;
+u64 table_size, addr;
+unsigned long entry_count;
+u8 *base_ptr;
+u8 checksum;
+
+addr = acpi_os_get_root_pointer();
+if ( !addr )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+
+/* Add place for STAO table in XSDT table */
+table_size = table->length + sizeof(u64);
+entry_count = (table->length - sizeof(struct acpi_table_header))
+  / sizeof(u64);
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_XSDT);
+ACPI_MEMCPY(base_ptr, table, table->length);
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+
+xsdt = (struct acpi_table_xsdt *)base_ptr;
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_FADT, tbl_add[TBL_FADT].start);
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_MADT, tbl_add[TBL_MADT].start);
+xsdt->table_offset_entry[entry_count] = tbl_add[TBL_STAO].start;
+
+xsdt->header.length = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xsdt), table_size);
+xsdt->header.checksum -= checksum;
+
+tbl_add[TBL_XSDT].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_XSDT);
+tbl_add[TBL_XSDT].size = table_size;
+
+return 0;
+}
+
 static int acpi_create_stao(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1585,6 +1653,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_xsdt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 00/22] Prepare UEFI and ACPI tables for Dom0 on ARM64

[Shannon Zhao]

These patches are Part 4 (and last part) of the previous patch set I
sent which adds ACPI support for arm64 on Xen[1]. Split them as an
individual set for convenient reviewing.

These patches create UEFI and ACPI tables which are mapped to Dom0's
space and add other preparations for Dom0 to use ACPI. Then at last
enable ACPI support on ARM64.

See individual patch for changes.

Thanks,
Shannon
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01831.html

Parth Dixit (1):
  arm/p2m: Add helper functions to map memory regions

Shannon Zhao (21):
  arm/acpi: Estimate memory required for acpi/efi tables
  arm/acpi: Add a helper function to get the acpi table offset
  arm/acpi: Prepare FADT table for Dom0
  arm/gic: Add a new callback for creating MADT table for Dom0
  arm/acpi: Prepare MADT table for Dom0
  arm/acpi: Prepare STAO table for Dom0
  arm/acpi: Prepare XSDT table for Dom0
  arm/acpi: Prepare RSDP table for Dom0
  arm/acpi: Map all other tables for Dom0
  arm/acpi: Prepare EFI system table for Dom0
  arm/acpi: Prepare EFI memory descriptor for Dom0
  arm/acpi: Map the new created EFI and ACPI tables to Dom0
  arm/acpi: Create min DT stub for Dom0
  arm/acpi: Permit access all Xen unused SPIs for Dom0
  arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically
  arm/gic: Add a new callback to deny Dom0 access to GIC regions
  arm/acpi: Permit MMIO access of Xen unused devices for Dom0
  hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  xen/acpi: Fix event-channel interrupt when booting with ACPI
  xen/arm: Add a hypercall for device mmio mapping
  xen/arm64: Add ACPI support

 docs/misc/arm/device-tree/guest.txt |  60 
 xen/arch/arm/Kconfig|   9 +
 xen/arch/arm/acpi/lib.c |  20 ++
 xen/arch/arm/domain.c   |   4 +
 xen/arch/arm/domain_build.c | 631 +++-
 xen/arch/arm/efi/Makefile   |   1 +
 xen/arch/arm/efi/efi-boot.h |   4 +-
 xen/arch/arm/efi/efi-dom0.c | 187 +++
 xen/arch/arm/efi/efi-dom0.h |   8 +
 xen/arch/arm/gic-v2.c   |  69 
 xen/arch/arm/gic-v3.c   |  97 ++
 xen/arch/arm/gic.c  |  10 +
 xen/arch/arm/mm.c   |   3 +
 xen/arch/arm/p2m.c  |  48 +++
 xen/arch/arm/vgic.c |  32 ++
 xen/common/efi/runtime.c|  12 +-
 xen/common/memory.c |  16 +
 xen/include/asm-arm/acpi.h  |   2 +
 xen/include/asm-arm/gic.h   |   6 +
 xen/include/asm-arm/p2m.h   |  15 +
 xen/include/asm-arm/setup.h |  11 +
 xen/include/public/hvm/params.h |  13 +
 xen/include/public/memory.h |   1 +
 23 files changed, 1250 insertions(+), 9 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/guest.txt
 create mode 100644 xen/arch/arm/efi/efi-dom0.c
 create mode 100644 xen/arch/arm/efi/efi-dom0.h

-- 
2.1.4


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

[Xen-devel] [PATCH v7 10/22] arm/acpi: Map all other tables for Dom0

[Shannon Zhao]

Map all other ACPI tables into Dom0 using 1:1 mappings.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: Fix comments and printk log
---
 xen/arch/arm/domain_build.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index eeb1359..1bfb2fc 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,30 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static void acpi_map_other_tables(struct domain *d)
+{
+int i;
+unsigned long res;
+u64 addr, size;
+
+/* Map all ACPI tables to Dom0 using 1:1 mappings. */
+for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+res = map_regions_rw_cache(d,
+   paddr_to_pfn(addr & PAGE_MASK),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
+   " - 0x%"PRIx64" in domain \n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+}
+}
+}
+
 static int acpi_create_rsdp(struct domain *d, struct membank tbl_add[])
 {
 
@@ -1695,6 +1719,8 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+acpi_map_other_tables(d);
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 08/22] arm/acpi: Prepare RSDP table for Dom0

[Shannon Zhao]

Copy RSDP table and replace rsdp->xsdt_physical_address with the address
of XSDT table, so it can point to the right XSDT table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cd501ff..eeb1359 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,40 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_rsdp(struct domain *d, struct membank tbl_add[])
+{
+
+struct acpi_table_rsdp *rsdp = NULL;
+u64 addr;
+u64 table_size = sizeof(struct acpi_table_rsdp);
+u8 *base_ptr;
+u8 checksum;
+
+addr = acpi_os_get_root_pointer();
+if ( !addr  )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+rsdp = acpi_os_map_memory(addr, table_size);
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_RSDP);
+ACPI_MEMCPY(base_ptr, rsdp, table_size);
+acpi_os_unmap_memory(rsdp, table_size);
+
+rsdp = (struct acpi_table_rsdp *)base_ptr;
+/* Replace xsdt_physical_address */
+rsdp->xsdt_physical_address = tbl_add[TBL_XSDT].start;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, rsdp), table_size);
+rsdp->checksum = rsdp->checksum - checksum;
+
+tbl_add[TBL_RSDP].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_RSDP);
+tbl_add[TBL_RSDP].size = table_size;
+
+return 0;
+}
+
 static void acpi_xsdt_modify_entry(u64 entry[], unsigned long entry_count,
char *signature, u64 addr)
 {
@@ -1657,6 +1691,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_rsdp(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 03/22] arm/acpi: Prepare FADT table for Dom0

[Shannon Zhao]

Copy and modify FADT table before passing it to Dom0. Set PSCI_COMPLIANT
and PSCI_USE_HVC.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 13027ea..0e44e10 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,44 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+
+static int acpi_create_fadt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_fadt *fadt = NULL;
+u64 table_size;
+acpi_status status;
+u8 *base_ptr;
+u8 checksum;
+
+status = acpi_get_table(ACPI_SIG_FADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get FADT table, %s\n", msg);
+return -EINVAL;
+}
+
+table_size = table->length;
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_FADT);
+ACPI_MEMCPY(base_ptr, table, table_size);
+fadt = (struct acpi_table_fadt *)base_ptr;
+
+/* Set PSCI_COMPLIANT and PSCI_USE_HVC */
+fadt->arm_boot_flags |= (ACPI_FADT_PSCI_COMPLIANT | 
ACPI_FADT_PSCI_USE_HVC);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), table_size);
+fadt->header.checksum -= checksum;
+
+tbl_add[TBL_FADT].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_FADT);
+tbl_add[TBL_FADT].size = table_size;
+
+return 0;
+}
+
 static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
 {
 size_t efi_size, acpi_size, madt_size;
@@ -1415,6 +1453,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 {
 int rc = 0;
 int order;
+struct membank tbl_add[TBL_MMAX] = {};
 
 rc = estimate_acpi_efi_size(d, kinfo);
 if ( rc != 0 )
@@ -1441,6 +1480,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 return -EINVAL;
 }
 
+rc = acpi_create_fadt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 05/22] arm/acpi: Prepare MADT table for Dom0

[Shannon Zhao]

Copy main MADT table contents and distributor subtable from physical
ACPI MADT table. Make other subtables through the callback of
gic_hw_ops.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 60 +
 1 file changed, 60 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0e44e10..86fc3e0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,62 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_madt *madt = NULL;
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_distributor *gicd;
+u32 table_size = sizeof(struct acpi_table_madt);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_MADT);
+int ret;
+acpi_status status;
+u8 *base_ptr, checksum;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get MADT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, table_size);
+
+/* Add Generic Distributor. */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+if ( !header )
+{
+printk("Can't get GICD entry\n");
+return -EINVAL;
+}
+gicd = container_of(header, struct acpi_madt_generic_distributor, header);
+ACPI_MEMCPY(base_ptr + table_size, gicd,
+sizeof(struct acpi_madt_generic_distributor));
+table_size += sizeof(struct acpi_madt_generic_distributor);
+
+/* Add other subtables. */
+ret = gic_make_hwdom_madt(d, offset + table_size);
+if ( ret < 0 )
+{
+printk("Failed to get other subtables\n");
+return -EINVAL;
+}
+table_size += ret;
+
+madt = (struct acpi_table_madt *)base_ptr;
+madt->header.length = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, madt), table_size);
+madt->header.checksum -= checksum;
+
+tbl_add[TBL_MADT].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_MADT].size = table_size;
+
+return 0;
+}
 
 static int acpi_create_fadt(struct domain *d, struct membank tbl_add[])
 {
@@ -1484,6 +1540,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_madt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 06/22] arm/acpi: Prepare STAO table for Dom0

[Shannon Zhao]

Create STAO table for Dom0. This table is used to tell Dom0 whether it
should ignore UART defined in SPCR table or the ACPI namespace names.

Look at below url for details:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 86fc3e0..c09fb26 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,43 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_stao(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_stao *stao = NULL;
+u32 table_size = sizeof(struct acpi_table_stao);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_STAO);
+acpi_status status;
+u8 *base_ptr, checksum;
+
+/* Copy OEM and ASL compiler fields from another table, use MADT */
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("STAO: Failed to get MADT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, sizeof(struct acpi_table_header));
+
+stao = (struct acpi_table_stao *)base_ptr;
+ACPI_MEMCPY(stao->header.signature, ACPI_SIG_STAO, 4);
+stao->header.revision = 1;
+stao->header.length = table_size;
+stao->ignore_uart = 1;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), table_size);
+stao->header.checksum -= checksum;
+
+tbl_add[TBL_STAO].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_STAO].size = table_size;
+
+return 0;
+}
+
 static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1544,6 +1581,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_stao(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.1.4


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

[Xen-devel] [PATCH v7 01/22] arm/acpi: Estimate memory required for acpi/efi tables

[Shannon Zhao]

Estimate the memory required for loading acpi/efi tables in Dom0. Make
the length of each table aligned with 64bit. Alloc the pages to store
the new created EFI and ACPI tables and free these pages when
destroying domain.

Signed-off-by: Shannon Zhao 
---
v7: address several comments from Julien
---
 xen/arch/arm/domain.c   |   4 ++
 xen/arch/arm/domain_build.c | 103 +++-
 xen/arch/arm/efi/Makefile   |   1 +
 xen/arch/arm/efi/efi-boot.h |   4 +-
 xen/arch/arm/efi/efi-dom0.c |  59 +
 xen/arch/arm/efi/efi-dom0.h |   8 
 xen/include/asm-arm/setup.h |   2 +
 7 files changed, 177 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/efi/efi-dom0.c
 create mode 100644 xen/arch/arm/efi/efi-dom0.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3d274ae..1365b4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -640,6 +640,10 @@ void arch_domain_destroy(struct domain *d)
 domain_vgic_free(d);
 domain_vuart_free(d);
 free_xenheap_page(d->shared_info);
+#ifdef CONFIG_ACPI
+free_xenheap_pages(d->arch.efi_acpi_table,
+   get_order_from_bytes(d->arch.efi_acpi_len));
+#endif
 }
 
 void arch_domain_shutdown(struct domain *d)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 83676e4..13027ea 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1354,6 +1356,101 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 return -EINVAL;
 }
 
+#ifdef CONFIG_ACPI
+static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
+{
+size_t efi_size, acpi_size, madt_size;
+u64 addr;
+struct acpi_table_rsdp *rsdp_tbl;
+struct acpi_table_header *table;
+
+efi_size = estimate_efi_size(kinfo->mem.nr_banks);
+
+acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
+acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
+
+madt_size = sizeof(struct acpi_table_madt)
++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
++ sizeof(struct acpi_madt_generic_distributor);
+if ( d->arch.vgic.version == GIC_V3 )
+madt_size += sizeof(struct acpi_madt_generic_redistributor)
+ * d->arch.vgic.nr_regions;
+acpi_size += ROUNDUP(madt_size, 8);
+
+addr = acpi_os_get_root_pointer();
+if ( !addr )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+if ( !rsdp_tbl )
+{
+printk("Unable to map RSDP table\n");
+return -EINVAL;
+}
+
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+if ( !table )
+{
+printk("Unable to map XSDT table\n");
+return -EINVAL;
+}
+
+/* Add place for STAO table in XSDT table */
+acpi_size += ROUNDUP(table->length + sizeof(u64), 8);
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+
+acpi_size += ROUNDUP(sizeof(struct acpi_table_rsdp), 8);
+d->arch.efi_acpi_len = PAGE_ALIGN(ROUNDUP(efi_size, 8)
+  + ROUNDUP(acpi_size, 8));
+
+return 0;
+}
+
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+int rc = 0;
+int order;
+
+rc = estimate_acpi_efi_size(d, kinfo);
+if ( rc != 0 )
+return rc;
+
+order = get_order_from_bytes(d->arch.efi_acpi_len);
+d->arch.efi_acpi_table = alloc_xenheap_pages(order, 0);
+if ( d->arch.efi_acpi_table == NULL )
+{
+printk("unable to allocate memory!\n");
+return -ENOMEM;
+}
+memset(d->arch.efi_acpi_table, 0, d->arch.efi_acpi_len);
+
+/*
+ * For ACPI, Dom0 doesn't use kinfo->gnttab_start to get the grant table
+ * region. So we use it as the ACPI table mapped address. Also it needs to
+ * check if the size of grant table region is enough for those ACPI tables.
+ */
+d->arch.efi_acpi_gpa = kinfo->gnttab_start;
+if ( kinfo->gnttab_size < d->arch.efi_acpi_len )
+{
+printk("The grant table region is not enough to fit the ACPI 
tables!\n");
+return -EINVAL;
+}
+
+return 0;
+}
+#else
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+/* Only booting with ACPI will hit here */
+BUG();
+return -EINVAL;
+}
+#endif
 static void dtb_load(struct kernel_info *kinfo)
 {
 void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
@@ -1540,7 +1637,11 @@ int construct_dom0(struct domain *d)
 allocate_memory(d, );
 find_gnttab_region(d, );
 
-rc = 

Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events

[Konrad Rzeszutek Wilk]

On Wed, Mar 23, 2016 at 12:35:36PM +, George Dunlap wrote:
> On 12/03/16 11:33, Dario Faggioli wrote:
> > (i.e., domain creation and destruction) so the
> > trace will show properly decoded info, rather
> > than just a bunch of hex codes.
> > ---
> 
> For some reason git won't apply your 'v2', complaining: 'corrupt patch
> at line 14'.

/me nods. Same here. I tried to check it in but couldn't.

Dariof could you make a git branch to pull in the Acked patches please?

> 
> But re the content (i.e., this patch with the SoB and the title fixed)
> 
> Acked-by: George Dunlap 
> 
> Sorry it took so long to get to this.
> 
> 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > Cc: Konrad Rzeszutek Wilk 
> > ---
> > Changes from v1:
> >  * new patch in the series.
> > ---
> >  tools/xentrace/xenalyze.c |   26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> > index d4a5b0c..353bed7 100644
> > --- a/tools/xentrace/xenalyze.c
> > +++ b/tools/xentrace/xenalyze.c
> > @@ -8388,6 +8388,30 @@ void hw_process(struct pcpu_info *p)
> >  }
> >  
> >  }
> > +
> > +#define TRC_DOM0_SUB_DOMOPS 1
> > +void dom0_process(struct pcpu_info *p)
> > +{
> > +struct record_info *ri = >ri;
> > +
> > +switch(ri->evt.sub)
> > +{
> > +case TRC_DOM0_SUB_DOMOPS:
> > +if(opt.dump_all) {
> > +struct {
> > +unsigned int domid;
> > +} *r = (typeof(r))ri->d;
> > +
> > +printf(" %s %s domain d%u\n", ri->dump_header,
> > +   ri->event == TRC_DOM0_DOM_ADD ? "creating" : "destroying",
> > +   r->domid);
> > +}
> > +break;
> > +default:
> > +process_generic(>ri);
> > +}
> > +}
> > +
> >  /*  Base - */
> >  void dump_generic(FILE * f, struct record_info *ri)
> >  {
> > @@ -9224,6 +9248,8 @@ void process_record(struct pcpu_info *p) {
> >  hw_process(p);
> >  break;
> >  case TRC_DOM0OP_MAIN:
> > +dom0_process(p);
> > +break;
> >  default:
> >  process_generic(ri);
> >  }
> > 
> 

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

Re: [Xen-devel] [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 04:00:33PM -0400, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Acked-by: Wei Liu 

Hey Wei,

It has you Ack, but I think when I carried over the change (it used
to be its own function with switch) I messed up the Style:

> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 6c3ec40..310a7f3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5277,8 +5278,24 @@ const libxl_version_info* 
> libxl_get_version_info(libxl_ctx *ctx)
>  
>  info->virt_start = val;
>  
> -(void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> -info->pagesize, >commandline);
> +if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> +  info->pagesize, >commandline) < 0)
> +goto out;
> +
> +r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> +if (r < 0)
> +{
> +info->build_id = libxl__strdup(NOGC, "");
> +}
> +else if (r > 0)
> +{
> +unsigned int i;
> +
> +info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> +
> +for (i = 0; i < r; i++)
> +snprintf(>build_id[i * 2], 3, "%02hhx", buf[i]);
> +}
>   out:
>  GC_FREE;
>  return info;

So I fixed it up to be:

From bc4ed9d93162325342a37122fcab7223fcd61430 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 18 Mar 2016 14:56:13 -0400
Subject: [PATCH] libxl: info: Display build_id of the hypervisor using
 XEN_VERSION_build_id

If the hypervisor is built with we will display it.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
v3: Retry with different size if 1020 is not enough.
v4: Use VERSION_OP subops instead of the XENVER_ subops
v5: Change it per Wei's review. s/VERSION_OP/VERSION/
And actually use the proper Style!
---
 tools/libxl/libxl.c | 18 --
 tools/libxl/libxl.h |  6 ++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c|  1 +
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 704e7b4..dea5d25 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5233,6 +5233,7 @@ const libxl_version_info* 
libxl_get_version_info(libxl_ctx *ctx)
 GC_INIT(ctx);
 char *buf;
 xen_version_op_val_t val = 0;
+int r;
 libxl_version_info *info = >version_info;
 
 if (info->xen_version_extra != NULL)
@@ -5275,8 +5276,21 @@ const libxl_version_info* 
libxl_get_version_info(libxl_ctx *ctx)
 
 info->virt_start = val;
 
-(void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
-info->pagesize, >commandline);
+if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
+  info->pagesize, >commandline) < 0)
+goto out;
+
+r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
+if (r < 0) {
+info->build_id = libxl__strdup(NOGC, "");
+} else if (r > 0) {
+unsigned int i;
+
+info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
+
+for (i = 0; i < r; i++)
+snprintf(>build_id[i * 2], 3, "%02hhx", buf[i]);
+}
  out:
 GC_FREE;
 return info;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f61bc4b..5baffdf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -230,6 +230,12 @@
 #define LIBXL_HAVE_APIC_ASSIST 1
 
 /*
+ * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
+ * field for the hypervisor build_id.
+ */
+#define LIBXL_HAVE_BUILD_ID 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 59b183c..e3a5707 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -363,6 +363,7 @@ libxl_version_info = Struct("version_info", [
 ("virt_start",uint64),
 ("pagesize",  integer),
 ("commandline",   string),
+("build_id",  string),
 ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a3610fc..23da95e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5861,6 +5861,7 @@ static void output_xeninfo(void)
 printf("cc_compile_by  : %s\n", info->compile_by);
 printf("cc_compile_domain  : %s\n", info->compile_domain);
 printf("cc_compile_date: %s\n", info->compile_date);
+printf("build_id   : 

Re: [Xen-devel] [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall

[Konrad Rzeszutek Wilk]

On Thu, Mar 24, 2016 at 09:24:01PM +, Wei Liu wrote:
> On Thu, Mar 24, 2016 at 04:00:14PM -0400, Konrad Rzeszutek Wilk wrote:
> [...]
> > +
> > +static int libxl__xc_version_wrapper(libxl__gc *gc, unsigned int cmd, char 
> > *buf, ssize_t len, char **dst)
> 
> Please wrap this long line.
> 
> > +{
> > +int r;
> > +
> > +r = xc_version(CTX->xch, cmd, buf, len);
> > +if ( r == -EPERM )
> > +{
> > +buf[0] = '\0';
> > +}
> > +else if ( r < 0 )
> > +{
> > +return r;
> > +}
> 
>   if (r == -EPERM) {
>   buf[0] = '\0';
>   } else if (r < 0) {
>   return r;
>   }
> 
> 
> You seem to have mixed different coding styles ...

Duh! Yes!
> 
> With those nits fixed:
> 
> Acked-by: Wei Liu 

Thank you!

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

[Xen-devel] [linux-linus test] 87236: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-amd64-pair23 guest-stop/src_host   fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail 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

version targeted for testing:
 linuxe46b4e2b46e173889b1b8bd033d5e8b3acf0
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  260 days
Failing since 59348  2015-07-10 04:24:05 Z  259 days  187 attempts
Testing same since87236  2016-03-24 21:11:45 Z0 days1 attempts


4811 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

[Wei Liu]

CC Samuel

On Wed, Mar 23, 2016 at 02:26:51PM -0700, Sarah Newman wrote:
> 7c8f3483 introduced a break within a loop in netfront.c such that
> cons and nr_consumed were no longer always being incremented. The
> offset at cons will be processed multiple times with the break in
> place.
> 
> Remove the break and re-add "some !=0" in the loop for HAVE_LIBC.
> 
> Signed-off-by: Sarah Newman 
> ---
>  netfront.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/netfront.c b/netfront.c
> index 0eca5b5..557e8c4 100644
> --- a/netfront.c
> +++ b/netfront.c
> @@ -108,8 +108,10 @@ moretodo:
>  
>  #ifdef HAVE_LIBC
>  some = 0;
> -#endif
> +for (cons = dev->rx.rsp_cons; (cons != rp) && !some; nr_consumed++, 
> cons++)
> +#else
>  for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
> +#endif
>  {
>  struct net_buffer* buf;
>  unsigned char* page;
> @@ -135,7 +137,6 @@ moretodo:
>   memcpy(dev->data, page+rx->offset, len);
>   dev->rlen = len;
>   some = 1;
> -break;
>   } else
>  #endif
>   dev->netif_rx(page+rx->offset,rx->status);
> -- 
> 1.9.1
> 
> 
> ___
> 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 v13 23/26] COLO nic: implement COLO nic subkind

[Wei Liu]

On Fri, Mar 25, 2016 at 02:44:30PM +0800, Changlong Xie wrote:
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 0470423..6893732 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -600,6 +600,7 @@ libxl_device_nic = Struct("device_nic", [
>  ("rate_bytes_per_interval", uint64),
>  ("rate_interval_usecs", uint32),
>  ("gatewaydev", string),
> +("coloft_forwarddev", string)

This lacks the stability warning text. See my reply to your earlier
inquiry.

Note that the COLO configuration settings should be considered
unstable.  They may change incompatibly in future versions of
Xen.

You can submit a new patch with the required change in a reply to this
one, and title it

 [PATCH v13.1 23/26] COLO nic: implement COLO nic subkind

I checked, this hunk seems to be the only place that needs adding that
snippet -- there is no modification to xl manpage and libxl.h in this
patch.

Wei.

>  ])
>  
>  libxl_device_pci = Struct("device_pci", [
> -- 
> 1.9.3
> 
> 
> 

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

Re: [Xen-devel] [PATCH v12 26/26] cmdline switches and config vars to control colo-proxy

[Wei Liu]

On Fri, Mar 25, 2016 at 02:10:23PM +0800, Changlong Xie wrote:
> On 03/25/2016 12:12 AM, Ian Jackson wrote:
> >Changlong Xie writes ("[PATCH v12 26/26] cmdline switches and config vars to 
> >control colo-proxy"):
> >>From: Wen Congyang 
> >>
> >>Add cmdline switches to 'xl migrate-receive' command to specify
> >>a domain-specific hotplug script to setup COLO proxy.
> >
> >>+if (nic->forwarddev) {
> >>+flexarray_append(back, "forwarddev");
> >>+flexarray_append(back, nic->forwarddev);
> >>+}
> >
> >I'd prefer a name with `coloft' in it, throughout, even for the
> >xenstore node.  But again this is not critical if we are not trying to
> >make a stable API.
> >
> >>+static struct option opts[] = {
> >>+{"script", 1, 0, 0x100},
> >
> >This should surely be --coloft-script, or --colo-script, something.
> >
> >I think this script is (actually, in your setup) created by your
> >management software, and contains some actual functionality.  Am I
> >right ?  In which case my comments about including that functionality
> >in xen.git apply here too.  But again this is not a blocker for 4.7.
> 
> Also, I can't find your "comments about xxx".
> 

Ian's comment on 20/26:

It is a shame that this management code is not also here.

We would like to have enough management code in xen.git that we can
introduce a COLO test in osstest.  That will ensure that your feature
does not regress.

The above comment applies to the script in this patch, too. Ian is
asking you to upstream all relevant management code so that there is a
chance upstream tests COLO -- but that's not a blocker for 4.7.

As a side note, we should devise a plan to test COLO -- either do it in
OSStest or rely on third party testing. But that's a topic for another
day.

Wei.

> Thanks
>   -Xie
> >
> >>-xasprintf(, "exec %s %s xl migrate-receive %s %s",
> >>-  ssh_command, host,
> >>-  libxl_defbool_val(r_info.colo) ? "-c" : "-r",
> >>-  daemonize ? "" : " -e");
> >>+if (!libxl_defbool_val(r_info.colo)) {
> >>+xasprintf(, "exec %s %s xl migrate-receive %s %s",
> >>+  ssh_command, host,
> >>+  "-r",
> >>+  daemonize ? "" : " -e");
> >>+} else {
> >>+xasprintf(, "exec %s %s xl migrate-receive %s %s %s 
> >>%s",
> >>+  ssh_command, host,
> >>+  "-c",
> >>+  r_info.netbufscript ? "--script" : "",
> >>+  r_info.netbufscript ? r_info.netbufscript : "",
> >>+  daemonize ? "" : " -e");
> >
> >I have just noticed here that you have introduced `-c' (in an earlier
> >patch) to mean to receive a COLO checkpointed stream.
> >
> >Can you please change this to `--colo' ?
> >
> >Sorry,
> >Ian.
> >
> >
> >.
> >
> 
> 

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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[Boris Ostrovsky]

On 03/24/2016 10:53 PM, Steven Haigh wrote:

Hi all,

Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I have also CC'ed Greg KH for his awesome insight as maintainer.

Please CC myself into replies - as I'm not a member of the kernel
mailing list - I may miss replies from monitoring the archives.

I've noticed recently that heavy disk IO is causing rcu_sched to detect
stalls. The process mentioned usually goes to 100% CPU usage, and
eventually processes start segfaulting and dying. The only fix to
recover the system is to use 'xl destroy' to force-kill the VM and to
start it again.

The majority of these issues seem to mention ext4 in the trace. This may
indicate an issue there - or may be a red herring.

The gritty details:
INFO: rcu_sched self-detected stall on CPU
#0110-...: (20999 ticks this GP) idle=327/141/0
softirq=1101493/1101493 fqs=6973
#011 (t=21000 jiffies g=827095 c=827094 q=524)
Task dump for CPU 0:
rsync   R  running task0  2446   2444 0x0088
818d0c00 88007fc03c58 810a625f 
818d0c00 88007fc03c70 810a8699 0001
88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
Call Trace:
  [] sched_show_task+0xaf/0x110
[] dump_cpu_task+0x39/0x40
[] rcu_dump_cpu_stacks+0x8a/0xc0
[] rcu_check_callbacks+0x424/0x7a0
[] ? account_system_time+0x81/0x110
[] ? account_process_tick+0x61/0x160
[] ? tick_sched_do_timer+0x30/0x30
[] update_process_times+0x39/0x60
[] tick_sched_handle.isra.15+0x36/0x50
[] tick_sched_timer+0x3d/0x70
[] __hrtimer_run_queues+0xf2/0x250
[] hrtimer_interrupt+0xa8/0x190
[] xen_timer_interrupt+0x2e/0x140
[] handle_irq_event_percpu+0x55/0x1e0
[] handle_percpu_irq+0x3a/0x50
[] generic_handle_irq+0x22/0x30
[] __evtchn_fifo_handle_events+0x15f/0x180
[] evtchn_fifo_handle_events+0x10/0x20
[] __xen_evtchn_do_upcall+0x43/0x80
[] xen_evtchn_do_upcall+0x30/0x50
[] xen_hvm_callback_vector+0x82/0x90
  [] ? queued_write_lock_slowpath+0x3d/0x80
[] _raw_write_lock+0x1e/0x30


This looks to me like ext4 failing to grab a lock. Everything above it 
(in Xen code) is regular tick interrupt handling which detects the stall.


Your config does not have CONFIG_PARAVIRT_SPINLOCKS so that eliminates 
any possible issues with pv locks.


Do you see anything "interesting" in dom0? (e.g. dmesg, xl dmesg, 
/var/log/xen/) Are you oversubscribing your guest (CPU-wise)?


-boris


[] ext4_es_remove_extent+0x43/0xc0
[] ext4_clear_inode+0x39/0x80
[] ext4_evict_inode+0x8d/0x4e0
[] evict+0xb7/0x180
[] dispose_list+0x36/0x50
[] prune_icache_sb+0x4b/0x60
[] super_cache_scan+0x141/0x190
[] shrink_slab.part.37+0x1ee/0x390
[] shrink_zone+0x26c/0x280
[] do_try_to_free_pages+0x15c/0x410
[] try_to_free_pages+0xba/0x170
[] __alloc_pages_nodemask+0x525/0xa60
[] ? kmem_cache_free+0xcc/0x2c0
[] alloc_pages_current+0x8d/0x120
[] __page_cache_alloc+0x91/0xc0
[] pagecache_get_page+0x56/0x1e0
[] grab_cache_page_write_begin+0x26/0x40
[] ext4_da_write_begin+0xa1/0x300
[] ? ext4_da_write_end+0x124/0x2b0
[] generic_perform_write+0xc0/0x1a0
[] __generic_file_write_iter+0x188/0x1e0
[] ext4_file_write_iter+0xf0/0x340
[] __vfs_write+0xaa/0xe0
[] vfs_write+0xa2/0x1a0
[] SyS_write+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x71

Some 11 hours later:
sshd[785]: segfault at 1f0 ip 7f03bb94ae5c sp 7ffe9eb54470 error
4 in ld-2.17.so[7f03bb94+21000]
sh[787]: segfault at 1f0 ip 7f6b4a0dfe5c sp 7ffe3d4a71e0 error 4
in ld-2.17.so[7f6b4a0d5000+21000]
systemd-cgroups[788]: segfault at 1f0 ip 7f4baa82ce5c sp
7ffd28e4c4b0 error 4 in ld-2.17.so[7f4baa822000+21000]
sshd[791]: segfault at 1f0 ip 7ff8c8a8ce5c sp 7ffede9e1c20 error
4 in ld-2.17.so[7ff8c8a82000+21000]
sshd[792]: segfault at 1f0 ip 7f183cf75e5c sp 7ffc81ab7160 error
4 in ld-2.17.so[7f183cf6b000+21000]
sshd[793]: segfault at 1f0 ip 7f3c665ece5c sp 7ffd9a13c850 error
4 in ld-2.17.so[7f3c665e2000+21000]

 From isolated testing, this does not occur on kernel 4.5.x - however I
have not verified this myself.

The kernel config used can be found in the kernel-xen git repo if it
assists in debugging:
http://xen.crc.id.au/git/?p=kernel-xen;a=summary



___
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 v12 23/26] COLO nic: implement COLO nic subkind

[Wei Liu]

On Fri, Mar 25, 2016 at 02:09:04PM +0800, Changlong Xie wrote:
> On 03/25/2016 12:05 AM, Ian Jackson wrote:
> >Changlong Xie writes ("[PATCH v12 23/26] COLO nic: implement COLO nic 
> >subkind"):
> >>From: Wen Congyang 
> >>
> >>implement COLO nic subkind.
> >...
> >>diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >>index a206d68..a8be078 100644
> >>--- a/tools/libxl/libxl_types.idl
> >>+++ b/tools/libxl/libxl_types.idl
> >>@@ -599,6 +599,9 @@ libxl_device_nic = Struct("device_nic", [
> >>  ("rate_bytes_per_interval", uint64),
> >>  ("rate_interval_usecs", uint32),
> >>  ("gatewaydev", string),
> >>+# forward device that only used in COLO, it forwards
> >>+# the network requests from client to secondary vm
> >>+("forwarddev", string)
> >
> >Sorry I didn't ask for this last time, but I think this parameter
> >ought to have `colo' or `coloft' in its name somewhere.
> >
> >How about `coloft_forwarddev' ?
> >
> >This is not critical for 4.7 if we aren't trying to provide a stable
> >API.  Please make sure a copy of the API stability warning text I
> 
> Could you point where is the "API stability warning text", i've went through
> v11/v12 and don't have any clue.
> 

See Ian's comment on 20/26 -- I will copy the most relevant snippet
here:

  So can you please add comments to this patch saying
  
Note that the COLO configuration settings should be considered
unstable.  They may change incompatibly in future versions of
Xen.
  
  This should appear (at least) three times: in xl.pod.1,
  xl-disk-configuration.txt and libxl_types.idl.  With such a change, I
  will ack this patch.

Wei.

> Thanks
>   -Xie
> >mentioned earlier (either because the previous patch put it here, or
> >adding it to this patch).
> >
> >Thanks,
> >Ian.
> >
> >
> >.
> >
> 
> 

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

Re: [Xen-devel] [PATCH] spinlock: improve spin_is_locked() for recursive locks

[Xu, Quan]

On March 24, 2016 7:31pm,  wrote:
> Recursive locks know their current owner, and since we use the function solely
> to determine whether a particular lock is being held by the current CPU (which
> so far has been an imprecise check), make actually check the owner for
> recusrively acquired locks.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -188,7 +188,9 @@ void _spin_unlock_irqrestore(spinlock_t
>  int _spin_is_locked(spinlock_t *lock)
>  {
>  check_lock(>debug);
> -return lock->tickets.head != lock->tickets.tail;
> +return lock->recurse_cpu == SPINLOCK_NO_CPU
> +   ? lock->tickets.head != lock->tickets.tail
> +   : lock->recurse_cpu == smp_processor_id();
>  }
> 
>  int _spin_trylock(spinlock_t *lock)
> 
> 

Reviewed-by: Quan Xu 

Thanks for your enhancement. I am not aware of this case in my previous patch 
set.
Quan



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf a7b15909e8a6dd221944d87f51b689e633308199
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  108 days
Failing since 65593  2015-12-08 23:44:51 Z  107 days  120 attempts
Testing same since87216  2016-03-24 17:43:50 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Juliano Ciocari 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Marvin Häuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

Logs, config files, etc. are available at

[Xen-devel] [linux-4.1 test] 87204: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 87117 
REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 86830 pass in 
87204
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 86830 pass 
in 87204
 test-armhf-armhf-xl-xsm  16 guest-start.2  fail in 87117 pass in 86830
 test-armhf-armhf-xl  11 guest-startfail in 87117 pass in 87204
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 87031
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail pass in 87117
 test-armhf-armhf-xl-cubietruck 11 guest-start   fail pass in 87117
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 87117
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 87117

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 87117 like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399

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-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 87117 never 
pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore   fail in 87117 never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 87117 never 
pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 87117 
never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 87117 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 87117 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 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
 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-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux7f30737678023b5becaf0e2e012665f71b886a7d
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z  100 days
Failing since 78925  2016-01-24 13:50:39 Z   60 days   66 attempts
Testing same since86587  2016-03-18 16:11:01 Z6 days8 attempts


494 people touched revisions under 

Re: [Xen-devel] [PATCH 2/2] IOMMU/MMU: Adjust low level functions for VT-d Device-TLB flush error.

[Xu, Quan]

On March 18, 2016 6:20pm,  wrote:
> >>> On 17.03.16 at 07:54,  wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_init.c
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c
> > @@ -1339,12 +1339,14 @@ static void invalidate_all_devices(void)
> >  iterate_ivrs_mappings(_invalidate_all_devices);
> >  }
> >
> > -void amd_iommu_suspend(void)
> > +int amd_iommu_suspend(void)
> >  {
> >  struct amd_iommu *iommu;
> >
> >  for_each_amd_iommu ( iommu )
> >  disable_iommu(iommu);
> > +
> > +return 0;
> >  }
> >
> >  void amd_iommu_resume(void)
> > @@ -1368,3 +1370,11 @@ void amd_iommu_resume(void)
> >  invalidate_all_domain_pages();
> >  }
> >  }
> > +
> > +void amd_iommu_crash_shutdown(void)
> > +{
> > +struct amd_iommu *iommu;
> > +
> > +for_each_amd_iommu ( iommu )
> > +disable_iommu(iommu);
> > +}
> 
> One of the two should clearly call the other - no need to have the same code
> twice.
> 

Good idea.

> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -182,7 +182,11 @@ void __hwdom_init iommu_hwdom_init(struct
> domain *d)
> >   ((page->u.inuse.type_info & PGT_type_mask)
> >== PGT_writable_page) )
> >  mapping |= IOMMUF_writable;
> > -hd->platform_ops->map_page(d, gfn, mfn, mapping);
> > +if ( hd->platform_ops->map_page(d, gfn, mfn, mapping) )
> > +printk(XENLOG_G_ERR
> > +   "IOMMU: Map page gfn: 0x%lx(mfn: 0x%lx)
> failed.\n",
> > +   gfn, mfn);
> > +
> 
> Printing one message here is certainly necessary, but what if the failure 
> repeats
> for very many pages? 

Yes, to me, it is ok, but I am open to your suggestion.

> Also %#lx instead of 0x%lx please, and a blank before the
> opening parenthesis.
> 
OK, just check it:

..
"IOMMU: Map page gfn: %#lx (mfn: %#lx) failed.\n"
..

Right?


> > @@ -554,11 +555,24 @@ static void iommu_flush_all(void)
> >  iommu = drhd->iommu;
> >  iommu_flush_context_global(iommu, 0);
> >  flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> > -iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> > +rc = iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> > +
> > +if ( rc > 0 )
> > +{
> > +iommu_flush_write_buffer(iommu);
> 
> Why is this needed all of the sudden?

As there may be multiple IOMMUs. .e.g, there are 2 IOMMUs in my machine, and I 
can find the following log message:
"""
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
"""
__iiuc__, iommu_flush_write_buffer() is per IOMMU, so It should be called to 
flush every IOMMU.



> (Note that if you did a more fine grained
> split, it might also be easier for you to note/ explain all the not directly 
> related
> changes in the respective commit messages. Unless of course they fix actual
> bugs, in which case they should be split out anyway; such individual fixes 
> would
> also likely have a much faster route to commit, relieving you earlier from the
> burden of at least some of the changes you have to carry and re-base.)
> 
> > +rc = 0;
> > +}
> > +else if ( rc < 0 )
> > +{
> > +printk(XENLOG_G_ERR "IOMMU: IOMMU flush all failed.\n");
> > +break;
> > +}
> 
> Is a log message really advisable here?
> 

To me, It looks tricky too. I was struggling to make decision. For scheme B, I 
would try to do as below:

if ( iommu_flush_all() )
printk("... nnn ...");

but there are 4 function calls, if so, to me, it looks redundant.

Or, could I ignore the print out for iommu_flush_all() failed?



> > -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > gfn,
> > +static int __intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > +gfn,
> 
> While I'm not VT-d maintainer, I think changes like this would be a good
> opportunity to also drop the stray double underscores: You need to touch all
> callers anyway.
> 

I think this is optional.


> > @@ -584,37 +599,40 @@ static void __intel_iommu_iotlb_flush(struct
> > domain *d, unsigned long gfn,
> >  continue;
> >
> >  if ( page_count != 1 || gfn == INVALID_GFN )
> > -{
> > -if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
> > -0, flush_dev_iotlb) )
> > -iommu_flush_write_buffer(iommu);
> > -}
> > +rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
> > +   0, flush_dev_iotlb);
> >  else
> > +rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
> > +   (paddr_t)gfn <<
> PAGE_SHIFT_4K, 0,
> > +   !dma_old_pte_present,
> > +   flush_dev_iotlb);
> 

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

[Juergen Gross]

On 24/03/16 12:38, George Dunlap wrote:
> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>  wrote:
>> On 24/03/16 10:58, Juergen Gross wrote:
>>> I've searched a little bit in git history in order to understand why
>>> xen-detect has been invented and/or has all the options which clearly
>>> are meant to be used in scripts.
>>>
>>> The last large modification was done in 2009 and I think Konrad is to
>>> blame here. ;-)
>>>
>>> It was meant to be used in early boot sequence to autoload the needed
>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>> this usage isn't needed any longer as the dom0 case is handled
>>> differently and the needed frontends are loaded automatically on demand.
>>>
>>> So this means we can drop all the options of xen-detect, as they serve
>>> no purpose today.
>>>
>>> Next question is whether the remaining functionality warrants keeping
>>> xen-detect, and how the information it is presenting can be obtained.
>>>
>>> If we want to keep it, I can think of following solutions:
>>> - new kernel ABI (as suggested, David doesn't like it)
>>> - follow the route it is taking today, information is unreliable
>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>   and printing that information (would work, but is a little bit hacky)
>>>
>>> Thoughts?
>>
>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>> always be playing catchup.
>>
>> Parsing? that's not a little hacky...  The ABI is definitely a better
>> solution.
>>
>> As for the ABI,
>>
>> [root@fusebot ~]# find /sys/hypervisor/
>> /sys/hypervisor/
>> /sys/hypervisor/type
>> /sys/hypervisor/uuid
>> /sys/hypervisor/compilation
>> /sys/hypervisor/compilation/compiled_by
>> /sys/hypervisor/compilation/compile_date
>> /sys/hypervisor/compilation/compiler
>> /sys/hypervisor/properties
>> /sys/hypervisor/properties/pagesize
>> /sys/hypervisor/properties/changeset
>> /sys/hypervisor/properties/virtual_start
>> /sys/hypervisor/properties/features
>> /sys/hypervisor/properties/capabilities
>> /sys/hypervisor/version
>> /sys/hypervisor/version/extra
>> /sys/hypervisor/version/major
>> /sys/hypervisor/version/minor
>>
>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>> and is applicable to all hypervisors, not just Xen.
> 
> FWIW this sounds reasonable to me.

Another sum up:

- common sense seems to be the current way xen-detect is trying to
  guess the guest type is unreliable and should be dropped (Jan
  would like to keep it, but I guess he just wants the information
  to be available - is this correct, Jan?)
- the command line options of xen-detect are not necessary any more
- the information which guest type we are should be obtainable from
  inside the guest, the consumer of this information should be humans
  only
- the OS already knows in which mode it is running, so it should be the
  kernel to present that information (David disagrees here: he isn't
  convinced this information is it worth to add another kernel
  interface)

As there is no real hurry to have this topic settled I'd suggest we just
discuss it at the Hackathon (all involved in the discussion so far but
George will be there). What do you think?


Juergen


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

[Xen-devel] [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao 
---
 drivers/acpi/scan.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5420cc5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+   void *context)
+{
+   struct resource *res = context;
+
+   if (acpi_dev_resource_memory(ares, res))
+   return AE_CTRL_TERMINATE;
+
+   return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   struct resource res;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_memory, );
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (res.start == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device in SPCR table 
will be hidden\n");
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
 }
 
+static void __init acpi_get_spcr_uart_addr(void)
+{
+   acpi_status status;
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
missing\n");
+}
+
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(_device_handler);
 
+   /*
+* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart)
+   acpi_get_spcr_uart_addr();
+   }
+
mutex_lock(_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4



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

[Xen-devel] [xen-unstable test] 87181: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm3 host-install(3) broken REGR. vs. 86491
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-saverestore  fail REGR. vs. 86491
 test-armhf-armhf-libvirt  7 host-ping-check-xen   fail REGR. vs. 86491
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 87093 
REGR. vs. 86491
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail in 87093 REGR. vs. 86491
 build-armhf-libvirt   4 host-build-prep  fail in 87093 REGR. vs. 86491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-migrupgrade 4 host-install/dst_host(4) broken in 87093 pass 
in 87181
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 87093 pass in 
87181
 test-amd64-i386-xl-qemut-win7-amd64 12 guest-saverestorefail pass in 87093
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore   fail pass in 87093
 test-armhf-armhf-xl   6 xen-bootfail pass in 87093

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 86491
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail in 87093 like 86491
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 87093 like 86491
 build-amd64-rumpuserxen   6 xen-buildfail   like 86491
 build-i386-rumpuserxen6 xen-buildfail   like 86491
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86491

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)blocked in 87093 n/a
 test-armhf-armhf-libvirt  1 build-check(1)blocked in 87093 n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)  blocked in 87093 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)blocked in 87093 n/a
 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-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-check fail in 87093 never pass
 test-armhf-armhf-xl  12 migrate-support-check fail in 87093 never pass
 test-armhf-armhf-xl  13 saverestore-support-check fail in 87093 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 87093 never pass
 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check

Re: [Xen-devel] [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

On 2016/3/24 23:08, Rafael J. Wysocki wrote:
> On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao  wrote:
>> > +static void acpi_get_spcr_uart_addr(void)
> static void __init acpi_get_spcr_uart_addr(void)
> 
> I suppose?
> 
> Apart from this it looks fine.
> 
Thanks, I'll update this one and resend it later.

-- 
Shannon


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

Re: [Xen-devel] [PATCH v6 15/22] arm/acpi: Permit access all Xen unused SPIs for Dom0

[Shannon Zhao]

On 2016/3/24 23:37, Julien Grall wrote:
> Hi Shannon,
> 
> On 24/03/16 15:01, Shannon Zhao wrote:
>> On 2016年03月23日 02:18, Julien Grall wrote:
>>>
 + * Dom0 configures the interrupt, set the interrupt type and
 route it to
 + * Dom0.
 + */
 +for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
 +{
 +desc = irq_to_desc(i);
 +if( desc->action != NULL)
>>>
>>> Well some of the SPIs used by Xen may not be registered yet. For
>>> instance the SMMU driver doesn't register any SPIs until it's necessary
>>> (i.e a device is assigned to a domain).
>> But when SMMU requests some SPI, it will delete the route and
>> reconfigure the SPI, right?
> 
> No, the SMMU driver will fail to request the interrupt if it's already
> in use.
Hmm, re-think about this, since we don't support SMMU with ACPI now, we
could exclude those interrupts later. I'll add a TODO comment here.

Thanks.
-- 
Shannon


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

[Xen-devel] [PATCH v13 17/26] implement the cmdline for COLO

[Changlong Xie]

From: Wen Congyang 

Add a new option -c to the command 'xl remus'. If you want
to use COLO HA instead of Remus HA, please use -c option.

Update man pages to reflect the addition of a new option to
'xl remus' command.

Also add a new option --colo to the internal command 'xl migrate-receive'.

Signed-off-by: Wen Congyang 
Signed-off-by: Yang Hongyang 
Signed-off-by: Changlong Xie 
Acked-by: Ian Jackson 
---
 docs/man/xl.pod.1  | 13 --
 tools/libxl/libxl.c| 22 ++--
 tools/libxl/libxl_create.c |  1 -
 tools/libxl/xl_cmdimpl.c   | 65 +++---
 tools/libxl/xl_cmdtable.c  |  4 ++-
 5 files changed, 84 insertions(+), 21 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index dc6213e..a992a45 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -447,12 +447,16 @@ Print huge (!) amount of debug during the migration 
process.
 
 =item B [I] I I
 
-Enable Remus HA for domain. By default B relies on ssh as a transport
-mechanism between the two hosts.
+Enable Remus HA or COLO HA for domain. By default B relies on ssh as a
+transport mechanism between the two hosts.
 
 N.B: Remus support in xl is still in experimental (proof-of-concept) phase.
  Disk replication support is limited to DRBD disks.
 
+ COLO support in xl is still in experimental (proof-of-concept) phase.
+ There is no support for network or disk, so the guest will corrupt its
+ disk and confuse its network peers at the moment.
+
 B
 
 =over 4
@@ -498,6 +502,11 @@ Disable network output buffering. Requires enabling unsafe 
mode.
 
 Disable disk replication. Requires enabling unsafe mode.
 
+=item B<-c>
+
+Enable COLO HA. This conflicts with B<-i> and B<-b>, and memory
+checkpoint compression must be disabled.
+
 =back
 
 =item B I
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 272c6a5..349a3c6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -848,12 +848,27 @@ int libxl_domain_remus_start(libxl_ctx *ctx, 
libxl_domain_remus_info *info,
 goto out;
 }
 
+/* The caller must set this defbool */
+if (libxl_defbool_is_default(info->colo)) {
+LOG(ERROR, "colo mode must be enabled/disabled");
+rc = ERROR_FAIL;
+goto out;
+}
+
 libxl_defbool_setdefault(>allow_unsafe, false);
 libxl_defbool_setdefault(>blackhole, false);
-libxl_defbool_setdefault(>compression, true);
+libxl_defbool_setdefault(>compression,
+ !libxl_defbool_val(info->colo));
 libxl_defbool_setdefault(>netbuf, true);
 libxl_defbool_setdefault(>diskbuf, true);
 
+if (libxl_defbool_val(info->colo) &&
+libxl_defbool_val(info->compression)) {
+LOG(ERROR, "cannot use memory checkpoint compression in COLO 
mode");
+rc = ERROR_FAIL;
+goto out;
+}
+
 if (!libxl_defbool_val(info->allow_unsafe) &&
 (libxl_defbool_val(info->blackhole) ||
  !libxl_defbool_val(info->netbuf) ||
@@ -875,7 +890,10 @@ int libxl_domain_remus_start(libxl_ctx *ctx, 
libxl_domain_remus_info *info,
 dss->live = 1;
 dss->debug = 0;
 dss->remus = info;
-dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
+if (libxl_defbool_val(info->colo))
+dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_COLO;
+else
+dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
 
 assert(info);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index d6c794e..be604e5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1893,7 +1893,6 @@ int libxl_domain_create_restore(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 const libxl_asyncop_how *ao_how,
 const libxl_asyncprogress_how *aop_console_how)
 {
-assert(send_back_fd == -1);
 return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
 params, ao_how, aop_console_how);
 }
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2e64f44..25bd81a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4740,6 +4740,8 @@ static void migrate_receive(int debug, int daemonize, int 
monitor,
 char rc_buf;
 char *migration_domname;
 struct domain_create dom_info;
+const char *ha = checkpointed == LIBXL_CHECKPOINTED_STREAM_COLO ?
+ "COLO" : "Remus";
 
 signal(SIGPIPE, SIG_IGN);
 /* if we get SIGPIPE we'd rather just have it as an error */
@@ -4757,7 +4759,7 @@ static void migrate_receive(int debug, int daemonize, int 
monitor,
 dom_info.monitor = monitor;
 dom_info.paused = 1;
 dom_info.migrate_fd = recv_fd;
-dom_info.send_back_fd = -1;
+dom_info.send_back_fd = send_fd;
 

[Xen-devel] [PATCH v13 12/26] secondary vm suspend/resume/checkpoint code

[Changlong Xie]

From: Wen Congyang 

Secondary vm is running in colo mode. So we will do
the following things again and again:
1. Resume secondary vm
   a. Send CHECKPOINT_SVM_READY to master.
   b. If it is not the first resume, call libxl__checkpoint_devices_preresume().
   c. If it is the first resume(resume right after live migration),
  - call libxl__xc_domain_restore_done() to build the secondary vm.
  - enable secondary vm's logdirty.
  - call libxl__domain_resume() to resume secondary vm.
  - call libxl__checkpoint_devices_setup() to setup checkpoint devices.
   d. Send CHECKPOINT_SVM_RESUMED to master.
2. Wait a new checkpoint
   a. Call libxl__checkpoint_devices_commit().
   b. Read CHECKPOINT_NEW from master.
3. Suspend secondary vm
   a. Suspend secondary vm.
   b. Call libxl__checkpoint_devices_postsuspend().
   c. Send CHECKPOINT_SVM_SUSPENDED to master.
4. Checkpoint
   a. Read emulator xenstore data and emulator context
   b. REC_TYPE_CHECKPOINT_END

Signed-off-by: Wen Congyang 
Signed-off-by: Yang Hongyang 
Signed-off-by: Changlong Xie 
---
 tools/libxc/include/xenguest.h |   20 +
 tools/libxc/xc_sr_save.c   |3 +-
 tools/libxl/Makefile   |1 +
 tools/libxl/libxl_colo.h   |   55 ++
 tools/libxl/libxl_colo_restore.c   | 1029 
 tools/libxl/libxl_create.c |   45 ++
 tools/libxl/libxl_internal.h   |   10 +-
 tools/libxl/libxl_save_callout.c   |6 +-
 tools/libxl/libxl_save_msgs_gen.pl |   11 +-
 tools/libxl/libxl_stream_read.c|   12 +
 tools/libxl/libxl_types.idl|1 +
 11 files changed, 1180 insertions(+), 13 deletions(-)
 create mode 100644 tools/libxl/libxl_colo.h
 create mode 100644 tools/libxl/libxl_colo_restore.c

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index b4f4bfb..3193d0f 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -78,6 +78,7 @@ struct save_callbacks {
 typedef enum {
 XC_MIG_STREAM_NONE, /* plain stream */
 XC_MIG_STREAM_REMUS,
+XC_MIG_STREAM_COLO,
 } xc_migration_stream_t;
 
 /**
@@ -97,6 +98,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom, uint32_t max_iter
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
+/* Called after a new checkpoint to suspend the guest.
+ */
+int (*suspend)(void* data);
+
+/* Called after the secondary vm is ready to resume.
+ * Callback function resumes the guest & the device model,
+ * returns to xc_domain_restore.
+ */
+int (*postcopy)(void* data);
+
 /* A checkpoint record has been found in the stream.
  * returns: */
 #define XGR_CHECKPOINT_ERROR0 /* Terminate processing */
@@ -104,6 +115,15 @@ struct restore_callbacks {
 #define XGR_CHECKPOINT_FAILOVER 2 /* Failover and resume VM */
 int (*checkpoint)(void* data);
 
+/*
+ * Called after the checkpoint callback.
+ *
+ * returns:
+ * 0: terminate checkpointing gracefully
+ * 1: take another checkpoint
+ */
+int (*wait_checkpoint)(void* data);
+
 /* to be provided as the last argument to each callback function */
 void* data;
 };
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index 1ccdbbb..d3d95d4 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -846,7 +846,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom,
 
 /* If altering migration_stream update this assert too. */
 assert(stream_type == XC_MIG_STREAM_NONE ||
-   stream_type == XC_MIG_STREAM_REMUS);
+   stream_type == XC_MIG_STREAM_REMUS ||
+   stream_type == XC_MIG_STREAM_COLO);
 
 /*
  * TODO: Find some time to better tweak the live migration algorithm.
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 8fa7b87..35a07a7 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -65,6 +65,7 @@ LIBXL_OBJS-y += libxl_no_convert_callout.o
 endif
 
 LIBXL_OBJS-y += libxl_remus.o libxl_checkpoint_device.o libxl_remus_disk_drbd.o
+LIBXL_OBJS-y += libxl_colo_restore.o
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
new file mode 100644
index 000..f2b98cc
--- /dev/null
+++ b/tools/libxl/libxl_colo.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2016 FUJITSU LIMITED
+ * Author: Wen Congyang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but