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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 93001
 build-i386-rumpuserxen6 xen-buildfail   like 93001
 build-amd64-rumpuserxen   6 xen-buildfail   like 93001
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93001
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93001
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93001
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93001

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

version targeted for testing:
 xen  f9bf994d81031b53191106e78653c3983e8e3536
baseline version:
 xen  981cfa96f183c5a6b62502d6f7d7b5c3b4e1e878

Last test of basis93001  2016-04-27 18:44:26 Z2 days
Testing same since93225  2016-04-29 16:26:39 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dirk Behme 
  Doug Goldstein 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall  [ARM]
  Konrad Rzeszutek Wilk 
  Martin Pohlack 
  Roger Pau Monné 
  Ross Lagerwall 
  Stefano Stabellini 
  Wei Liu 
  Yu Zhang 

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

[Xen-devel] [linux-3.4 baseline-only test] 44372: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44372 linux-3.4 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44372/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 44273
 test-amd64-i386-xl-raw   18 guest-start/debian.repeat fail REGR. vs. 44273

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44273
 build-amd64-rumpuserxen   6 xen-buildfail   like 44273

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

version targeted for testing:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4
baseline version:
 linux3389604d77540abf738b486d650c1745b2d663ca

Last test of basis44273  2016-03-22 11:52:37 Z   38 days
Testing same since44372  2016-04-29 15:54:02 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexander Duyck 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Lutomirski  kernel.org>
  Andy Lutomirski 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Ben Skeggs 
  Bjorn Helgaas 
  Bob Copeland 
  Borislav Petkov 
  Cathy Avery 
  Charles Keepax 
  Christian Zander 
  Christoph Biedl 
  Christoph Hellwig 
  Christophe Leroy 
  Chuck Lever 
  Dan Carpenter 
  Dave Airlie 
  David Daney 
  David Härdeman 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Felix Fietkau 
  G. Richard Bellamy 
  Geert Uytterhoeven 
  Grant Likely 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  H. Nikolaus Schaller 
  Herbert Xu 
  Hin-Tak Leung 
  Ilia Mirkin 
  Ingo Molnar 
  J. Bruce Fields 
  James Bottomley 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jeffery Miller 
  Jens Axboe 
  Jesse Jones 
  Joe Thornber 
  Joerg Roedel 
  Johan Hovold 
  Johannes Berg 
  John Stultz 
  Joseph Qi 
  Kalle Valo 
  Kamal Mostafa  canonical.com>
  Kees Cook 

[Xen-devel] [linux-4.1 test] 93220: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  11 guest-startfail in 93111 pass in 93220
 test-armhf-armhf-xl-xsm  11 guest-start fail pass in 93111
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 93111

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail in 93111 like 92143
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 93111 like 
92143
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 93111 like 92143
 build-amd64-rumpuserxen   6 xen-buildfail   like 92143
 build-i386-rumpuserxen6 xen-buildfail   like 92143
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 92143
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail   like 92143
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92143
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92143
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92143
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92143
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 92143

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

version targeted for testing:
 linux54419e3efcd6677e4b0841666e2fc605d2e5df86
baseline version:
 linux6fe78bc1bfcddabbf3d210e18f91da44fa796d8a

Last test of basis92143  2016-04-20 07:33:07 Z9 days
Testing same since93111  2016-04-28 16:51:58 Z1 days2 attempts


People who touched revisions under test:
  Alan Stern 
  Andrew Morton 
  Andy Shevchenko 
  Bjørn Mork 
  Boris Ostrovsky 
  Chris Mason 
  Daniel Fraga 
  Daniel Vetter 
  David Disseldorp 
  David Howells 
  David Matlack 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 91479
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
91479
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 91479

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

version targeted for testing:
 libvirt  5ba48584fbc5079c0ddbc9e9a52c96d7bcef0761
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z   14 days
Failing since 91597  2016-04-16 04:20:46 Z   13 days   13 attempts
Testing same since93223  2016-04-29 15:41:36 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ben Gray 
  Cole Robinson 
  Dmitry Andreev 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Simon Arlott 

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   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 

[Xen-devel] [linux-3.18 baseline-only test] 44371: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44371 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44371/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44352
 build-amd64-rumpuserxen   6 xen-buildfail   like 44352

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

version targeted for testing:
 linux834125557e0a4e5afafee3caf79696078d0820ae
baseline version:
 linuxf151e73cea45b97a5690806f3391d10e547d04d9

Last test of basis44352  2016-04-21 17:54:28 Z8 days
Testing same since44371  2016-04-29 14:51:27 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Andrew Morton 
  Andy Shevchenko 
  Anssi Hannula 
  Bin Liu 
  Bjørn Mork 
  Boris Ostrovsky 
  Chris Mason 
  Christoph Lameter 
  Daniel Fraga 
  David Disseldorp 
  David Howells 
  David Matlack 
  David S. Miller 
  David Vrabel 
  Dennis Kadioglu 
  Eric Dumazet 
  Eric Wong 
  Felipe Balbi 
  Felipe Balbi 
  Filipe Manana 
  Greg Kroah-Hartman 
  Hans de Goede 
  Helge Deller 
  Hui Wang 
  Ilya Dryomov 
  Jani Nikula 
  Jerome Marchand 
  

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

[osstest service owner]

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

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  c2994f8632d56e5379e612daa216401477dccbdb
baseline version:
 xen  a29e895b2bde17ab239da3bff76ec00c8d9b2e77

Last test of basis93226  2016-04-29 17:01:58 Z0 days
Testing same since93229  2016-04-29 19:02:30 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=c2994f8632d56e5379e612daa216401477dccbdb
+ . ./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 
c2994f8632d56e5379e612daa216401477dccbdb
+ branch=xen-unstable-smoke
+ revision=c2994f8632d56e5379e612daa216401477dccbdb
+ . ./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
+ '[' xc2994f8632d56e5379e612daa216401477dccbdb = 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 v2 2/5] vm_event: Implement ARM SMC events

[Razvan Cojocaru]

On 04/29/16 23:27, Tamas K Lengyel wrote:
> 
>  
> 
> 
> > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> > index 2906407..a29bda8 100644
> > --- a/xen/common/vm_event.c
> > +++ b/xen/common/vm_event.c
> > @@ -818,7 +818,6 @@ int vm_event_monitor_traps(struct vcpu *v, 
> uint8_t sync,
> >  req->altp2m_idx = altp2m_vcpu_idx(v);
> >  }
> >
> > -vm_event_fill_regs(req);
> >  vm_event_put_request(d, >vm_event->monitor, req);
> >
> >  return 1;
> 
> So now for x86 we only vm_fill_regs() for CR writes and
> breakpoints (and
> EPT faults, but that's in p2m.c which hasn't been touched by this
> patch)? That's a pretty big change, and one that's not explained
> in the
> patch description (which makes no mention of any x86 changes).
> 
> Having that call in vm_event_monitor_traps() made sure that all
> vm_events get a copy of the respective registers. In the x86
> case, that
> includes the guest request and MSR write events, which now no longer
> seem to carry that information, unless I'm missing something.
> 
> That behaviour should not change for x86 events, please.
> 
> 
> Yeap, good catch. It needs to be moved from the common path because
> the inputs to the function will differ on ARM and x86. I'll
> double-check that the x86 paths will remain functionally the same.
> 
> 
> So for mem_access nothing changes in this patch, fill_regs was already
> called from p2m.c. For MSR's I just missed adding the extra call. As for
> vm_event_monitor_guest_request, it will needs to be moved to be
> arch-specific. I think I'll do it as a precursor patch where I move it
> to be in the arch-specific monitor code (where it should be actually).
> Will do these fixes in the next round.

Fair enough, thanks!


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

Re: [Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

>
>
>
>
>>
>> > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> > index 2906407..a29bda8 100644
>> > --- a/xen/common/vm_event.c
>> > +++ b/xen/common/vm_event.c
>> > @@ -818,7 +818,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t
>> sync,
>> >  req->altp2m_idx = altp2m_vcpu_idx(v);
>> >  }
>> >
>> > -vm_event_fill_regs(req);
>> >  vm_event_put_request(d, >vm_event->monitor, req);
>> >
>> >  return 1;
>>
>> So now for x86 we only vm_fill_regs() for CR writes and breakpoints (and
>> EPT faults, but that's in p2m.c which hasn't been touched by this
>> patch)? That's a pretty big change, and one that's not explained in the
>> patch description (which makes no mention of any x86 changes).
>>
>> Having that call in vm_event_monitor_traps() made sure that all
>> vm_events get a copy of the respective registers. In the x86 case, that
>> includes the guest request and MSR write events, which now no longer
>> seem to carry that information, unless I'm missing something.
>>
>> That behaviour should not change for x86 events, please.
>>
>
> Yeap, good catch. It needs to be moved from the common path because the
> inputs to the function will differ on ARM and x86. I'll double-check that
> the x86 paths will remain functionally the same.
>

So for mem_access nothing changes in this patch, fill_regs was already
called from p2m.c. For MSR's I just missed adding the extra call. As for
vm_event_monitor_guest_request, it will needs to be moved to be
arch-specific. I think I'll do it as a precursor patch where I move it to
be in the arch-specific monitor code (where it should be actually). Will do
these fixes in the next round.

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

Re: [Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

> @@ -2491,6 +2492,21 @@ bad_data_abort:
> >  inject_dabt_exception(regs, info.gva, hsr.len);
> >  }
> >
> > +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> > +{
> > +int rc = 0;
> > +if ( current->domain->arch.monitor.privileged_call_enabled )
> > +{
> > +rc = monitor_smc(regs);
> > +}
>
>
> If you need to increment the patch version, maybe remove the curly
> braces here?
>

Sure.


>
> > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> > index 2906407..a29bda8 100644
> > --- a/xen/common/vm_event.c
> > +++ b/xen/common/vm_event.c
> > @@ -818,7 +818,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t
> sync,
> >  req->altp2m_idx = altp2m_vcpu_idx(v);
> >  }
> >
> > -vm_event_fill_regs(req);
> >  vm_event_put_request(d, >vm_event->monitor, req);
> >
> >  return 1;
>
> So now for x86 we only vm_fill_regs() for CR writes and breakpoints (and
> EPT faults, but that's in p2m.c which hasn't been touched by this
> patch)? That's a pretty big change, and one that's not explained in the
> patch description (which makes no mention of any x86 changes).
>
> Having that call in vm_event_monitor_traps() made sure that all
> vm_events get a copy of the respective registers. In the x86 case, that
> includes the guest request and MSR write events, which now no longer
> seem to carry that information, unless I'm missing something.
>
> That behaviour should not change for x86 events, please.
>

Yeap, good catch. It needs to be moved from the common path because the
inputs to the function will differ on ARM and x86. I'll double-check that
the x86 paths will remain functionally the same.

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

Re: [Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Razvan Cojocaru]

On 04/29/16 21:07, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIVILEGED_CALL type.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Razvan Cojocaru 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> Cc: Julien Grall 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> v2: introduce VM_EVENT_REASON_PRIVELEGED_CALL
> aarch64 support
> ---
>  MAINTAINERS |   6 +-
>  tools/libxc/include/xenctrl.h   |   2 +
>  tools/libxc/xc_monitor.c|  26 +++-
>  tools/tests/xen-access/xen-access.c |  31 -
>  xen/arch/arm/Makefile   |   2 +
>  xen/arch/arm/monitor.c  |  80 +++
>  xen/arch/arm/traps.c|  20 +-
>  xen/arch/arm/vm_event.c | 127 
> 
>  xen/arch/x86/hvm/event.c|   2 +
>  xen/common/vm_event.c   |   1 -
>  xen/include/asm-arm/domain.h|   5 ++
>  xen/include/asm-arm/monitor.h   |  20 ++
>  xen/include/asm-arm/vm_event.h  |  16 ++---
>  xen/include/public/domctl.h |   1 +
>  xen/include/public/vm_event.h   |  27 
>  15 files changed, 333 insertions(+), 33 deletions(-)
>  create mode 100644 xen/arch/arm/monitor.c
>  create mode 100644 xen/arch/arm/vm_event.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5af7a0c..36d8591 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -355,12 +355,10 @@ VM EVENT AND MEM ACCESS
>  M:   Razvan Cojocaru 
>  M:   Tamas K Lengyel 
>  S:   Supported
> -F:   xen/common/vm_event.c
> +F:   xen/*/vm_event.c
> +F:   xen/*/monitor.c
>  F:   xen/common/mem_access.c
> -F:   xen/common/monitor.c
>  F:   xen/arch/x86/hvm/event.c
> -F:   xen/arch/x86/monitor.c
> -F:   xen/arch/*/vm_event.c
>  F:   tools/tests/xen-access
>  
>  VTPM

This patch touches MAINTANERS, but so does the last patch in the series
(which does nothing else but touch MAINTAINERS). I wouldn't block this
patch on this account, but would it be problematic for all changes to
MAINTAINERS to occur in that patch?

> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 42f201b..4b75ae4 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2160,6 +2160,8 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
> domid_t domain_id,
> bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
>   bool enable, bool sync);
> +int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
> +   bool enable);
>  
>  /**
>   * This function enables / disables emulation for each REP for a
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b1705dd..072df70 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -4,7 +4,7 @@
>   *
>   * Interface to VM event monitor
>   *
> - * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> + * Copyright (c) 2015-2016 Tamas K Lengyel (ta...@tklengyel.com)
>   *
>   * This library is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU Lesser General Public
> @@ -156,3 +156,27 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, 
> domid_t domain_id,
>  
>  return do_domctl(xch, );
>  }
> +
> +int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
> +   bool enable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
> +
> +return do_domctl(xch, );
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index f26e723..33e8044 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -334,6 +334,8 @@ void usage(char* progname)
>  fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
>  #if defined(__i386__) || defined(__x86_64__)
>  fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec");
> +#elif defined(__arm__) || 

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

[osstest service owner]

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

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 b59e2427c2d92cfee0238d9bde7372691c2af17c
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  143 days
Failing since 65593  2015-12-08 23:44:51 Z  142 days  191 attempts
Testing same since93204  2016-04-29 11:14:57 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

Re: [Xen-devel] how to set up a #VE

[Tamas K Lengyel]

On Thu, Apr 28, 2016 at 10:27 PM, Big Strong  wrote:

> You can always just add a new page to the domain to be used for #VE.
>
> It's there a method to directly assign physical pages to guest from dom0?
> Using xc_map_foreign_address just like libvmi?
>

Please don't top-post on xen-devel.

You could share a page from dom0 but I think what you want to do is
increase the reservation of the domain and then map it into so it can be
used for #VE. The functions for this are
xc_domain_increase_reservation_exact and xc_domain_populate_physmap_exact.

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Luis R. Rodriguez]

On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez  wrote:
> On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote:
>> On Mon, 2016-02-29 at 10:12 +, David Woodhouse wrote:
>> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
>> > > This ports built-in firmware to use linker tables,
>> > > this replaces the custom section solution with a
>> > > generic solution.
>> > >
>> > > This also demos the use of the .rodata (SECTION_RO)
>> > > linker tables.
>> > >
>> > > Tested with 0 built-in firmware, 1 and 2 built-in
>> > > firmwares successfully.
>> >
>> > I think we'd do better to rip this support out entirely. It just
>> > isn't needed; firmware can live in an initramfs and don't even need
>> > *any* actual running userspace support to load it from there these
>> > days, do we?
>>
>> We have lots of SCSI drivers with built in firmware.  The obvious
>> examples are 53c700, aic7xxx and aic79xx.  For them, we actually have
>> the firmware compilers in tree.  The firmware model they use just isn't
>> amenable to the firmware loader: they're not monolithic blobs, it's a
>> set of firmware scripts we use to handle particular operations before
>> giving control back to the host, so the firmware and the driver are
>> very much symbiotic.
>
> I'm in the process of doing some other cleanups with the firmware_class
> stuff so that odd requirements get supported but clean interfaces are
> also not hampered by these odd requirements, so I'll take a look at
> this later. If you have other oddball firmware requirements please
> let me know so I can also keep in mind.
>
>> On the other hand, I don't think any of them uses firmware sections, so
>> it's not an argument for not ripping out this type.
>
> Thanks for confirming. I'll rip this out.

Just a heads up, I've put the removal through 0-day without issues,
I'll be folding the removal into another series of changes for the
firmware API which should help compartmentalize the user mode helper
stuff as well.

 Luis

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

Re: [Xen-devel] 2016 Xen hackathon notes - xenstored

[Luis R. Rodriguez]

On Fri, Apr 29, 2016 at 04:33:31PM +0200, Filipe Manco wrote:
> Hi
> 
> Regarding LiXS, our goal is to make it one of the upstream xenstore
> alternatives. For that I already started getting internal approvals
> to release the code open source, which should happen somewhere
> around next month. I also need to fix some bugs and would like to do
> some performance testing before the release.
> 
> Once it is released, it would be nice to get some comments from the
> community on the implementation, specifically about how to make it
> upstreamable; I’ll let you know when the code is available.
> 
> Does this plan sound reasonable?

I have no say in the Xen community, but to me this sounds reasonable,
you should have competing solutions and let people win, its the
same principle that was applied to Linux Security Modules, for
instance, and that philosophy tends to enable all viable options
to compete while upstream. For Xen, there are already 2 xenstores,
having another IMHO should just require commitment for a maintainer
to upkeep it. Without that it should make no sense.

You also require C++ though ? That's a new requirement AFAICT, so
that would need to be addressed.

If it were up to me, I'd recommend to consider extending Kconfig
onto tools, and then having the xenstore be a Kconfig option.

  Luis

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

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

[osstest service owner]

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

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  a29e895b2bde17ab239da3bff76ec00c8d9b2e77
baseline version:
 xen  f9bf994d81031b53191106e78653c3983e8e3536

Last test of basis93195  2016-04-29 10:01:34 Z0 days
Testing same since93226  2016-04-29 17:01:58 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a29e895b2bde17ab239da3bff76ec00c8d9b2e77
+ . ./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 
a29e895b2bde17ab239da3bff76ec00c8d9b2e77
+ branch=xen-unstable-smoke
+ revision=a29e895b2bde17ab239da3bff76ec00c8d9b2e77
+ . ./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
+ '[' xa29e895b2bde17ab239da3bff76ec00c8d9b2e77 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [PATCH v2 3/5] x86/hvm: Rename hvm/event to hvm/monitor

[Tamas K Lengyel]

Mechanical renaming to better describe that the code in hvm/event is part of
the monitor subsystem.

Signed-off-by: Tamas K Lengyel 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Razvan Cojocaru 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 MAINTAINERS|  1 -
 xen/arch/x86/hvm/Makefile  |  2 +-
 xen/arch/x86/hvm/hvm.c | 12 +--
 xen/arch/x86/hvm/{event.c => monitor.c}| 17 ---
 xen/arch/x86/hvm/vmx/vmx.c | 13 +--
 xen/include/asm-x86/hvm/{event.h => monitor.h} | 30 +-
 6 files changed, 38 insertions(+), 37 deletions(-)
 rename xen/arch/x86/hvm/{event.c => monitor.c} (88%)
 rename xen/include/asm-x86/hvm/{event.h => monitor.h} (60%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36d8591..0c050a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -358,7 +358,6 @@ S:  Supported
 F: xen/*/vm_event.c
 F: xen/*/monitor.c
 F: xen/common/mem_access.c
-F: xen/arch/x86/hvm/event.c
 F: tools/tests/xen-access
 
 VTPM
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 8bc55a9..f750d13 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,7 +3,6 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += emulate.o
-obj-y += event.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += i8254.o
@@ -11,6 +10,7 @@ obj-y += intercept.o
 obj-y += io.o
 obj-y += ioreq.o
 obj-y += irq.o
+obj-y += monitor.o
 obj-y += mtrr.o
 obj-y += nestedhvm.o
 obj-y += pmtimer.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8cb6e9e..08fd25f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -59,7 +59,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -1960,7 +1960,7 @@ int hvm_handle_xsetbv(u32 index, u64 new_bv)
 {
 int rc;
 
-hvm_event_crX(XCR0, new_bv, current->arch.xcr0);
+hvm_monitor_crX(XCR0, new_bv, current->arch.xcr0);
 
 rc = handle_xsetbv(index, new_bv);
 if ( rc )
@@ -2196,7 +2196,7 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR0, value, old_value) )
+if ( hvm_monitor_crX(CR0, value, old_value) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr0 = 1;
@@ -2298,7 +2298,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR3, value, old) )
+if ( hvm_monitor_crX(CR3, value, old) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr3 = 1;
@@ -2378,7 +2378,7 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR4, value, old_cr) )
+if ( hvm_monitor_crX(CR4, value, old_cr) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr4 = 1;
@@ -3711,7 +3711,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
 
-hvm_event_msr(msr, msr_content);
+hvm_monitor_msr(msr, msr_content);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/monitor.c
similarity index 88%
rename from xen/arch/x86/hvm/event.c
rename to xen/arch/x86/hvm/monitor.c
index f7d1418..76ed811 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -1,5 +1,5 @@
 /*
- * arch/x86/hvm/event.c
+ * arch/x86/hvm/monitor.c
  *
  * Arch-specific hardware virtual machine event abstractions.
  *
@@ -7,6 +7,7 @@
  * Copyright (c) 2005, International Business Machines Corporation.
  * Copyright (c) 2008, Citrix Systems, Inc.
  * Copyright (c) 2016, Bitdefender S.R.L.
+ * Copyright (c) 2016, Tamas K Lengyel (ta...@tklengyel.com)
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -22,12 +23,12 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 
-bool_t hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
+bool_t hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long 
old)
 {
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
@@ -55,7 +56,7 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 return 0;
 }
 
-void hvm_event_msr(unsigned int msr, uint64_t value)
+void hvm_monitor_msr(unsigned int msr, uint64_t 

[Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.

Signed-off-by: Tamas K Lengyel 
---
Cc: Razvan Cojocaru 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: introduce VM_EVENT_REASON_PRIVELEGED_CALL
aarch64 support
---
 MAINTAINERS |   6 +-
 tools/libxc/include/xenctrl.h   |   2 +
 tools/libxc/xc_monitor.c|  26 +++-
 tools/tests/xen-access/xen-access.c |  31 -
 xen/arch/arm/Makefile   |   2 +
 xen/arch/arm/monitor.c  |  80 +++
 xen/arch/arm/traps.c|  20 +-
 xen/arch/arm/vm_event.c | 127 
 xen/arch/x86/hvm/event.c|   2 +
 xen/common/vm_event.c   |   1 -
 xen/include/asm-arm/domain.h|   5 ++
 xen/include/asm-arm/monitor.h   |  20 ++
 xen/include/asm-arm/vm_event.h  |  16 ++---
 xen/include/public/domctl.h |   1 +
 xen/include/public/vm_event.h   |  27 
 15 files changed, 333 insertions(+), 33 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c
 create mode 100644 xen/arch/arm/vm_event.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5af7a0c..36d8591 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -355,12 +355,10 @@ VM EVENT AND MEM ACCESS
 M: Razvan Cojocaru 
 M: Tamas K Lengyel 
 S: Supported
-F: xen/common/vm_event.c
+F: xen/*/vm_event.c
+F: xen/*/monitor.c
 F: xen/common/mem_access.c
-F: xen/common/monitor.c
 F: xen/arch/x86/hvm/event.c
-F: xen/arch/x86/monitor.c
-F: xen/arch/*/vm_event.c
 F: tools/tests/xen-access
 
 VTPM
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 42f201b..4b75ae4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2160,6 +2160,8 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
 
 /**
  * This function enables / disables emulation for each REP for a
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b1705dd..072df70 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -4,7 +4,7 @@
  *
  * Interface to VM event monitor
  *
- * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ * Copyright (c) 2015-2016 Tamas K Lengyel (ta...@tklengyel.com)
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -156,3 +156,27 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t 
domain_id,
 
 return do_domctl(xch, );
 }
+
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index f26e723..33e8044 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -334,6 +334,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -357,6 +359,7 @@ int main(int argc, char *argv[])
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
+int privcall = 0;
 int altp2m = 0;
 uint16_t altp2m_view_id = 0;
 
@@ -412,6 +415,11 @@ int main(int argc, char *argv[])
 default_access = XENMEM_access_rw;
 altp2m = 1;
 }
+#elif defined(__arm__) || defined(__aarch64__)
+else if ( 

[Xen-devel] [PATCH v2 1/5] monitor: Rename vm_event_monitor_get_capabilities

[Tamas K Lengyel]

The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.

Signed-off-by: Tamas K Lengyel 
Acked-by: Andrew Cooper 
Acked-by: Razvan Cojocaru 
---
Cc: Razvan Cojocaru 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/x86/monitor.c |  2 +-
 xen/common/monitor.c   |  5 ++---
 xen/include/asm-arm/monitor.h  | 11 ++-
 xen/include/asm-arm/vm_event.h |  9 -
 xen/include/asm-x86/monitor.h  | 23 +++
 xen/include/asm-x86/vm_event.h | 23 ---
 6 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1fec412..621f91a 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -126,7 +126,7 @@ int arch_monitor_domctl_event(struct domain *d,
 
 default:
 /*
- * Should not be reached unless vm_event_monitor_get_capabilities() is
+ * Should not be reached unless arch_monitor_get_capabilities() is
  * not properly implemented.
  */
 ASSERT_UNREACHABLE();
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index d950a7c..7c3d1c8 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
@@ -48,12 +47,12 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 if ( unlikely(mop->event > 31) )
 return -EINVAL;
 /* Check if event type is available. */
-if ( unlikely(!(vm_event_monitor_get_capabilities(d) & (1U << 
mop->event))) )
+if ( unlikely(!(arch_monitor_get_capabilities(d) & (1U << 
mop->event))) )
 return -EOPNOTSUPP;
 break;
 
 case XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES:
-mop->event = vm_event_monitor_get_capabilities(d);
+mop->event = arch_monitor_get_capabilities(d);
 return 0;
 
 default:
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 6e36e99..3fd3c9d 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -39,11 +39,20 @@ int arch_monitor_domctl_event(struct domain *d,
 /*
  * No arch-specific monitor vm-events on ARM.
  *
- * Should not be reached unless vm_event_monitor_get_capabilities() is not
+ * Should not be reached unless arch_monitor_get_capabilities() is not
  * properly implemented.
  */
 ASSERT_UNREACHABLE();
 return -EOPNOTSUPP;
 }
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+return capabilities;
+}
+
 #endif /* __ASM_ARM_MONITOR_H__ */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 014d9ba..a3fc4ce 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -59,13 +59,4 @@ static inline void vm_event_fill_regs(vm_event_request_t 
*req)
 /* Not supported on ARM. */
 }
 
-static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
-{
-uint32_t capabilities = 0;
-
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
-
-return capabilities;
-}
-
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 0954b59..446b2af 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -50,4 +50,27 @@ int arch_monitor_domctl_op(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 int arch_monitor_domctl_event(struct domain *d,
   struct xen_domctl_monitor_op *mop);
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+/*
+ * At the moment only Intel HVM domains are supported. However, event
+ * delivery could be extended to AMD and PV domains.
+ */
+if ( !is_hvm_domain(d) || !cpu_has_vmx )
+return capabilities;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+
+return capabilities;
+}
+
 #endif /* __ASM_X86_MONITOR_H__ 

[Xen-devel] [PATCH v2 4/5] x86/hvm: Add debug exception vm_events

[Tamas K Lengyel]

Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
a hook for vm_event subscribers to tap into this new always-on guest event. We
rename along the way hvm_event_breakpoint_type to hvm_event_type to better
match the various events that can be passed with it. We also introduce the
necessary monitor_op domctl's to enable subscribing to the events.

Signed-off-by: Tamas K Lengyel 
---
Cc: Razvan Cojocaru 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2: Rename hvm_monitor_event to hvm_monitor_debug
---
 tools/libxc/include/xenctrl.h   |  3 +-
 tools/libxc/xc_monitor.c| 15 +
 tools/tests/xen-access/xen-access.c | 61 -
 xen/arch/x86/hvm/monitor.c  | 26 ++--
 xen/arch/x86/hvm/vmx/vmx.c  | 26 +---
 xen/arch/x86/monitor.c  | 16 ++
 xen/include/asm-x86/domain.h|  2 ++
 xen/include/asm-x86/hvm/monitor.h   |  7 +++--
 xen/include/asm-x86/monitor.h   |  3 +-
 xen/include/public/domctl.h |  6 
 xen/include/public/vm_event.h   | 12 +++-
 11 files changed, 156 insertions(+), 21 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4b75ae4..ff3ba9e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2162,7 +2162,8 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
  bool enable, bool sync);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
-
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 072df70..e9b0343 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -171,6 +171,21 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION;
+domctl.u.monitor_op.u.debug_exception.sync = sync;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 33e8044..ae235e2 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -53,6 +53,10 @@
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
 #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
 
+/* From xen/include/asm-x86/processor.h */
+#define X86_TRAP_DEBUG  1
+#define X86_TRAP_INT3   3
+
 typedef struct vm_event {
 domid_t domain_id;
 xenevtchn_handle *xce_handle;
@@ -333,7 +337,7 @@ void usage(char* progname)
 {
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
-fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec");
+fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
 #elif defined(__arm__) || defined(__aarch64__)
 fprintf(stderr, "|privcall");
 #endif
@@ -356,11 +360,13 @@ int main(int argc, char *argv[])
 xc_interface *xch;
 xenmem_access_t default_access = XENMEM_access_rwx;
 xenmem_access_t after_first_access = XENMEM_access_rwx;
+int memaccess = 0;
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
 int privcall = 0;
 int altp2m = 0;
+int debug = 0;
 uint16_t altp2m_view_id = 0;
 
 char* progname = argv[0];
@@ -394,11 +400,13 @@ int main(int argc, char *argv[])
 {
 default_access = XENMEM_access_rx;
 after_first_access = XENMEM_access_rwx;
+memaccess = 1;
 }
 else if ( !strcmp(argv[0], "exec") )
 {
 default_access = XENMEM_access_rw;
 after_first_access = XENMEM_access_rwx;
+memaccess = 1;
 }
 #if defined(__i386__) || defined(__x86_64__)
 else if ( !strcmp(argv[0], "breakpoint") )
@@ -409,11 +417,17 @@ int main(int argc, char *argv[])
 {
 default_access = XENMEM_access_rx;
 altp2m = 1;
+memaccess = 1;
 }
 else if ( !strcmp(argv[0], "altp2m_exec") )
 {
 default_access = XENMEM_access_rw;
 altp2m = 1;
+   

[Xen-devel] [PATCH v2 5/5] MAINTAINERS: Update monitor/vm_event covered code

[Tamas K Lengyel]

Add headers to the covered list.

Signed-off-by: Tamas K Lengyel 
---
Cc: Razvan Cojocaru 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 MAINTAINERS | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0c050a5..cbf2234 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -351,13 +351,16 @@ S:Supported
 T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg
 F: drivers/xen/usb*/
 
-VM EVENT AND MEM ACCESS
+VM EVENT, MEM ACCESS and MONITOR
 M: Razvan Cojocaru 
 M: Tamas K Lengyel 
 S: Supported
 F: xen/*/vm_event.c
 F: xen/*/monitor.c
 F: xen/common/mem_access.c
+F: xen/include/*/mem_access.h
+F: xen/include/*/monitor.h
+F: xen/include/*/vm_event.h
 F: tools/tests/xen-access
 
 VTPM
-- 
2.8.1


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

[Xen-devel] [PATCH v3] altp2m: Allow the hostp2m to be shared

[Tamas K Lengyel]

Don't propagate altp2m changes from ept_set_entry for memshare as memshare
already has the lock. We call altp2m propagate changes once memshare
successfully finishes. Allow the hostp2m entries to be of type
p2m_ram_shared when applying mem_access. Also, do not trigger PoD for hostp2m
when setting altp2m mem_access to be in-line with non-altp2m mem_access path.

Signed-off-by: Tamas K Lengyel 
---
Cc: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v3: Add comment to the unshare routine pointing out where altp2m gets updated
v2: Cosmetic fixes and addressing PoD in the commit message
---
 xen/arch/x86/mm/mem_sharing.c | 11 ++-
 xen/arch/x86/mm/p2m-ept.c |  2 +-
 xen/arch/x86/mm/p2m.c |  5 ++---
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a522423..b6c7e33 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mm-locks.h"
@@ -926,11 +927,12 @@ int mem_sharing_share_pages(struct domain *sd, unsigned 
long sgfn, shr_handle_t
 int ret = -EINVAL;
 mfn_t smfn, cmfn;
 p2m_type_t smfn_type, cmfn_type;
+p2m_access_t cmfn_a;
 struct two_gfns tg;
 struct rmap_iterator ri;
 
 get_two_gfns(sd, sgfn, _type, NULL, ,
- cd, cgfn, _type, NULL, ,
+ cd, cgfn, _type, _a, ,
  0, );
 
 /* This tricky business is to avoid two callers deadlocking if 
@@ -1026,6 +1028,12 @@ int mem_sharing_share_pages(struct domain *sd, unsigned 
long sgfn, shr_handle_t
 /* We managed to free a domain page. */
 atomic_dec(_shared_mfns);
 atomic_inc(_saved_mfns);
+
+/* Save the change to the altp2m tables as well if active */
+if ( altp2m_active(cd) )
+p2m_altp2m_propagate_change(cd, _gfn(cgfn), smfn, PAGE_ORDER_4K,
+p2m_ram_shared, cmfn_a);
+
 ret = 0;
 
 err_out:
@@ -1222,6 +1230,7 @@ int __mem_sharing_unshare_page(struct domain *d,
 put_page_and_type(old_page);
 
 private_page_found:
+/* The following will also update the altp2m tables (if any) */
 if ( p2m_change_type_one(d, gfn, p2m_ram_shared, p2m_ram_rw) )
 {
 gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 1ed5b47..ff84242 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -847,7 +847,7 @@ out:
 if ( is_epte_present(_entry) )
 ept_free_entry(p2m, _entry, target);
 
-if ( rc == 0 && p2m_is_hostp2m(p2m) )
+if ( rc == 0 && p2m_is_hostp2m(p2m) && p2mt != p2m_ram_shared )
 p2m_altp2m_propagate_change(d, _gfn(gfn), mfn, order, p2mt, p2ma);
 
 return rc;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6eef2f3..2a42b91 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1765,11 +1765,10 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
p2m_domain *hp2m,
 /* Check host p2m if no valid entry in alternate */
 if ( !mfn_valid(mfn) )
 {
-mfn = hp2m->get_entry(hp2m, gfn_l, , _a,
-  P2M_ALLOC | P2M_UNSHARE, _order, NULL);
+mfn = hp2m->get_entry(hp2m, gfn_l, , _a, 0, _order, NULL);
 
 rc = -ESRCH;
-if ( !mfn_valid(mfn) || t != p2m_ram_rw )
+if ( !mfn_valid(mfn) || (t != p2m_ram_rw && t != p2m_ram_shared) )
 return rc;
 
 /* If this is a superpage, copy that first */
-- 
2.8.1


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

Re: [Xen-devel] [PATCH for-4.7] mkelf32: fix compilation on 32 bit build host

[Wei Liu]

On Fri, Apr 29, 2016 at 01:26:39PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 06:25:31PM +0100, Wei Liu wrote:
> > When cross-compiling xen on a 32 bit build host:
> > 
> > boot/mkelf32.c: In function 'main':
> > boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long 
> > int', but argument 3 has type 'Elf64_Off' [-Werror=format]
> > cc1: all warnings being treated as errors
> > 
> > Fix that by using PRId64 in format string.
> > 
> > Signed-off-by: Wei Liu 
> 
> Tested-by: Konrad Rzeszutek Wilk 
> 
> and Reviewed-by too if you want that.

Release-acked-by: Wei Liu 

(Feel a bit silly to do this to my own patch)

Please push it when convenient.

> > ---
> >  xen/arch/x86/boot/mkelf32.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
> > index 8c51990..6cfa312 100644
> > --- a/xen/arch/x86/boot/mkelf32.c
> > +++ b/xen/arch/x86/boot/mkelf32.c
> > @@ -356,7 +356,7 @@ int main(int argc, char **argv)
> >  if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
> >  {
> >  fprintf(stderr, "Expected .note section within .text 
> > section!\n" \
> > -"Offset %ld not within %d!\n",
> > +"Offset %"PRId64" not within %d!\n",
> >  in64_phdr.p_offset, dat_siz);
> >  return 1;
> >  }
> > -- 
> > 2.1.4
> > 

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

Re: [Xen-devel] [PATCH for-4.7] mkelf32: fix compilation on 32 bit build host

[Konrad Rzeszutek Wilk]

On Fri, Apr 29, 2016 at 06:25:31PM +0100, Wei Liu wrote:
> When cross-compiling xen on a 32 bit build host:
> 
> boot/mkelf32.c: In function 'main':
> boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long 
> int', but argument 3 has type 'Elf64_Off' [-Werror=format]
> cc1: all warnings being treated as errors
> 
> Fix that by using PRId64 in format string.
> 
> Signed-off-by: Wei Liu 

Tested-by: Konrad Rzeszutek Wilk 

and Reviewed-by too if you want that.
> ---
>  xen/arch/x86/boot/mkelf32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
> index 8c51990..6cfa312 100644
> --- a/xen/arch/x86/boot/mkelf32.c
> +++ b/xen/arch/x86/boot/mkelf32.c
> @@ -356,7 +356,7 @@ int main(int argc, char **argv)
>  if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
>  {
>  fprintf(stderr, "Expected .note section within .text section!\n" 
> \
> -"Offset %ld not within %d!\n",
> +"Offset %"PRId64" not within %d!\n",
>  in64_phdr.p_offset, dat_siz);
>  return 1;
>  }
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH for-4.7] mkelf32: fix compilation on 32 bit build host

[Andrew Cooper]

On 29/04/16 18:25, Wei Liu wrote:
> When cross-compiling xen on a 32 bit build host:
>
> boot/mkelf32.c: In function 'main':
> boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long 
> int', but argument 3 has type 'Elf64_Off' [-Werror=format]
> cc1: all warnings being treated as errors
>
> Fix that by using PRId64 in format string.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Konrad Rzeszutek Wilk]

On Fri, Apr 29, 2016 at 07:07:44PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 12:59:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > IMHO, the best way to solve this is to define a set of 
> > > > > XSPLICE_ERROR_* that 
> > > > > covers the error codes returned by xsplice, and use that instead of 
> > > > > XEN_* 
> > > > > errno values. This would make it much more easier to avoid mistakes 
> > > > > when 
> > > > > coding the toolstack part of xsplice.
> > > > 
> > > > But why?
> > > > 
> > > > I must be missing something here - but the return from the hypercall
> > > > can return say 0 but the status->rc can be -XEN_EAGAIN.
> > > > 
> > > > Why does it need to be XSPLICE_ERROR_?
> > > 
> > > Because nobody uses or enforces the correct usage of XEN_E* in the tools, 
> > > so 
> > > people just use native error codes, which works on Linux, but breaks on 
> > > other OSes.
> > 
> > That was an oversigh on my part. I think changing the error code handling
> > in xen-xsplice to look for XEN_EXX is the right way.
> > 
> > But are you saying the BSD does not enforce the POSIX errors? errno.h is 
> > POSIX right?
> 
> Yes, BSD uses POSIX error codes just as Linux, the issue is that the values 
> differ. For example on Xen and Linux EAGAIN is 11, on FreeBSD EAGAIN is 35.

Wow! That is messed up. And would explain the odd errors you had seen.

But if the xen-xsplice would use XEN_EXX error handling this would work for you 
right?
(Which BTW, thank you for doing!)

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

[Xen-devel] [PATCH for-4.7] mkelf32: fix compilation on 32 bit build host

[Wei Liu]

When cross-compiling xen on a 32 bit build host:

boot/mkelf32.c: In function 'main':
boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long int', 
but argument 3 has type 'Elf64_Off' [-Werror=format]
cc1: all warnings being treated as errors

Fix that by using PRId64 in format string.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/boot/mkelf32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index 8c51990..6cfa312 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -356,7 +356,7 @@ int main(int argc, char **argv)
 if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
 {
 fprintf(stderr, "Expected .note section within .text section!\n" \
-"Offset %ld not within %d!\n",
+"Offset %"PRId64" not within %d!\n",
 in64_phdr.p_offset, dat_siz);
 return 1;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Konrad Rzeszutek Wilk]

On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
> >>> On 27.04.16 at 21:27,  wrote:
> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
> >  /*mem_siz = (u32)in64_phdr.p_memsz;*/
> >  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
> >  
> > +note_sz = note_base = offset = 0;
> > +if ( num_phdrs > 1 )
> > +{
> > +offset = in64_phdr.p_offset;
> > +note_base = in64_phdr.p_vaddr;
> > +
> > +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), SEEK_SET);
> > +do_read(infd, _phdr, sizeof(in64_phdr));
> > +endianadjust_phdr64(_phdr);
> > +
> > +(void)lseek(infd, offset, SEEK_SET);
> > +
> > +note_sz = in64_phdr.p_memsz;
> > +note_base = in64_phdr.p_vaddr - note_base;
> > +
> > +if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
> > +{
> > +fprintf(stderr, "Expected .note section within .text 
> > section!\n" \
> > +"Offset %ld not within %d!\n",
> > +in64_phdr.p_offset, dat_siz);
> 
> This fails to build on a 32-bit build host (which is one of the two
> post-commit, pre-push checks I normally do).

I hadn't realized that it was possible to build an 64-bit hypervisor on 32-bit
GCC toolchain. I've never done that - always built the hypervisor in 64-bit env
and the 32-bit toolstack in 32-bit environment. Then booted it.

Anyhow, Wei beat me on IRC with the patch and will be sending it shortly!

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

Re: [Xen-devel] [PATCH] x86/shadow: account for ioreq server pages before complaining about not found mapping

[Andrew Cooper]

On 29/04/16 18:10, Tim Deegan wrote:
> At 06:39 -0600 on 29 Apr (1461911995), Jan Beulich wrote:
> On 29.04.16 at 14:28,  wrote:
>>> It would be nice if we could use gfn_t rather than having more unsigned
>>> longs.
>> I generally agree, but intentionally didn't to match all the other
>> shadow code. I'll make changing this dependent on what Tim
>> thinks.
> Is gfn_t even available here?

Yes.  It is available everywhere since c/s 177bd5fb "mem: expose
typesafe mfns/gfns/pfns to common code"  (I wonder who acked a patch
like that ;p)

~Andrew

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

Re: [Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 12:59:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_* 
> > > > that 
> > > > covers the error codes returned by xsplice, and use that instead of 
> > > > XEN_* 
> > > > errno values. This would make it much more easier to avoid mistakes 
> > > > when 
> > > > coding the toolstack part of xsplice.
> > > 
> > > But why?
> > > 
> > > I must be missing something here - but the return from the hypercall
> > > can return say 0 but the status->rc can be -XEN_EAGAIN.
> > > 
> > > Why does it need to be XSPLICE_ERROR_?
> > 
> > Because nobody uses or enforces the correct usage of XEN_E* in the tools, 
> > so 
> > people just use native error codes, which works on Linux, but breaks on 
> > other OSes.
> 
> That was an oversigh on my part. I think changing the error code handling
> in xen-xsplice to look for XEN_EXX is the right way.
> 
> But are you saying the BSD does not enforce the POSIX errors? errno.h is 
> POSIX right?

Yes, BSD uses POSIX error codes just as Linux, the issue is that the values 
differ. For example on Xen and Linux EAGAIN is 11, on FreeBSD EAGAIN is 35.

Roger.

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

Re: [Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Konrad Rzeszutek Wilk]

> > > IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_* 
> > > that 
> > > covers the error codes returned by xsplice, and use that instead of XEN_* 
> > > errno values. This would make it much more easier to avoid mistakes when 
> > > coding the toolstack part of xsplice.
> > 
> > But why?
> > 
> > I must be missing something here - but the return from the hypercall
> > can return say 0 but the status->rc can be -XEN_EAGAIN.
> > 
> > Why does it need to be XSPLICE_ERROR_?
> 
> Because nobody uses or enforces the correct usage of XEN_E* in the tools, so 
> people just use native error codes, which works on Linux, but breaks on 
> other OSes.

That was an oversigh on my part. I think changing the error code handling
in xen-xsplice to look for XEN_EXX is the right way.

But are you saying the BSD does not enforce the POSIX errors? errno.h is POSIX 
right?

> 
> Using something like XSPLICE_ERROR_* prevents people from having the bad 
> habit of directly using native OS error codes, by making it more obvious 
> that the error code is in a different space.

> 
> Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 18:34,  wrote:
> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 17:06,  wrote:
> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >> >>> On 29.04.16 at 16:21,  wrote:
> >> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> >> > obsolescent (so it may be removed in the future) and optional.
> >> >> 
> >> >> It being optional still doesn't preclude us using it.
> >> >> 
> >> >> > Replace it's
> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD 
> >> >> > and
> >> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> >> 
> >> >> There's no rule saying that Xen's errno set must match any other OS'es.
> >> >> That's one of the reasons why we (finally) separated ours.
> >> > 
> >> > I understand that, but doing this means that then on the toolstack side 
> >> > we 
> >> > need to start doing ifdefery in order to match values that are not 
> >> > present 
> >> > in the native OS. For example a check was added to libxl against 
> >> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
> >> > have to add a:
> >> > 
> >> > #ifdef __FreeBSD__
> >> > #define ENODATA ENOENT
> >> > #endif
> >> 
> >> You ought to be using XEN_NODATA there anyway.
> > 
> > No, the privcmd driver is the one that performs the translation from Xen 
> > error codes into the OS error code space, so the tools just see error codes 
> > in the OS space. No tools at all use XEN_* error codes directly.
> 
> That's the supposed behavior for return values, but not for
> structure contents. The structures are Xen-specific, so them
> holding Xen-specific values is known to the callers, and they
> should (be made) cope.

And the usage of ENODATA I'm trying to fix here is from the direct return of 
an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
just think it would be better to simply replace the usage of ENODATA with 
something else, so I could avoid adding more ifdefery to the tools.

Would you be fine with me just adjusting xen_build_id (in 
xen/common/version.c) to return ENOENT instead of ENODATA?

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 18:34,  wrote:
> On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 17:06,  wrote:
>> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 16:21,  wrote:
>> >> > According to the POSIX standard for error codes [0], ENODATA is both
>> >> > obsolescent (so it may be removed in the future) and optional.
>> >> 
>> >> It being optional still doesn't preclude us using it.
>> >> 
>> >> > Replace it's
>> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
>> >> > OpenBSD don't have this error code in the native errno.h headers.
>> >> 
>> >> There's no rule saying that Xen's errno set must match any other OS'es.
>> >> That's one of the reasons why we (finally) separated ours.
>> > 
>> > I understand that, but doing this means that then on the toolstack side we 
>> > need to start doing ifdefery in order to match values that are not present 
>> > in the native OS. For example a check was added to libxl against 
>> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
>> > have to add a:
>> > 
>> > #ifdef __FreeBSD__
>> > #define ENODATA ENOENT
>> > #endif
>> 
>> You ought to be using XEN_NODATA there anyway.
> 
> No, the privcmd driver is the one that performs the translation from Xen 
> error codes into the OS error code space, so the tools just see error codes 
> in the OS space. No tools at all use XEN_* error codes directly.

That's the supposed behavior for return values, but not for
structure contents. The structures are Xen-specific, so them
holding Xen-specific values is known to the callers, and they
should (be made) cope.

> This is because privcmd does the translation, and because it would be 
> impossible to differentiate if the errno returned by the ioctl belongs to 
> Xen space or to the OS space.

Exactly - I agree for the return values.

Jan


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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Jan Beulich]

>>> On 27.04.16 at 21:27,  wrote:
> @@ -304,6 +338,32 @@ int main(int argc, char **argv)
>  /*mem_siz = (u32)in64_phdr.p_memsz;*/
>  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
>  
> +note_sz = note_base = offset = 0;
> +if ( num_phdrs > 1 )
> +{
> +offset = in64_phdr.p_offset;
> +note_base = in64_phdr.p_vaddr;
> +
> +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), SEEK_SET);
> +do_read(infd, _phdr, sizeof(in64_phdr));
> +endianadjust_phdr64(_phdr);
> +
> +(void)lseek(infd, offset, SEEK_SET);
> +
> +note_sz = in64_phdr.p_memsz;
> +note_base = in64_phdr.p_vaddr - note_base;
> +
> +if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
> +{
> +fprintf(stderr, "Expected .note section within .text section!\n" 
> \
> +"Offset %ld not within %d!\n",
> +in64_phdr.p_offset, dat_siz);

This fails to build on a 32-bit build host (which is one of the two
post-commit, pre-push checks I normally do).

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 17:06,  wrote:
> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 16:21,  wrote:
> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> > obsolescent (so it may be removed in the future) and optional.
> >> 
> >> It being optional still doesn't preclude us using it.
> >> 
> >> > Replace it's
> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> 
> >> There's no rule saying that Xen's errno set must match any other OS'es.
> >> That's one of the reasons why we (finally) separated ours.
> > 
> > I understand that, but doing this means that then on the toolstack side we 
> > need to start doing ifdefery in order to match values that are not present 
> > in the native OS. For example a check was added to libxl against 
> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
> > have to add a:
> > 
> > #ifdef __FreeBSD__
> > #define ENODATA ENOENT
> > #endif
> 
> You ought to be using XEN_NODATA there anyway.

No, the privcmd driver is the one that performs the translation from Xen 
error codes into the OS error code space, so the tools just see error codes 
in the OS space. No tools at all use XEN_* error codes directly.

This is because privcmd does the translation, and because it would be 
impossible to differentiate if the errno returned by the ioctl belongs to 
Xen space or to the OS space.

Roger.

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

Re: [Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 12:22:32PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 06:16:19PM +0200, Roger Pau Monne wrote:
> > On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> > > On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > > > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > > > > I have a gut feeling that returning XEN_ errno to userspace program is
> > > > > layering violation. They should always be translated to OS level errno
> > > > > by privcmd driver.
> > > > 
> > > > Yes, the error value returned from the hypercall executed is indeed 
> > > > translated into the native OS error space. The problem here is that 
> > > > those 
> > > > error codes are returned _inside_ of the specific hypercall struct, 
> > > > which 
> > > > sadly privcmd doesn't know anything about.
> > > > 
> > > > And of course teaching privcmd about every possible hypercall struct is 
> > > > simply impossible, since some of them are not stable (eg: domctls)
> > > >  
> > > > > Aren't FreeBSD and NetBSD already doing that?
> > > > 
> > > > As said above, this is only done for direct return codes, everything 
> > > > inside 
> > > > of the struct passed to the hypercall is returned as-is.
> > > > 
> > > > This is a complete mess, and TBH, I don't have a clever idea about how 
> > > > to 
> > > > solve it.
> > > > 
> > > 
> > > Me neither. Maybe a new thread should be started to discuss this.
> > 
> > So here we are.
> > 
> > In order to put everyone into context: the issue here is that some 
> > hypercalls (those that batch several operations) return an array of error 
> > codes inside of the hypercall structure. This array of error codes is not 
> > standardized, so the privcmd driver doesn't know anything about it, and 
> > thus 
> > cannot translate it into the native OS error space.
> > 
> > It has also been suggested that the privcmd driver simply doesn't translate 
> > error codes at all, and then let the applications figure out if the error 
> > code comes from Xen or from the OS. IMHO, this is impossible to achieve, 
> > because the ioctl syscall can return an error code that's been forwarded 
> > by Xen or a native one, and the application has no way of knowing where is 
> > it coming from.
> > 
> > I've identified at least the following hypercall structs that store XEN_* 
> > error codes inside:
> > 
> >  - xen_add_to_physmap_batch
> >  - xen_xsplice_status
> > 
> > TBH, it's quite hard to spot them, so I might have missed some. 
> > 
> > xen_add_to_physmap_batch is part of the public ABI, and cannot be changed. 
> > On the bright side, xen_add_to_physmap_batch is implemented as a different 
> > ioctl in privcmd usually (in order to map memory from other domains), so 
> > the 
> > error translation should be handled correctly.
> > 
> > Then the xsplice struct that uses XEN_* values is:
> > 
> > struct xen_xsplice_status {
> > #define XSPLICE_STATE_CHECKED  1
> > #define XSPLICE_STATE_APPLIED  2
> > uint32_t state;/* OUT: XSPLICE_STATE_*. */
> > int32_t rc;/* OUT: 0 if no error, otherwise 
> > -XEN_EXX. */
> > };
> > 
> > Which is in turn used by:
> > 
> > struct xen_sysctl_xsplice_list {
> > uint32_t version;   /* OUT: Hypervisor stamps value.
> >If varies between calls, we 
> > are
> >  * getting stale data. */
> > uint32_t idx;   /* IN: Index into hypervisor 
> > list. */
> > uint32_t nr;/* IN: How many status, name, 
> > and len
> >should fill out. Can be zero 
> > to get
> >amount of payloads and 
> > version.
> >OUT: How many payloads left. 
> > */
> > uint32_t pad;   /* IN: Must be zero. */
> > XEN_GUEST_HANDLE_64(xen_xsplice_status_t) status;  /* OUT. Must have 
> > enough
> >space allocate for nr of 
> > them. */
> > XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each 
> > member
> >MUST XEN_XSPLICE_NAME_SIZE 
> > in size.
> >Must have nr of them. */
> > XEN_GUEST_HANDLE_64(uint32) len;/* OUT: Array of lengths of 
> > name's.
> >Must have nr of them. */
> > };
> > 
> > IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_* that 
> > covers the error codes returned by xsplice, and use that instead of XEN_* 
> > errno values. This would make it much more easier to avoid mistakes when 
> > coding the toolstack part of xsplice.
> 
> But why?
> 
> I must be missing something here - but the return from the hypercall
> can 

[Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Jan Beulich]

>>> On 29.04.16 at 18:16,  wrote:
> On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
>> On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
>> > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
>> > > I have a gut feeling that returning XEN_ errno to userspace program is
>> > > layering violation. They should always be translated to OS level errno
>> > > by privcmd driver.
>> > 
>> > Yes, the error value returned from the hypercall executed is indeed 
>> > translated into the native OS error space. The problem here is that those 
>> > error codes are returned _inside_ of the specific hypercall struct, which 
>> > sadly privcmd doesn't know anything about.
>> > 
>> > And of course teaching privcmd about every possible hypercall struct is 
>> > simply impossible, since some of them are not stable (eg: domctls)
>> >  
>> > > Aren't FreeBSD and NetBSD already doing that?
>> > 
>> > As said above, this is only done for direct return codes, everything 
>> > inside 
> 
>> > of the struct passed to the hypercall is returned as-is.
>> > 
>> > This is a complete mess, and TBH, I don't have a clever idea about how to 
>> > solve it.
>> > 
>> 
>> Me neither. Maybe a new thread should be started to discuss this.
> 
> So here we are.
> 
> In order to put everyone into context: the issue here is that some 
> hypercalls (those that batch several operations) return an array of error 
> codes inside of the hypercall structure. This array of error codes is not 
> standardized, so the privcmd driver doesn't know anything about it, and thus 
> cannot translate it into the native OS error space.

I don't see why these would need translation: Anything in a structure
field simply is in XEN_E* space, and the caller can be easily aware.

> It has also been suggested that the privcmd driver simply doesn't translate 
> error codes at all, and then let the applications figure out if the error 
> code comes from Xen or from the OS. IMHO, this is impossible to achieve, 
> because the ioctl syscall can return an error code that's been forwarded 
> by Xen or a native one, and the application has no way of knowing where is 
> it coming from.

But that's a separate issue from that of passing such values in
structure fields.

Jan


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

[Xen-devel] [xen-unstable test] 93001: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start.2fail blocked in 92925
 build-i386-rumpuserxen6 xen-buildfail   like 92925
 build-amd64-rumpuserxen   6 xen-buildfail   like 92925
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92925
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92925
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92925
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92925

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

version targeted for testing:
 xen  981cfa96f183c5a6b62502d6f7d7b5c3b4e1e878
baseline version:
 xen  9772c480a71ad38cc2c342e4c2e78c2475de7268

Last test of basis92925  2016-04-27 04:59:20 Z2 days
Testing same since93001  2016-04-27 18:44:26 Z1 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Ian Jackson 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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-oldkern 

Re: [Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Konrad Rzeszutek Wilk]

On Fri, Apr 29, 2016 at 06:16:19PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > > > I have a gut feeling that returning XEN_ errno to userspace program is
> > > > layering violation. They should always be translated to OS level errno
> > > > by privcmd driver.
> > > 
> > > Yes, the error value returned from the hypercall executed is indeed 
> > > translated into the native OS error space. The problem here is that those 
> > > error codes are returned _inside_ of the specific hypercall struct, which 
> > > sadly privcmd doesn't know anything about.
> > > 
> > > And of course teaching privcmd about every possible hypercall struct is 
> > > simply impossible, since some of them are not stable (eg: domctls)
> > >  
> > > > Aren't FreeBSD and NetBSD already doing that?
> > > 
> > > As said above, this is only done for direct return codes, everything 
> > > inside 
> > > of the struct passed to the hypercall is returned as-is.
> > > 
> > > This is a complete mess, and TBH, I don't have a clever idea about how to 
> > > solve it.
> > > 
> > 
> > Me neither. Maybe a new thread should be started to discuss this.
> 
> So here we are.
> 
> In order to put everyone into context: the issue here is that some 
> hypercalls (those that batch several operations) return an array of error 
> codes inside of the hypercall structure. This array of error codes is not 
> standardized, so the privcmd driver doesn't know anything about it, and thus 
> cannot translate it into the native OS error space.
> 
> It has also been suggested that the privcmd driver simply doesn't translate 
> error codes at all, and then let the applications figure out if the error 
> code comes from Xen or from the OS. IMHO, this is impossible to achieve, 
> because the ioctl syscall can return an error code that's been forwarded 
> by Xen or a native one, and the application has no way of knowing where is 
> it coming from.
> 
> I've identified at least the following hypercall structs that store XEN_* 
> error codes inside:
> 
>  - xen_add_to_physmap_batch
>  - xen_xsplice_status
> 
> TBH, it's quite hard to spot them, so I might have missed some. 
> 
> xen_add_to_physmap_batch is part of the public ABI, and cannot be changed. 
> On the bright side, xen_add_to_physmap_batch is implemented as a different 
> ioctl in privcmd usually (in order to map memory from other domains), so the 
> error translation should be handled correctly.
> 
> Then the xsplice struct that uses XEN_* values is:
> 
> struct xen_xsplice_status {
> #define XSPLICE_STATE_CHECKED  1
> #define XSPLICE_STATE_APPLIED  2
> uint32_t state;/* OUT: XSPLICE_STATE_*. */
> int32_t rc;/* OUT: 0 if no error, otherwise -XEN_EXX. 
> */
> };
> 
> Which is in turn used by:
> 
> struct xen_sysctl_xsplice_list {
> uint32_t version;   /* OUT: Hypervisor stamps value.
>If varies between calls, we are
>  * getting stale data. */
> uint32_t idx;   /* IN: Index into hypervisor 
> list. */
> uint32_t nr;/* IN: How many status, name, and 
> len
>should fill out. Can be zero 
> to get
>amount of payloads and version.
>OUT: How many payloads left. */
> uint32_t pad;   /* IN: Must be zero. */
> XEN_GUEST_HANDLE_64(xen_xsplice_status_t) status;  /* OUT. Must have 
> enough
>space allocate for nr of them. 
> */
> XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each 
> member
>MUST XEN_XSPLICE_NAME_SIZE in 
> size.
>Must have nr of them. */
> XEN_GUEST_HANDLE_64(uint32) len;/* OUT: Array of lengths of 
> name's.
>Must have nr of them. */
> };
> 
> IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_* that 
> covers the error codes returned by xsplice, and use that instead of XEN_* 
> errno values. This would make it much more easier to avoid mistakes when 
> coding the toolstack part of xsplice.

But why?

I must be missing something here - but the return from the hypercall
can return say 0 but the status->rc can be -XEN_EAGAIN.

Why does it need to be XSPLICE_ERROR_?

> 
> Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 17:06,  wrote:
> On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 16:21,  wrote:
>> > According to the POSIX standard for error codes [0], ENODATA is both
>> > obsolescent (so it may be removed in the future) and optional.
>> 
>> It being optional still doesn't preclude us using it.
>> 
>> > Replace it's
>> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
>> > OpenBSD don't have this error code in the native errno.h headers.
>> 
>> There's no rule saying that Xen's errno set must match any other OS'es.
>> That's one of the reasons why we (finally) separated ours.
> 
> I understand that, but doing this means that then on the toolstack side we 
> need to start doing ifdefery in order to match values that are not present 
> in the native OS. For example a check was added to libxl against 
> XENVER_build_id returning ENODATA, this means that then on libxl I would 
> have to add a:
> 
> #ifdef __FreeBSD__
> #define ENODATA ENOENT
> #endif

You ought to be using XEN_NODATA there anyway.

Jan


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

[Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > > I have a gut feeling that returning XEN_ errno to userspace program is
> > > layering violation. They should always be translated to OS level errno
> > > by privcmd driver.
> > 
> > Yes, the error value returned from the hypercall executed is indeed 
> > translated into the native OS error space. The problem here is that those 
> > error codes are returned _inside_ of the specific hypercall struct, which 
> > sadly privcmd doesn't know anything about.
> > 
> > And of course teaching privcmd about every possible hypercall struct is 
> > simply impossible, since some of them are not stable (eg: domctls)
> >  
> > > Aren't FreeBSD and NetBSD already doing that?
> > 
> > As said above, this is only done for direct return codes, everything inside 
> > of the struct passed to the hypercall is returned as-is.
> > 
> > This is a complete mess, and TBH, I don't have a clever idea about how to 
> > solve it.
> > 
> 
> Me neither. Maybe a new thread should be started to discuss this.

So here we are.

In order to put everyone into context: the issue here is that some 
hypercalls (those that batch several operations) return an array of error 
codes inside of the hypercall structure. This array of error codes is not 
standardized, so the privcmd driver doesn't know anything about it, and thus 
cannot translate it into the native OS error space.

It has also been suggested that the privcmd driver simply doesn't translate 
error codes at all, and then let the applications figure out if the error 
code comes from Xen or from the OS. IMHO, this is impossible to achieve, 
because the ioctl syscall can return an error code that's been forwarded 
by Xen or a native one, and the application has no way of knowing where is 
it coming from.

I've identified at least the following hypercall structs that store XEN_* 
error codes inside:

 - xen_add_to_physmap_batch
 - xen_xsplice_status

TBH, it's quite hard to spot them, so I might have missed some. 

xen_add_to_physmap_batch is part of the public ABI, and cannot be changed. 
On the bright side, xen_add_to_physmap_batch is implemented as a different 
ioctl in privcmd usually (in order to map memory from other domains), so the 
error translation should be handled correctly.

Then the xsplice struct that uses XEN_* values is:

struct xen_xsplice_status {
#define XSPLICE_STATE_CHECKED  1
#define XSPLICE_STATE_APPLIED  2
uint32_t state;/* OUT: XSPLICE_STATE_*. */
int32_t rc;/* OUT: 0 if no error, otherwise -XEN_EXX. */
};

Which is in turn used by:

struct xen_sysctl_xsplice_list {
uint32_t version;   /* OUT: Hypervisor stamps value.
   If varies between calls, we are
 * getting stale data. */
uint32_t idx;   /* IN: Index into hypervisor list. 
*/
uint32_t nr;/* IN: How many status, name, and 
len
   should fill out. Can be zero to 
get
   amount of payloads and version.
   OUT: How many payloads left. */
uint32_t pad;   /* IN: Must be zero. */
XEN_GUEST_HANDLE_64(xen_xsplice_status_t) status;  /* OUT. Must have enough
   space allocate for nr of them. */
XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each member
   MUST XEN_XSPLICE_NAME_SIZE in 
size.
   Must have nr of them. */
XEN_GUEST_HANDLE_64(uint32) len;/* OUT: Array of lengths of name's.
   Must have nr of them. */
};

IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_* that 
covers the error codes returned by xsplice, and use that instead of XEN_* 
errno values. This would make it much more easier to avoid mistakes when 
coding the toolstack part of xsplice.

Roger.

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

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

[osstest service owner]

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

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-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail 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-pair  22 guest-migrate/dst_host/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-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 17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 14 guest-saverestorefail blocked in 59254
 test-amd64-amd64-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

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

version targeted for testing:
 linuxbcc981e9ed84c678533299d7eff17d2c81e4d5de
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  295 days
Failing since 59348  2015-07-10 04:24:05 Z  294 days  216 attempts
Testing same since92798  2016-04-26 04:35:29 Z3 days1 attempts


4921 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   pass
 build-amd64-libvirt  pass  

Re: [Xen-devel] [PATCH V3] x86/monitor: Disallow setting mem_access_emulate_each_rep when vm_event is NULL

[Razvan Cojocaru]

On 04/09/16 08:54, Razvan Cojocaru wrote:
> It is meaningless (and potentially dangerous - see 
> hvmemul_virtual_to_linear())
> to set mem_access_emulate_each_rep before xc_monitor_enable() (which allocates
> vcpu->arch.vm_event) has been called, so return an error from the
> XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP hypercall when that is the case.
> 
> Signed-off-by: Razvan Cojocaru 
> Reviewed-by: Andrew Cooper 
> 
> ---
> Changes since V2:
>  - Updated the if() condition as recommended by Andrew Cooper.
>  - Added Andrew Cooper's Reviewed-by.
> ---
>  xen/include/asm-x86/monitor.h | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 0954b59..d367099 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -32,19 +32,29 @@
>  static inline
>  int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op 
> *mop)
>  {
> +int rc = 0;
> +
>  switch ( mop->op )
>  {
>  case XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP:
>  domain_pause(d);
> -d->arch.mem_access_emulate_each_rep = !!mop->event;
> +/*
> + * Enabling mem_access_emulate_each_rep without a vm_event subscriber
> + * is meaningless.
> + */
> +if ( d->max_vcpus && d->vcpu[0] && d->vcpu[0]->arch.vm_event )
> +d->arch.mem_access_emulate_each_rep = !!mop->event;
> +else
> +rc = -EINVAL;
> +
>  domain_unpause(d);
>  break;
>  
>  default:
> -return -EOPNOTSUPP;
> +rc = -EOPNOTSUPP;
>  }
>  
> -return 0;
> +return rc;
>  }
>  
>  int arch_monitor_domctl_event(struct domain *d,

Hello,

According to the previous list discussion with Andrew Cooper, this fix
might be considered for the 4.7 release, so CC-ing Wei for a release
ack, as suggested.


Thanks,
Razvan

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

Re: [Xen-devel] Patch ping

[Andrew Cooper]

On 29/04/16 17:03, Razvan Cojocaru wrote:
> Hello,
>
> Just for my internal patch book-keeping, I assume this patch did not get
> into staging because of the code freeze and is planned for 4.8?
>
> http://lists.xen.org/archives/html/xen-devel/2016-04/msg01444.html

That fix should go into 4.7, but you need to CC Wei to get a release ack.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 92767
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92767
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92767

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

version targeted for testing:
 qemuu61861eff69279e20428c10be269ce1c1bba2c7b1
baseline version:
 qemuuf419a626c76bcb26697883af702862e8623056f9

Last test of basis92767  2016-04-25 23:46:54 Z3 days
Testing same since93078  2016-04-28 10:22:28 Z1 days1 attempts


People who touched revisions under test:
  David Gibson 
  Michael Roth 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 

[Xen-devel] Patch ping

[Razvan Cojocaru]

Hello,

Just for my internal patch book-keeping, I assume this patch did not get
into staging because of the code freeze and is planned for 4.8?

http://lists.xen.org/archives/html/xen-devel/2016-04/msg01444.html


Thanks,
Razvan

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

[Xen-devel] [linux-3.4 test] 92983: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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-intel 11 guest-start  fail  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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4
baseline version:
 linux3389604d77540abf738b486d650c1745b2d663ca

Last test of basis86898  2016-03-22 08:18:28 Z   38 days
Testing same since92983  2016-04-27 16:21:44 Z1 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexander Duyck 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Lutomirski  kernel.org>
  Andy Lutomirski 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Ben Skeggs 
  Bjorn Helgaas 
  Bob Copeland 
  Borislav Petkov 
  Cathy Avery 
  Charles Keepax 
  Christian Zander 
  Christoph Biedl 
  Christoph Hellwig 
  Christophe Leroy 
  Chuck Lever 
  Dan Carpenter 
  Dave Airlie 
  David Daney 
  David Härdeman 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Felix Fietkau 
  G. Richard Bellamy 
  Geert Uytterhoeven 
  Grant Likely 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  H. Nikolaus Schaller 
  Herbert Xu 
  Hin-Tak Leung 
  Ilia Mirkin 
  Ingo Molnar 
  J. Bruce Fields 
  James Bottomley 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jeffery Miller 
  Jens Axboe 
  Jesse Jones 
  Joe Thornber 
  Joerg Roedel 
  Johan Hovold 
  Johannes Berg 
  John Stultz 
  Joseph Qi 
  Kalle Valo 
  Kamal Mostafa  canonical.com>
  Kees Cook 
  Konrad Rzeszutek Wilk 
  Kosuke Tatsukawa 
  Laura Abbott 
  Linus Torvalds 
  Luca Coelho 
  Malcolm Crossley 
  Mark Brown 
  Mark Rustad 
  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build 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  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host 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-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684
 test-amd64-i386-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-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail 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-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux9eb35194e25243660e6475783ed15ac88fd9d480
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  260 days
Failing since 60712  2015-08-15 18:33:48 Z  257 days  198 attempts
Testing same since93049  2016-04-28 04:31:39 Z1 days1 attempts

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

Re: [Xen-devel] [PATCH 0/2] x86: fix memory leaks

[Wei Liu]

On Fri, Apr 29, 2016 at 08:41:14AM -0600, Jan Beulich wrote:
> 1: p2m: clean up altp2m
> 2: fix domain cleanup
> 
> Signed-off-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Stefano Stabellini]

On Fri, 29 Apr 2016, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Matt Fleming wrote:
> > On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > > Also, it would be nice to have all things EFI in a single tree, the 
> > > > conflicts are 
> > > > going to be painful! There's very little reason not to carry this kind 
> > > > of commit:
> > > > 
> > > >  arch/arm/xen/enlighten.c   |  6 +
> > > >  drivers/firmware/efi/arm-runtime.c | 17 +-
> > > >  drivers/firmware/efi/efi.c | 45 
> > > > --
> > > >  3 files changed, 56 insertions(+), 12 deletions(-)
> > > > 
> > > > in the EFI tree.
> > > 
> > > That's true. I'll drop this commit from xentip and let Matt pick it up
> > > or request changes as he sees fit.
> > 
> > One small change I think would be sensible to make is to expand
> > EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> > Xen, and in the process, to delete EFI_PARAVIRT.
> > 
> > That should address Ingo's major concern, and also make it much easier
> > to rework the code in a piecemeal fashion.
> > 
> > Could somebody enumerate the things that make Xen (dom0) different on
> > arm* compared with bare metal EFI boot? The list I made for x86 was,
> > 
> >   1. Has no EFI memory map
> >   2. Runtime regions do not need to be mapped
> >   3. Cannot call SetVirtualAddressMap()
> >   4. /sys/firmware/efi/fw_vendor is invisible
> > 
> > The first maps to not setting EFI_MEMMAP, the second to not setting
> > EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> > to efi.flags that should cover everything on x86. Does arm* require
> > anything else?
> 
> Xen on ARM is different, the impact should be limited:
> 
> - there are no BootServices (ExitBootServices has already been called)
> - RuntimeServices go via hypercalls
> 
> The UEFI memory map is still available at an address specified on device
> tree like on native, but the compatibility string is different
> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
> than native.
> 
> That's pretty much it, Shannon please confirm.

This is to say that Xen on ARM might only need EFI_RUNTIME.

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

Re: [Xen-devel] [PATCH 2/2] x86: fix domain cleanup

[Andrew Cooper]

On 29/04/16 15:49, Jan Beulich wrote:
> Free d->arch.cpuids on both the creation error path and during
> destruction.
>
> Don't bypass iommu_domain_destroy().
>
> Move psr_domain_init() up so that hvm_domain_initialise() again is the
> last thing which can fail, and hence doesn't require undoing later on.
>
> Move psr_domain_free() up on the creation error path, so that cleanup
> once again gets done in reverse order of setup.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] ocaml/xc_get_cpu_featureset/arm: Return not implemented on ARM

[Andrew Cooper]

On 29/04/16 15:54, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 02:38:33AM -0400, Konrad Rzeszutek Wilk wrote:
>> . as it is not implemented on it.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk 
>>
>> ---
>> v1: Initial botched patch that didn't compile.
>> v2: Andrew mentioned to "need to set ENOSYS in the xch last
>> error." - but we do not use 'failwith_xc', and:
>>a). The error codes you set are no EXX type.
>>b). The best I can do is set errno=ENOSYS; Is that what you would 
>> like?
>>
> As far as I can tell this change follows existing pattern so it's
> probably fine. But I will wait until some ocaml experts chime in.

This appears to be the prevailing pattern.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Wei Liu]

On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> > > Avoid using system errno values when comparing with Xen errno values.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: Ross Lagerwall 
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > ---
> > > Using errno values inside of hypercall structs is not right IMHO, but 
> > > there
> > > are already several occurrences of this. Although I'm adding the correct 
> > > XEN_
> > > prefixes here, it's very likely that new additions/modifications to this
> > > file will not take this into account, breaking it for OSes != Linux.
> > 
> > This seems to be a rather thorny issue.
> > 
> > I have a gut feeling that returning XEN_ errno to userspace program is
> > layering violation. They should always be translated to OS level errno
> > by privcmd driver.
> 
> Yes, the error value returned from the hypercall executed is indeed 
> translated into the native OS error space. The problem here is that those 
> error codes are returned _inside_ of the specific hypercall struct, which 
> sadly privcmd doesn't know anything about.
> 
> And of course teaching privcmd about every possible hypercall struct is 
> simply impossible, since some of them are not stable (eg: domctls)
>  
> > Aren't FreeBSD and NetBSD already doing that?
> 
> As said above, this is only done for direct return codes, everything inside 
> of the struct passed to the hypercall is returned as-is.
> 
> This is a complete mess, and TBH, I don't have a clever idea about how to 
> solve it.
> 

Me neither. Maybe a new thread should be started to discuss this.

Wei.

> Roger.

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

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Wei Liu]

On Fri, Apr 29, 2016 at 04:11:47PM +0100, Andrew Cooper wrote:
> On 29/04/16 16:02, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> >> Avoid using system errno values when comparing with Xen errno values.
> >>
> >> Signed-off-by: Roger Pau Monné 
> >> ---
> >> Cc: Konrad Rzeszutek Wilk 
> >> Cc: Ross Lagerwall 
> >> Cc: Ian Jackson 
> >> Cc: Wei Liu 
> >> ---
> >> Using errno values inside of hypercall structs is not right IMHO, but there
> >> are already several occurrences of this. Although I'm adding the correct 
> >> XEN_
> >> prefixes here, it's very likely that new additions/modifications to this
> >> file will not take this into account, breaking it for OSes != Linux.
> > This seems to be a rather thorny issue.
> >
> > I have a gut feeling that returning XEN_ errno to userspace program is
> > layering violation. They should always be translated to OS level errno
> > by privcmd driver.
> >
> > Aren't FreeBSD and NetBSD already doing that?
> 
> It is not practical for the privcmd driver to do this translation, as
> most hypercalls through the privcmd driver are toolstack calls, and have
> an unstable layout.
> 

If what you mean is what Roger said in his other reply then I agree
translating in privcmd is not doable.

> Another thorny issue is that the ioctl() call for privcmd returns errors
> via errno, which may be in system errno space, or xen errno space
> depending on the source of the errno.
> 
> This is very large swamp in desperate need of some attention.
> 

Indeed.

Wei.

> ~Andrew

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

[Xen-devel] [PATCH 1/2] x86/p2m: clean up altp2m

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -618,9 +618,11 @@ void p2m_teardown(struct p2m_domain *p2m
 
 void p2m_final_teardown(struct domain *d)
 {
-/* We must teardown unconditionally because
+/*
+ * We must teardown both of them unconditionally because
  * we initialise them unconditionally.
  */
+p2m_teardown_altp2m(d);
 p2m_teardown_nestedp2m(d);
 
 /* Iterate over all p2m tables per domain */



x86/p2m: clean up altp2m

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -618,9 +618,11 @@ void p2m_teardown(struct p2m_domain *p2m
 
 void p2m_final_teardown(struct domain *d)
 {
-/* We must teardown unconditionally because
+/*
+ * We must teardown both of them unconditionally because
  * we initialise them unconditionally.
  */
+p2m_teardown_altp2m(d);
 p2m_teardown_nestedp2m(d);
 
 /* Iterate over all p2m tables per domain */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 91479
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
91479
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 91479

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

version targeted for testing:
 libvirt  cdbbb93a968bdf297c0aa47a3f161ffd76136dca
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z   14 days
Failing since 91597  2016-04-16 04:20:46 Z   13 days   12 attempts
Testing same since93129  2016-04-28 20:01:55 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Dmitry Andreev 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Simon Arlott 

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   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt

Re: [Xen-devel] [PATCH for-4.7 4/4] xen/xsplice: remove OSABI check when loading a payload

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 08:48:39AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 16:21,  wrote:
> > FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
> > still be loaded without issues.
> > 
> > All the ELF OS ABIs follow the System V calling convention, and the OS ABI
> > doesn't really matter because Xen is a standalone kernel.
> 
> Well, first of all our name is wrong. The correct one is
> ELFOSABI_NONE, as I did also write in one of the xSplice patch
> reviews. And this _is_ the correct thing to expect here, as other
> settings may imply behavioral changes. If other ABIs are also
> fine, they can be added, but we can't ignore that field.

Thanks for the review. I'm going to change it to ELFOSABI_NONE and then 
add ELFOSABI_FREEBSD as a supported OSABI also.

Roger.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 92143

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 92143
 build-i386-rumpuserxen6 xen-buildfail   like 92143
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail   like 92143
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeatfail like 92143
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 92143
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92143
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92143
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92143
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92143
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 92143
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 92143

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux54419e3efcd6677e4b0841666e2fc605d2e5df86
baseline version:
 linux6fe78bc1bfcddabbf3d210e18f91da44fa796d8a

Last test of basis92143  2016-04-20 07:33:07 Z9 days
Testing same since93111  2016-04-28 16:51:58 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Andrew Morton 
  Andy Shevchenko 
  Bjørn Mork 
  Boris Ostrovsky 
  Chris Mason 
  Daniel Fraga 
  Daniel Vetter 
  David Disseldorp 
  David Howells 
  David Matlack 
  David S. Miller 
  David Vrabel 
  Dennis Kadioglu 
  Eric Dumazet 
  Felipe Balbi 
  Filipe Manana 
  Greg Kroah-Hartman 
  Hans de Goede 
  Helge Deller 
  Hui Wang 

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> > Avoid using system errno values when comparing with Xen errno values.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Ross Lagerwall 
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> > Using errno values inside of hypercall structs is not right IMHO, but there
> > are already several occurrences of this. Although I'm adding the correct 
> > XEN_
> > prefixes here, it's very likely that new additions/modifications to this
> > file will not take this into account, breaking it for OSes != Linux.
> 
> This seems to be a rather thorny issue.
> 
> I have a gut feeling that returning XEN_ errno to userspace program is
> layering violation. They should always be translated to OS level errno
> by privcmd driver.

Yes, the error value returned from the hypercall executed is indeed 
translated into the native OS error space. The problem here is that those 
error codes are returned _inside_ of the specific hypercall struct, which 
sadly privcmd doesn't know anything about.

And of course teaching privcmd about every possible hypercall struct is 
simply impossible, since some of them are not stable (eg: domctls)
 
> Aren't FreeBSD and NetBSD already doing that?

As said above, this is only done for direct return codes, everything inside 
of the struct passed to the hypercall is returned as-is.

This is a complete mess, and TBH, I don't have a clever idea about how to 
solve it.

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 4/4] xen/xsplice: remove OSABI check when loading a payload

[Jan Beulich]

>>> On 29.04.16 at 16:21,  wrote:
> FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
> still be loaded without issues.
> 
> All the ELF OS ABIs follow the System V calling convention, and the OS ABI
> doesn't really matter because Xen is a standalone kernel.

Well, first of all our name is wrong. The correct one is
ELFOSABI_NONE, as I did also write in one of the xSplice patch
reviews. And this _is_ the correct thing to expect here, as other
settings may imply behavioral changes. If other ABIs are also
fine, they can be added, but we can't ignore that field.

Jan

> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Konrad Rzeszutek Wilk 
> Cc: Ross Lagerwall 
> ---
>  xen/common/xsplice_elf.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
> index e403a0e..de68d29 100644
> --- a/xen/common/xsplice_elf.c
> +++ b/xen/common/xsplice_elf.c
> @@ -397,7 +397,6 @@ static int xsplice_header_check(const struct xsplice_elf 
> *elf)
>  if ( hdr->e_version != EV_CURRENT ||
>   hdr->e_ident[EI_VERSION] != EV_CURRENT ||
>   hdr->e_ident[EI_ABIVERSION] != 0 ||
> - hdr->e_ident[EI_OSABI] != ELFOSABI_SYSV ||
>   hdr->e_type != ET_REL ||
>   hdr->e_phnum != 0 )
>  {
> -- 
> 2.6.4 (Apple Git-63)
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



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

[Xen-devel] [PATCH for-4.7 3/6] rombios/tcgbios: initialise logdataptr in HashLogEvent32

[Wei Liu]

Gcc complains:

tcgbios.c: In function ‘HashLogEvent32’:
tcgbios.c:1131:10: error: ‘logdataptr’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
entry = tcpa_extend_acpi_log(logdataptr);

It fails to figure out when logdataptr is used it is always initialised
in a if block a few line above.

Signed-off-by: Wei Liu 
---
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c 
b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
index 3501051..fa22c44 100644
--- a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
+++ b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
@@ -1062,7 +1062,7 @@ uint32_t HashLogEvent32(struct hlei *hlei, struct hleo 
*hleo,
 {
uint32_t rc = 0;
uint16_t size;
-   uint32_t logdataptr;
+   uint32_t logdataptr = 0;
uint32_t logdatalen;
uint32_t hashdataptr;
uint32_t hashdatalen;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Andrew Cooper]

On 29/04/16 16:02, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
>> Avoid using system errno values when comparing with Xen errno values.
>>
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Ross Lagerwall 
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> ---
>> Using errno values inside of hypercall structs is not right IMHO, but there
>> are already several occurrences of this. Although I'm adding the correct XEN_
>> prefixes here, it's very likely that new additions/modifications to this
>> file will not take this into account, breaking it for OSes != Linux.
> This seems to be a rather thorny issue.
>
> I have a gut feeling that returning XEN_ errno to userspace program is
> layering violation. They should always be translated to OS level errno
> by privcmd driver.
>
> Aren't FreeBSD and NetBSD already doing that?

It is not practical for the privcmd driver to do this translation, as
most hypercalls through the privcmd driver are toolstack calls, and have
an unstable layout.

Another thorny issue is that the ioctl() call for privcmd returns errors
via errno, which may be in system errno space, or xen errno space
depending on the source of the errno.

This is very large swamp in desperate need of some attention.

~Andrew

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

[Xen-devel] [PATCH for-4.7 2/6] rombios/tcgbios: initialise entry in HashLogEvent32

[Wei Liu]

Gcc complains:

tcgbios.c:1142:22: error: ‘entry’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
hleo->eventnumber = entry;

It fails to figure out if entry is used it is always initialised in
previous if block.

Signed-off-by: Wei Liu 
---
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c 
b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
index d1d1203..3501051 100644
--- a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
+++ b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
@@ -1100,7 +1100,7 @@ uint32_t HashLogEvent32(struct hlei *hlei, struct hleo 
*hleo,
}
 
if (rc == 0) {
-   uint32_t entry;
+   uint32_t entry = 0;
hashdataptr = hlei->hashdataptr;
hashdatalen = hlei->hashdatalen;
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 0/6] Workaround gcc -Wmaybe-uninitialised false positive reports

[Wei Liu]

On my Debian Jessie build box gcc complains about various maybe uninitialised
variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very
reliable according to gcc manpage, various search results and answer from
someone on freenode #gcc channel.

I go through those failures and try to provide some workaround for them.
Please have a look if these fixes make sense or my analysis is correct.

Wei.

Wei Liu (6):
  rombios/tcgbios: initialise size in tcpa_extend_acpi_log
  rombios/tcgbios: initialise entry in HashLogEvent32
  rombios/tcgbios: initialise logdataptr in HashLogEvent32
  blktap2: initialise buf in vhd_util_check_footer
  blktap2: initialise buf to NULL in img2qcow.c:main
  blktap2: initialise buf in qcow2raw.c:main

 tools/blktap2/drivers/img2qcow.c   | 2 +-
 tools/blktap2/drivers/qcow2raw.c   | 2 +-
 tools/blktap2/vhd/lib/vhd-util-check.c | 2 +-
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 5/6] blktap2: initialise buf to NULL in img2qcow.c:main

[Wei Liu]

Gcc complains:

qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
treq.buf = buf;
 ^

But at the point of that assignment, buf is a valid buffer allocated by
posix_memalign and filled in by read.

Signed-off-by: Wei Liu 
---
 tools/blktap2/drivers/img2qcow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/drivers/img2qcow.c b/tools/blktap2/drivers/img2qcow.c
index 57b931e..7376382 100644
--- a/tools/blktap2/drivers/img2qcow.c
+++ b/tools/blktap2/drivers/img2qcow.c
@@ -166,7 +166,7 @@ int main(int argc, const char *argv[])
 int ret = -1, fd, len, err;
struct timeval timeout;
uint64_t i;
-   char *buf;
+   char *buf = NULL;
td_request_t treq;
 td_disk_info_t info;
 td_vbd_request_t* vreq;
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 1/6] rombios/tcgbios: initialise size in tcpa_extend_acpi_log

[Wei Liu]

Gcc complains:

tcgbios.c:362:3: error: ‘size’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
   memcpy((char *)lasa_last, (char *)entry_ptr, size);

It fails to figure out if size is used in memcpy it is always initialised.

Signed-off-by: Wei Liu 
---
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c 
b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
index beef5a4..d1d1203 100644
--- a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
+++ b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
@@ -330,7 +330,7 @@ uint32_t tcpa_extend_acpi_log(uint32_t entry_ptr)
uint32_t res = 0;
unsigned char *lasa_last = tcpa_get_lasa_last_ptr();
unsigned char *lasa_base = tcpa_get_lasa_base_ptr();
-   uint32_t size;
+   uint32_t size = 0;
uint16_t entry_count = tcpa_acpi.entry_count;
struct pcpes *pcpes = (struct pcpes *)entry_ptr;
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 4/6] blktap2: initialise buf in vhd_util_check_footer

[Wei Liu]

Gcc complains:

vhd-util-check.c: In function ‘vhd_util_check_footer’:
vhd-util-check.c:413:2: error: ‘buf’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
  memcpy(, buf, sizeof(backup));

In fact buf is initialised a few lines above.

Signed-off-by: Wei Liu 
---
I can't figure out why buf may be uninitialised and this seems to be the
only way to convince gcc it is ok to proceed.
---
 tools/blktap2/vhd/lib/vhd-util-check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/vhd/lib/vhd-util-check.c 
b/tools/blktap2/vhd/lib/vhd-util-check.c
index af07426..40565ac 100644
--- a/tools/blktap2/vhd/lib/vhd-util-check.c
+++ b/tools/blktap2/vhd/lib/vhd-util-check.c
@@ -335,7 +335,7 @@ vhd_util_check_footer(int fd, vhd_footer_t *footer, int 
ignore)
 {
size_t size;
int err, opened;
-   char *msg, *buf;
+   char *msg, *buf = NULL;
off_t eof, off;
vhd_footer_t primary, backup;
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 6/6] blktap2: initialise buf in qcow2raw.c:main

[Wei Liu]

Gcc complains:

qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
treq.buf = buf;
 ^

But buf is a valid buffer allocated by posix_memalign at that point.

Signed-off-by: Wei Liu 
---
 tools/blktap2/drivers/qcow2raw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/drivers/qcow2raw.c b/tools/blktap2/drivers/qcow2raw.c
index a2e417d..5ad7305 100644
--- a/tools/blktap2/drivers/qcow2raw.c
+++ b/tools/blktap2/drivers/qcow2raw.c
@@ -202,7 +202,7 @@ int main(int argc, const char *argv[])
uint64_t size;
struct timeval timeout;
uint64_t i;
-   char *buf;
+   char *buf = NULL;
struct stat finfo;
td_request_t treq;
td_vbd_request_t* vreq;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.7 2/4] tools/xsplice: corrently use errno

[Wei Liu]

On Fri, Apr 29, 2016 at 05:07:40PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 03:57:23PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> > > Some error paths incorrectly used rc instead of errno.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: Ross Lagerwall 
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > ---
> > >  tools/misc/xen-xsplice.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> > > index 0f1ab5a..695be7f 100644
> > > --- a/tools/misc/xen-xsplice.c
> > > +++ b/tools/misc/xen-xsplice.c
> > > @@ -273,7 +273,7 @@ int action_func(int argc, char *argv[], unsigned int 
> > > idx)
> > >  if ( rc )
> > >  {
> > >  fprintf(stderr, "%s failed to get status (rc=%d, %s)!\n",
> > 
> > I think it is better to also change rc= to errno= here.
> 
> Thanks. Yes, in fact I think I prefer the format used elsewhere in this 
> file, which is:
> 
> %d(%s)
> 

That's fine, too.

Wei.

> Roger.

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

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Wei Liu]

On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> Avoid using system errno values when comparing with Xen errno values.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Konrad Rzeszutek Wilk 
> Cc: Ross Lagerwall 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
> Using errno values inside of hypercall structs is not right IMHO, but there
> are already several occurrences of this. Although I'm adding the correct XEN_
> prefixes here, it's very likely that new additions/modifications to this
> file will not take this into account, breaking it for OSes != Linux.

This seems to be a rather thorny issue.

I have a gut feeling that returning XEN_ errno to userspace program is
layering violation. They should always be translated to OS level errno
by privcmd driver.

Aren't FreeBSD and NetBSD already doing that?

Wei.

> ---
>  tools/misc/xen-xsplice.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> index 695be7f..b31115c 100644
> --- a/tools/misc/xen-xsplice.c
> +++ b/tools/misc/xen-xsplice.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  static xc_interface *xch;
>  
>  void show_help(void)
> @@ -233,7 +235,7 @@ struct {
>  .function = xc_xsplice_revert,
>  },
>  {   .allow = XSPLICE_STATE_CHECKED,
> -.expected = -ENOENT,
> +.expected = -XEN_ENOENT,
>  .name = "unload",
>  .function = xc_xsplice_unload,
>  },
> @@ -276,7 +278,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
>  name, errno, strerror(errno));
>  return -1;
>  }
> -if ( status.rc == -EAGAIN )
> +if ( status.rc == -XEN_EAGAIN )
>  {
>  fprintf(stderr, "%s failed. Operation already in progress\n", name);
>  return -1;
> @@ -319,7 +321,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
>  
>  if ( status.state != original_state )
>  break;
> -if ( status.rc && status.rc != -EAGAIN )
> +if ( status.rc && status.rc != -XEN_EAGAIN )
>  {
>  rc = status.rc;
>  break;
> -- 
> 2.6.4 (Apple Git-63)
> 

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

Re: [Xen-devel] [PATCH for-4.7 2/4] tools/xsplice: corrently use errno

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 03:57:23PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> > Some error paths incorrectly used rc instead of errno.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Ross Lagerwall 
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> >  tools/misc/xen-xsplice.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> > index 0f1ab5a..695be7f 100644
> > --- a/tools/misc/xen-xsplice.c
> > +++ b/tools/misc/xen-xsplice.c
> > @@ -273,7 +273,7 @@ int action_func(int argc, char *argv[], unsigned int 
> > idx)
> >  if ( rc )
> >  {
> >  fprintf(stderr, "%s failed to get status (rc=%d, %s)!\n",
> 
> I think it is better to also change rc= to errno= here.

Thanks. Yes, in fact I think I prefer the format used elsewhere in this 
file, which is:

%d(%s)

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 16:21,  wrote:
> > According to the POSIX standard for error codes [0], ENODATA is both
> > obsolescent (so it may be removed in the future) and optional.
> 
> It being optional still doesn't preclude us using it.
> 
> > Replace it's
> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
> > OpenBSD don't have this error code in the native errno.h headers.
> 
> There's no rule saying that Xen's errno set must match any other OS'es.
> That's one of the reasons why we (finally) separated ours.

I understand that, but doing this means that then on the toolstack side we 
need to start doing ifdefery in order to match values that are not present 
in the native OS. For example a check was added to libxl against 
XENVER_build_id returning ENODATA, this means that then on libxl I would 
have to add a:

#ifdef __FreeBSD__
#define ENODATA ENOENT
#endif

I think this adds more complexity, when we could solve it by only using 
error codes that are part of the POSIX standard, and that are present on all 
UNIX systems.

> > --- a/xen/include/public/errno.h
> > +++ b/xen/include/public/errno.h
> > @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG,   36) /* File name too long */
> >  XEN_ERRNO(ENOLCK,  37) /* No record locks available */
> >  XEN_ERRNO(ENOTEMPTY,   39) /* Directory not empty */
> >  XEN_ERRNO(ENOSYS,  38) /* Function not implemented */
> > -XEN_ERRNO(ENODATA, 61) /* No data available */
> >  XEN_ERRNO(ETIME,   62) /* Timer expired */
> >  XEN_ERRNO(EBADMSG, 74) /* Not a data message */
> >  XEN_ERRNO(EOVERFLOW,   75) /* Value too large for defined data 
> > type */
> 
> And in absolutely no case can you unconditionally remove _anything_
> from other than the tools-only parts of the public interface.

Right, the problem with leaving it there is that I'm quite certain it's 
going to be used again as a return value from a hypercall.

Roger.

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

Re: [Xen-devel] [PATCH] ocaml/xc_get_cpu_featureset/arm: Return not implemented on ARM

[Wei Liu]

On Fri, Apr 29, 2016 at 02:38:33AM -0400, Konrad Rzeszutek Wilk wrote:
> . as it is not implemented on it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> 
> ---
> v1: Initial botched patch that didn't compile.
> v2: Andrew mentioned to "need to set ENOSYS in the xch last
> error." - but we do not use 'failwith_xc', and:
>a). The error codes you set are no EXX type.
>b). The best I can do is set errno=ENOSYS; Is that what you would like?
> 

As far as I can tell this change follows existing pattern so it's
probably fine. But I will wait until some ocaml experts chime in.

> Cc: David Scott 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Andrew Cooper 
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> 
> ---
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index 5477df3..5e45551 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -1218,6 +1218,7 @@ CAMLprim value stub_xc_get_cpu_featureset(value xch, 
> value idx)
>  {
>   CAMLparam2(xch, idx);
>   CAMLlocal1(bitmap_val);
> +#if defined(__i386__) || defined(__x86_64__)
>  
>   /* Safe, because of the global ocaml lock. */
>   static uint32_t fs_len;
> @@ -1245,7 +1246,9 @@ CAMLprim value stub_xc_get_cpu_featureset(value xch, 
> value idx)
>   for (i = 0; i < len; ++i)
>   Store_field(bitmap_val, i, caml_copy_int64(fs[i]));
>   }
> -
> +#else
> + caml_failwith("xc_get_cpu_featureset: not implemented");
> +#endif
>   CAMLreturn(bitmap_val);
>  }
>  
> -- 
> 2.5.0
> 

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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Stefano Stabellini]

On Fri, 29 Apr 2016, Matt Fleming wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > Also, it would be nice to have all things EFI in a single tree, the 
> > > conflicts are 
> > > going to be painful! There's very little reason not to carry this kind of 
> > > commit:
> > > 
> > >  arch/arm/xen/enlighten.c   |  6 +
> > >  drivers/firmware/efi/arm-runtime.c | 17 +-
> > >  drivers/firmware/efi/efi.c | 45 
> > > --
> > >  3 files changed, 56 insertions(+), 12 deletions(-)
> > > 
> > > in the EFI tree.
> > 
> > That's true. I'll drop this commit from xentip and let Matt pick it up
> > or request changes as he sees fit.
> 
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
> 
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
> 
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
> 
>   1. Has no EFI memory map
>   2. Runtime regions do not need to be mapped
>   3. Cannot call SetVirtualAddressMap()
>   4. /sys/firmware/efi/fw_vendor is invisible
> 
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?

Xen on ARM is different, the impact should be limited:

- there are no BootServices (ExitBootServices has already been called)
- RuntimeServices go via hypercalls

The UEFI memory map is still available at an address specified on device
tree like on native, but the compatibility string is different
("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
than native.

That's pretty much it, Shannon please confirm.

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

Re: [Xen-devel] [PATCH for-4.7 2/4] tools/xsplice: corrently use errno

[Wei Liu]

On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> Some error paths incorrectly used rc instead of errno.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Konrad Rzeszutek Wilk 
> Cc: Ross Lagerwall 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/misc/xen-xsplice.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> index 0f1ab5a..695be7f 100644
> --- a/tools/misc/xen-xsplice.c
> +++ b/tools/misc/xen-xsplice.c
> @@ -273,7 +273,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
>  if ( rc )
>  {
>  fprintf(stderr, "%s failed to get status (rc=%d, %s)!\n",

I think it is better to also change rc= to errno= here.

> -name, -rc, strerror(-rc));
> +name, errno, strerror(errno));
>  return -1;
>  }
>  if ( status.rc == -EAGAIN )
> @@ -295,7 +295,8 @@ int action_func(int argc, char *argv[], unsigned int idx)
>  rc = action_options[idx].function(xch, name, 0);
>  if ( rc )
>  {
> -fprintf(stderr, "%s failed with %d(%s)\n", name, -rc, 
> strerror(-rc));
> +fprintf(stderr, "%s failed with %d(%s)\n", name, errno,
> +strerror(errno));
>  return -1;
>  }
>  }
> -- 
> 2.6.4 (Apple Git-63)
> 

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

[Xen-devel] [PATCH 2/2] x86: fix domain cleanup

[Jan Beulich]

Free d->arch.cpuids on both the creation error path and during
destruction.

Don't bypass iommu_domain_destroy().

Move psr_domain_init() up so that hvm_domain_initialise() again is the
last thing which can fail, and hence doesn't require undoing later on.

Move psr_domain_free() up on the creation error path, so that cleanup
once again gets done in reverse order of setup.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -642,21 +642,18 @@ int arch_domain_create(struct domain *d,
 }
 spin_lock_init(>arch.e820_lock);
 
+if ( (rc = psr_domain_init(d)) != 0 )
+goto fail;
+
 if ( has_hvm_container_domain(d) )
 {
 if ( (rc = hvm_domain_initialise(d)) != 0 )
-{
-iommu_domain_destroy(d);
 goto fail;
-}
 }
 else
 /* 64-bit PV guest by default. */
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
 
-if ( (rc = psr_domain_init(d)) != 0 )
-goto fail;
-
 /* initialize default tsc behavior in case tools don't */
 tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
 spin_lock_init(>arch.vtsc_lock);
@@ -674,8 +671,11 @@ int arch_domain_create(struct domain *d,
 
  fail:
 d->is_dying = DOMDYING_dead;
+psr_domain_free(d);
+iommu_domain_destroy(d);
 cleanup_domain_irq_mapping(d);
 free_xenheap_page(d->shared_info);
+xfree(d->arch.cpuids);
 if ( paging_initialised )
 paging_final_teardown(d);
 free_perdomain_mappings(d);
@@ -684,7 +684,6 @@ int arch_domain_create(struct domain *d,
 xfree(d->arch.pv_domain.cpuidmasks);
 free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
 }
-psr_domain_free(d);
 return rc;
 }
 
@@ -694,6 +693,7 @@ void arch_domain_destroy(struct domain *
 hvm_domain_destroy(d);
 
 xfree(d->arch.e820);
+xfree(d->arch.cpuids);
 
 free_domain_pirqs(d);
 if ( !is_idle_domain(d) )



x86: fix domain cleanup

Free d->arch.cpuids on both the creation error path and during
destruction.

Don't bypass iommu_domain_destroy().

Move psr_domain_init() up so that hvm_domain_initialise() again is the
last thing which can fail, and hence doesn't require undoing later on.

Move psr_domain_free() up on the creation error path, so that cleanup
once again gets done in reverse order of setup.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -642,21 +642,18 @@ int arch_domain_create(struct domain *d,
 }
 spin_lock_init(>arch.e820_lock);
 
+if ( (rc = psr_domain_init(d)) != 0 )
+goto fail;
+
 if ( has_hvm_container_domain(d) )
 {
 if ( (rc = hvm_domain_initialise(d)) != 0 )
-{
-iommu_domain_destroy(d);
 goto fail;
-}
 }
 else
 /* 64-bit PV guest by default. */
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
 
-if ( (rc = psr_domain_init(d)) != 0 )
-goto fail;
-
 /* initialize default tsc behavior in case tools don't */
 tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
 spin_lock_init(>arch.vtsc_lock);
@@ -674,8 +671,11 @@ int arch_domain_create(struct domain *d,
 
  fail:
 d->is_dying = DOMDYING_dead;
+psr_domain_free(d);
+iommu_domain_destroy(d);
 cleanup_domain_irq_mapping(d);
 free_xenheap_page(d->shared_info);
+xfree(d->arch.cpuids);
 if ( paging_initialised )
 paging_final_teardown(d);
 free_perdomain_mappings(d);
@@ -684,7 +684,6 @@ int arch_domain_create(struct domain *d,
 xfree(d->arch.pv_domain.cpuidmasks);
 free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
 }
-psr_domain_free(d);
 return rc;
 }
 
@@ -694,6 +693,7 @@ void arch_domain_destroy(struct domain *
 hvm_domain_destroy(d);
 
 xfree(d->arch.e820);
+xfree(d->arch.cpuids);
 
 free_domain_pirqs(d);
 if ( !is_idle_domain(d) )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Ard Biesheuvel]

On 29 April 2016 at 16:39, Matt Fleming  wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>> > Also, it would be nice to have all things EFI in a single tree, the 
>> > conflicts are
>> > going to be painful! There's very little reason not to carry this kind of 
>> > commit:
>> >
>> >  arch/arm/xen/enlighten.c   |  6 +
>> >  drivers/firmware/efi/arm-runtime.c | 17 +-
>> >  drivers/firmware/efi/efi.c | 45 
>> > --
>> >  3 files changed, 56 insertions(+), 12 deletions(-)
>> >
>> > in the EFI tree.
>>
>> That's true. I'll drop this commit from xentip and let Matt pick it up
>> or request changes as he sees fit.
>
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
>
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
>
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
>
>   1. Has no EFI memory map
>   2. Runtime regions do not need to be mapped
>   3. Cannot call SetVirtualAddressMap()
>   4. /sys/firmware/efi/fw_vendor is invisible
>
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?

I already proposed when this patch was first under review to make the
arm_enable_runtime_services() function bail early without error if the
EFI_RUNTIME_SERVICES flag is already set, and the xen code could set
that bit as well when it installs its paravirtualized alternatives. I
don't remember exactly why that was shot down, though, but I think it
is the only reason this code introduces references to EFI_PARAVIRT in
the first place.

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

Re: [Xen-devel] [PATCH 1/2] x86/p2m: clean up altp2m

[Andrew Cooper]

On 29/04/16 15:49, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [linux-3.18 test] 92982: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 92189
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail like 
92139
 build-amd64-rumpuserxen   6 xen-buildfail   like 92189
 build-i386-rumpuserxen6 xen-buildfail   like 92189
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92189
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92189

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

version targeted for testing:
 linux834125557e0a4e5afafee3caf79696078d0820ae
baseline version:
 linuxf151e73cea45b97a5690806f3391d10e547d04d9

Last test of basis92189  2016-04-20 18:48:46 Z8 days
Testing same since92982  2016-04-27 16:21:58 Z1 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Andrew Morton 
  Andy Shevchenko 
  Anssi Hannula 
  Bin Liu 
  Bjørn Mork 
  Boris Ostrovsky 
  Chris Mason 
  Christoph Lameter 
  Daniel Fraga 
  David Disseldorp 
  David Howells 
  David Matlack 
  David S. Miller 
  David Vrabel 
  Dennis Kadioglu 
  Eric Dumazet 
  Eric Wong 
  Felipe Balbi 
  Felipe Balbi 
  Filipe Manana 
  Greg Kroah-Hartman 
  Hans de Goede 
  Helge Deller 
  Hui Wang 
  Ilya 

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 16:21,  wrote:
> According to the POSIX standard for error codes [0], ENODATA is both
> obsolescent (so it may be removed in the future) and optional.

It being optional still doesn't preclude us using it.

> Replace it's
> usage with ENOENT, which seems like the closest match. Both FreeBSD and
> OpenBSD don't have this error code in the native errno.h headers.

There's no rule saying that Xen's errno set must match any other OS'es.
That's one of the reasons why we (finally) separated ours.

> --- a/xen/include/public/errno.h
> +++ b/xen/include/public/errno.h
> @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG, 36) /* File name too long */
>  XEN_ERRNO(ENOLCK,37) /* No record locks available */
>  XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */
>  XEN_ERRNO(ENOSYS,38) /* Function not implemented */
> -XEN_ERRNO(ENODATA,   61) /* No data available */
>  XEN_ERRNO(ETIME, 62) /* Timer expired */
>  XEN_ERRNO(EBADMSG,   74) /* Not a data message */
>  XEN_ERRNO(EOVERFLOW, 75) /* Value too large for defined data type */

And in absolutely no case can you unconditionally remove _anything_
from other than the tools-only parts of the public interface.

Jan


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

[Xen-devel] [PATCH 0/2] x86: fix memory leaks

[Jan Beulich]

1: p2m: clean up altp2m
2: fix domain cleanup

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the 
> > conflicts are 
> > going to be painful! There's very little reason not to carry this kind of 
> > commit:
> > 
> >  arch/arm/xen/enlighten.c   |  6 +
> >  drivers/firmware/efi/arm-runtime.c | 17 +-
> >  drivers/firmware/efi/efi.c | 45 
> > --
> >  3 files changed, 56 insertions(+), 12 deletions(-)
> > 
> > in the EFI tree.
> 
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.

One small change I think would be sensible to make is to expand
EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
Xen, and in the process, to delete EFI_PARAVIRT.

That should address Ingo's major concern, and also make it much easier
to rework the code in a piecemeal fashion.

Could somebody enumerate the things that make Xen (dom0) different on
arm* compared with bare metal EFI boot? The list I made for x86 was,

  1. Has no EFI memory map
  2. Runtime regions do not need to be mapped
  3. Cannot call SetVirtualAddressMap()
  4. /sys/firmware/efi/fw_vendor is invisible

The first maps to not setting EFI_MEMMAP, the second to not setting
EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
to efi.flags that should cover everything on x86. Does arm* require
anything else?

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

Re: [Xen-devel] 2016 Xen hackathon notes - xenstored

[Filipe Manco]

Hi

Regarding LiXS, our goal is to make it one of the upstream xenstore 
alternatives. For that I already started getting internal approvals to 
release the code open source, which should happen somewhere around next 
month. I also need to fix some bugs and would like to do some 
performance testing before the release.


Once it is released, it would be nice to get some comments from the 
community on the implementation, specifically about how to make it 
upstreamable; I’ll let you know when the code is available.


Does this plan sound reasonable?

Best regards
Filipe Manco

P.S. The code will be released under a BSD License

On 28-04-2016 20:34, Luis R. Rodriguez wrote:

At the 2016 Xen Hackathon I raised the topic of the default xenstored
used. Here are my notes with some new additions and supported
documentation. It would seem we're moving to oxenstored as the default
on Linux distributions and FreeBSD now, if you have issues or concerns
with this please let us know.

Notes:
=

Although we have had oxenstored be the the default *iff* you have
ocaml dev libs installled when compiling Xen from source both Linux
distributions (Debian, SUSE*, Gentoo) and FreeBSD were still using the
C xenstored as the default. This begged the question of why not make
the switch given Citrix has already been using oxensotred in
production for years with these known gains [0]:

   * 1/5th the size in terms of line of code in comparison to the C xenstored
   * better performance increasing support for the number of guests, it
 supports 3 times number of guests for an upper limit of 160 guests

At the 2014 summit Anil's presented work on a Xenstore 2.0 which
hinted also towards the future ability to provide git-like
capabilities for the xenstore, all still written in Ocaml [1]. There
are others who have worked on a C++ replacement lixs (Lightweight
XenStore) as well [2], such work revealed oxenstored had the CPU
pegged after just a few dozen guests. Such work hinted that the
oxenstored that should be considered for more serious work was the
Mirage OS xenstore [3], but that the C++ lixs was also performing
better than the current oxenstored.

Although there are questions about the future of the Xenestore we know
oxenstored performs better than cxenstored and since we are building
and using it by default already it begged the question why haven't
distributions made the switch to use it by default. Since Mirage OS
work seems promising we agreed to just set oxenstored as the default
in distributions and in the future hope that Mirage's work or other
contending efforts make it upstream to consider them as alternatives.

Given Mirage Xenstore would still require ocaml, it would be a good
stepping stone now to just use oxenstored by default more widely on
Linux distributions and FreeBSD. A concern was raised about expertise
over Ocaml, however it would seem that we will have no option but to
rely on the community / folks supporting upstream oxenstored for this.

[0] http://www.do-not-panic.com/2014/04/summary-of-gains-of-xen-oxenstored.html
[1] http://decks.openmirage.org/xendevsummit14#/
[2] 
http://events.linuxfoundation.org/sites/events/files/slides/xendevsummit14_0.pdf
[3] https://github.com/mirage/ocaml-xenstore

   Luis



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

[Xen-devel] [PATCH for-4.7 0/4] xsplice fixes

[Roger Pau Monne]

Hello,

This series contains bugfixes for xSplice, that popped up when testing it on 
OSes != Linux.

Roger.


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

Re: [Xen-devel] SMMU, Unhandled context fault

[Peng Fan]

Hi Julien,

On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote:
>Hello,
>
>On 28/04/16 13:56, Peng Fan wrote:
>>On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
>>>
>>>
>>>On 28/04/16 07:39, Peng Fan wrote:
Hi Julien,
>>>
>>>Hello Peng,
>>>
On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
>Hi Julien,
>On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote:
>>Hello Peng,
>>
>>On 27/04/2016 03:02, Peng Fan wrote:
>>>On Tue, Apr 26, 2016 at 04:30:03PM +0200, Edgar E. Iglesias wrote:
On Tue, Apr 26, 2016 at 09:56:33PM +0800, Peng Fan wrote:
>You mean the PNU bit(Privileged Not Unprivileged) is 1?
>I did not met Unhandled context fault each time.
>Actually during my serveral boot test, I only met two times.



I meant the NSSTATE and NSATTR bits in FSYNR are set to zero. I get the
impression that the TrustZone state for the SD controller may be
>>>
>>>oh. The NSATTR bit is 0. I did not find NSSTATE in my Issue D SMMU spec.
>>>If without xen, only one linux boots up, sd controller can access memory 
>>>using
>>>DMA without issue.
>>
>>IIRC, by default Linux baremetal does not protect the devices with the 
>>SMMU.
>>
>>I would recommend you to check whether the SMMUs are in-used and 
>>configured
>>to generate a fault (disable_bypass = 1).
>
>Ok. I'll set S2CRn to generate fault in xen smmu driver to see whether 
>SMMUs in-used or not
>>>
>>>I meant in Linux.
>>
>>My bad. Do you mean enabling SMMU driver in Linux with KVM support?
>
>Yes.
>
>[...]
>
>>Is there any big difference between XEN SMMU driver and linux SMMU driver?
>>I know that XEN only support Stage 2. But the initliaization flow is almost 
>>the same.
>
>The SMMU driver for Xen is a port from Linux 3.19-rc0. Since then the Linux
>driver has been reworked and it might be possible that we have missed some
>bug fix.
>
>Aside that, for Xen, the page tables are always shared between the SMMU and
>the processor.

Thanks. I shared two picture that dumped using TRACE32.

https://drive.google.com/file/d/0B9ruJqJLIGp7cHhhSFNSNC00MHc/view?usp=sharing
https://drive.google.com/file/d/0B9ruJqJLIGp7dmlqVllXYTIxajQ/view?usp=sharing

Would you please help check?

The block that marked red, seems not correct. I am also adding debug info
in xen memory allocation part to see what happends.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall

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

[Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Roger Pau Monne]

Avoid using system errno values when comparing with Xen errno values.

Signed-off-by: Roger Pau Monné 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Ian Jackson 
Cc: Wei Liu 
---
Using errno values inside of hypercall structs is not right IMHO, but there
are already several occurrences of this. Although I'm adding the correct XEN_
prefixes here, it's very likely that new additions/modifications to this
file will not take this into account, breaking it for OSes != Linux.
---
 tools/misc/xen-xsplice.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
index 695be7f..b31115c 100644
--- a/tools/misc/xen-xsplice.c
+++ b/tools/misc/xen-xsplice.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 static xc_interface *xch;
 
 void show_help(void)
@@ -233,7 +235,7 @@ struct {
 .function = xc_xsplice_revert,
 },
 {   .allow = XSPLICE_STATE_CHECKED,
-.expected = -ENOENT,
+.expected = -XEN_ENOENT,
 .name = "unload",
 .function = xc_xsplice_unload,
 },
@@ -276,7 +278,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
 name, errno, strerror(errno));
 return -1;
 }
-if ( status.rc == -EAGAIN )
+if ( status.rc == -XEN_EAGAIN )
 {
 fprintf(stderr, "%s failed. Operation already in progress\n", name);
 return -1;
@@ -319,7 +321,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
 
 if ( status.state != original_state )
 break;
-if ( status.rc && status.rc != -EAGAIN )
+if ( status.rc && status.rc != -XEN_EAGAIN )
 {
 rc = status.rc;
 break;
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 4/4] xen/xsplice: remove OSABI check when loading a payload

[Roger Pau Monne]

FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
still be loaded without issues.

All the ELF OS ABIs follow the System V calling convention, and the OS ABI
doesn't really matter because Xen is a standalone kernel.

Signed-off-by: Roger Pau Monné 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
---
 xen/common/xsplice_elf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
index e403a0e..de68d29 100644
--- a/xen/common/xsplice_elf.c
+++ b/xen/common/xsplice_elf.c
@@ -397,7 +397,6 @@ static int xsplice_header_check(const struct xsplice_elf 
*elf)
 if ( hdr->e_version != EV_CURRENT ||
  hdr->e_ident[EI_VERSION] != EV_CURRENT ||
  hdr->e_ident[EI_ABIVERSION] != 0 ||
- hdr->e_ident[EI_OSABI] != ELFOSABI_SYSV ||
  hdr->e_type != ET_REL ||
  hdr->e_phnum != 0 )
 {
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

According to the POSIX standard for error codes [0], ENODATA is both
obsolescent (so it may be removed in the future) and optional. Replace it's
usage with ENOENT, which seems like the closest match. Both FreeBSD and
OpenBSD don't have this error code in the native errno.h headers.

[0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Tim Deegan 
Cc: George Dunlap 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 tools/libxl/libxl.c |  2 +-
 xen/arch/x86/hvm/hvm.c  |  8 
 xen/arch/x86/microcode_amd.c|  4 ++--
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/common/device_tree.c|  2 +-
 xen/common/domctl.c |  2 +-
 xen/common/version.c| 10 +-
 xen/drivers/acpi/pmstat.c   |  2 +-
 xen/drivers/acpi/tables.c   |  2 +-
 xen/include/public/errno.h  |  1 -
 10 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c39d745..0dcc06f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5361,7 +5361,7 @@ static const int libxl__xc_version_wrap(libxl__gc *gc, 
libxl_version_info *info,
 r = xc_version(CTX->xch, XENVER_build_id, build);
 switch (r) {
 case -EPERM:
-case -ENODATA:
+case -ENOENT:
 case 0:
 info->build_id = libxl__strdup(NOGC, "");
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8cb6e9e..980b4a1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1274,14 +1274,14 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read xsave 
descriptor\n",
d->domain_id, vcpuid);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length + sizeof (*desc) > h->size - h->cur)
 {
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read %u xsave 
bytes\n",
d->domain_id, vcpuid, desc->length);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length < offsetof(struct hvm_hw_cpu_xsave, save_area) +
 XSTATE_AREA_MIN_SIZE )
@@ -1402,14 +1402,14 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read MSR 
descriptor\n",
d->domain_id, vcpuid);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length + sizeof (*desc) > h->size - h->cur)
 {
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read %u MSR bytes\n",
d->domain_id, vcpuid, desc->length);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length < HVM_CPU_MSR_SIZE(1) )
 {
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index a61c926..ca1a026 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -342,7 +342,7 @@ static int container_fast_forward(const void *data, size_t 
size_left, size_t *of
 *offset += size;
 
 if ( !size_left )
-return -ENODATA;
+return -ENOENT;
 }
 
 return 0;
@@ -454,7 +454,7 @@ static int cpu_request_microcode(unsigned int cpu, const 
void *buf,
 break;
 
 error = container_fast_forward(buf, bufsize - offset, );
-if ( error == -ENODATA )
+if ( error == -ENOENT )
 {
 ASSERT(offset == bufsize);
 break;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4e06c13..6ce76e2 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3729,7 +3729,7 @@ int shadow_track_dirty_vram(struct domain *d,
 dirty_vram->last_dirty = NOW();
 
 /* Tell the caller that this time we could not track dirty bits. */
-rc = -ENODATA;
+rc = -ENOENT;
 }
 else if (dirty_vram->last_dirty == -1)
 /* still completely clean, just copy our empty bitmap */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..9d1896e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -204,7 +204,7 @@ int dt_property_read_string(const struct dt_device_node *np,
 if ( !pp )
 return -EINVAL;
 if ( !pp->value )
-return -ENODATA;
+return -ENOENT;
 if ( strnlen(pp->value, pp->length) >= pp->length )
 return -EILSEQ;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index e43904e..d07114a 

[Xen-devel] [PATCH for-4.7 2/4] tools/xsplice: corrently use errno

[Roger Pau Monne]

Some error paths incorrectly used rc instead of errno.

Signed-off-by: Roger Pau Monné 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/misc/xen-xsplice.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
index 0f1ab5a..695be7f 100644
--- a/tools/misc/xen-xsplice.c
+++ b/tools/misc/xen-xsplice.c
@@ -273,7 +273,7 @@ int action_func(int argc, char *argv[], unsigned int idx)
 if ( rc )
 {
 fprintf(stderr, "%s failed to get status (rc=%d, %s)!\n",
-name, -rc, strerror(-rc));
+name, errno, strerror(errno));
 return -1;
 }
 if ( status.rc == -EAGAIN )
@@ -295,7 +295,8 @@ int action_func(int argc, char *argv[], unsigned int idx)
 rc = action_options[idx].function(xch, name, 0);
 if ( rc )
 {
-fprintf(stderr, "%s failed with %d(%s)\n", name, -rc, 
strerror(-rc));
+fprintf(stderr, "%s failed with %d(%s)\n", name, errno,
+strerror(errno));
 return -1;
 }
 }
-- 
2.6.4 (Apple Git-63)


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

Re: [Xen-devel] pvops xen_blkfront does not enforce device names

[Konrad Rzeszutek Wilk]

On Fri, Apr 29, 2016 at 01:27:35PM +0200, Olaf Hering wrote:
> On Fri, Apr 29, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > > Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > > In my PV domU.cfg I still have something like this:
> > > disk=[ 'file:/path,hda,w' ]
> > > 
> > > With pvops and xen_blkfront I get xvda.
> > > With xenlinux and xenblk I get hda.
> > 
> > It has no business subverting the hda device names which
> > are specifically for legacy devices.
> 
> Old IDE drives are not SCSI either, but now they appear as 'sd' since a
> while.
> 
> 'hd' or 'sd' or 'mmc' or 'xvd' are just names. They do not represent
> hardware as such. Otherwise the interface into the blocklayer to request
> major/minor/name would be like 'hey, I'm the IDE/SCSI/MMC/whatever
> driver, give me something'.
> 
> Anyway, since this is now set in stone, any VM out there which still is
> configured to use /dev/hd* has to be adjusted to /dev/xvd* upfront when
> going from xenlinux to pvops.

You may want to adjust it to use UUID. It really makes it easier in case
they also want to swap the disks arounds, etc.
> 
> Olaf

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

Re: [Xen-devel] 2016 Xen hackathon notes - xenstored

[Anil Madhavapeddy]

Please do get in touch if you have any packaging problems concerning OCaml.  
It's pretty good on modern Linux and FreeBSD though, and oxenstored works on 
most modern releases.

We've not got a set of patches that are suitable for upstreaming for the 
Xenstored/Irmin tree that we demonstrated at XenSummit, so please don't block 
waiting for that.

Anil

> On 28 Apr 2016, at 19:34, Luis R. Rodriguez  wrote:
> 
> At the 2016 Xen Hackathon I raised the topic of the default xenstored
> used. Here are my notes with some new additions and supported
> documentation. It would seem we're moving to oxenstored as the default
> on Linux distributions and FreeBSD now, if you have issues or concerns
> with this please let us know.
> 
> Notes:
> =
> 
> Although we have had oxenstored be the the default *iff* you have
> ocaml dev libs installled when compiling Xen from source both Linux
> distributions (Debian, SUSE*, Gentoo) and FreeBSD were still using the
> C xenstored as the default. This begged the question of why not make
> the switch given Citrix has already been using oxensotred in
> production for years with these known gains [0]:
> 
>  * 1/5th the size in terms of line of code in comparison to the C xenstored
>  * better performance increasing support for the number of guests, it
>supports 3 times number of guests for an upper limit of 160 guests
> 
> At the 2014 summit Anil's presented work on a Xenstore 2.0 which
> hinted also towards the future ability to provide git-like
> capabilities for the xenstore, all still written in Ocaml [1]. There
> are others who have worked on a C++ replacement lixs (Lightweight
> XenStore) as well [2], such work revealed oxenstored had the CPU
> pegged after just a few dozen guests. Such work hinted that the
> oxenstored that should be considered for more serious work was the
> Mirage OS xenstore [3], but that the C++ lixs was also performing
> better than the current oxenstored.
> 
> Although there are questions about the future of the Xenestore we know
> oxenstored performs better than cxenstored and since we are building
> and using it by default already it begged the question why haven't
> distributions made the switch to use it by default. Since Mirage OS
> work seems promising we agreed to just set oxenstored as the default
> in distributions and in the future hope that Mirage's work or other
> contending efforts make it upstream to consider them as alternatives.
> 
> Given Mirage Xenstore would still require ocaml, it would be a good
> stepping stone now to just use oxenstored by default more widely on
> Linux distributions and FreeBSD. A concern was raised about expertise
> over Ocaml, however it would seem that we will have no option but to
> rely on the community / folks supporting upstream oxenstored for this.
> 
> [0] 
> http://www.do-not-panic.com/2014/04/summary-of-gains-of-xen-oxenstored.html
> [1] http://decks.openmirage.org/xendevsummit14#/
> [2] 
> http://events.linuxfoundation.org/sites/events/files/slides/xendevsummit14_0.pdf
> [3] https://github.com/mirage/ocaml-xenstore
> 
>  Luis
> 


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

Re: [Xen-devel] [PATCH] x86/shadow: account for ioreq server pages before complaining about not found mapping

[Wei Liu]

On Fri, Apr 29, 2016 at 02:13:35AM -0600, Jan Beulich wrote:
> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
> takes a write reference on the page, and hence should similarly be
> accounted for when determining whether to log a complaint.
> 
> This requires using recursive locking for the ioreq server lock, as the
> offending invocation of sh_remove_all_mappings() is down the call stack
> from hvm_set_ioreq_server_state(). (While not strictly needed to be
> done in all other instances too, convert all of them for consistency.)
> 
> At once improve the usefulness of the shadow error message: Log all
> values involved in triggering it as well as the GFN (to aid
> understanding which guest page it is that there is a problem with - in
> cases like the one here the GFN is invariant across invocations, while
> the MFN obviously can [and will] vary).
> 
> Signed-off-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

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

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

[osstest service owner]

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

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 b59e2427c2d92cfee0238d9bde7372691c2af17c
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  143 days
Failing since 65593  2015-12-08 23:44:51 Z  142 days  190 attempts
Testing same since93204  2016-04-29 11:14:57 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

Re: [Xen-devel] [PATCH] x86/shadow: account for ioreq server pages before complaining about not found mapping

[Jan Beulich]

>>> On 29.04.16 at 14:28,  wrote:
> On 29/04/16 09:13, Jan Beulich wrote:
>> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
>> takes a write reference on the page, and hence should similarly be
>> accounted for when determining whether to log a complaint.
>>
>> This requires using recursive locking for the ioreq server lock, as the
>> offending invocation of sh_remove_all_mappings() is down the call stack
>> from hvm_set_ioreq_server_state(). (While not strictly needed to be
>> done in all other instances too, convert all of them for consistency.)
>>
>> At once improve the usefulness of the shadow error message: Log all
>> values involved in triggering it as well as the GFN (to aid
>> understanding which guest page it is that there is a problem with - in
>> cases like the one here the GFN is invariant across invocations, while
>> the MFN obviously can [and will] vary).
>>
>> Signed-off-by: Jan Beulich 
> 
> IMO, this is a 4.7 candidate. I already had a TODO list item of working
> out why the shadow code was always complaining.

Definitely (hence I had copied Wei).

> Reviewed-by: Andrew Cooper , albeit with one
> further suggestion.
> 
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include "private.h"
>>  
>> @@ -2591,7 +2592,8 @@ int sh_remove_write_access_from_sl1p(str
>>  /* Remove all mappings of a guest frame from the shadow tables.
>>   * Returns non-zero if we need to flush TLBs. */
>>  
>> -static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn)
>> +static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn,
>> +  unsigned long gfn)
> 
> It would be nice if we could use gfn_t rather than having more unsigned
> longs.

I generally agree, but intentionally didn't to match all the other
shadow code. I'll make changing this dependent on what Tim
thinks.

Jan


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

Re: [Xen-devel] [PATCH] x86/shadow: account for ioreq server pages before complaining about not found mapping

[Andrew Cooper]

On 29/04/16 09:13, Jan Beulich wrote:
> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
> takes a write reference on the page, and hence should similarly be
> accounted for when determining whether to log a complaint.
>
> This requires using recursive locking for the ioreq server lock, as the
> offending invocation of sh_remove_all_mappings() is down the call stack
> from hvm_set_ioreq_server_state(). (While not strictly needed to be
> done in all other instances too, convert all of them for consistency.)
>
> At once improve the usefulness of the shadow error message: Log all
> values involved in triggering it as well as the GFN (to aid
> understanding which guest page it is that there is a problem with - in
> cases like the one here the GFN is invariant across invocations, while
> the MFN obviously can [and will] vary).
>
> Signed-off-by: Jan Beulich 

IMO, this is a 4.7 candidate. I already had a TODO list item of working
out why the shadow code was always complaining.

Reviewed-by: Andrew Cooper , albeit with one
further suggestion.

> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "private.h"
>  
> @@ -2591,7 +2592,8 @@ int sh_remove_write_access_from_sl1p(str
>  /* Remove all mappings of a guest frame from the shadow tables.
>   * Returns non-zero if we need to flush TLBs. */
>  
> -static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn)
> +static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn,
> +  unsigned long gfn)

It would be nice if we could use gfn_t rather than having more unsigned
longs.

~Andrew

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

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

[osstest service owner]

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

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  f9bf994d81031b53191106e78653c3983e8e3536
baseline version:
 xen  1d5b507e69d67d2a6eee54286e44b5b7cc525e6c

Last test of basis93093  2016-04-28 14:01:33 Z0 days
Testing same since93195  2016-04-29 10:01:34 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall  [ARM]
  Konrad Rzeszutek Wilk 
  Martin Pohlack 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] pvops xen_blkfront does not enforce device names

[Olaf Hering]

On Fri, Apr 29, Konrad Rzeszutek Wilk wrote:

> On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > In my PV domU.cfg I still have something like this:
> > disk=[ 'file:/path,hda,w' ]
> > 
> > With pvops and xen_blkfront I get xvda.
> > With xenlinux and xenblk I get hda.
> 
> It has no business subverting the hda device names which
> are specifically for legacy devices.

Old IDE drives are not SCSI either, but now they appear as 'sd' since a
while.

'hd' or 'sd' or 'mmc' or 'xvd' are just names. They do not represent
hardware as such. Otherwise the interface into the blocklayer to request
major/minor/name would be like 'hey, I'm the IDE/SCSI/MMC/whatever
driver, give me something'.

Anyway, since this is now set in stone, any VM out there which still is
configured to use /dev/hd* has to be adjusted to /dev/xvd* upfront when
going from xenlinux to pvops.

Olaf

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

Re: [Xen-devel] pvops xen_blkfront does not enforce device names

[Stefano Stabellini]

On Fri, 29 Apr 2016, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 01:29:17AM -0600, Jan Beulich wrote:
> > >>> On 29.04.16 at 08:45,  wrote:
> > > On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > >> Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > >> In my PV domU.cfg I still have something like this:
> > >> disk=[ 'file:/path,hda,w' ]
> > >> 
> > >> With pvops and xen_blkfront I get xvda.
> > >> With xenlinux and xenblk I get hda.
> > > 
> > > It has no business subverting the hda device names which
> > > are specifically for legacy devices.
> > 
> > That's one view. The other is that people moving from XenoLinux to
> > pv-ops are in trouble without it. How did you (or Citrix, if anyone of
> > them looks) deal with this when doing the transition?
> 
> We had transition folks to use 'UUID' or volume group names in their 'root='
> entry so never had an issue with this.
> > 
> > > [We got smacked down at some point for having done this]
> > 
> > In which way?
> 
> For usurping the 'hda'. Stefano may remember the details more..

The argument goes as follow: 'hda' as 'xvda' or 'sda' are Linux specific
names. A different operating system could name its devices 'goofy', or
any other made up names. The Xen toolstack has no business in choosing
the naming scheme for the guest kernel to use. Moreover xl can do
nothing to enforce it: what if the OS stubbornly keeps calling its
devices 'goofy' even if according to xl should be 'hda'? It is just an
internal OS representation, so the OS can do as it wishes.

Linux doesn't want to call PV disks anything else than xvd*. After all
they are PV disks, aren't they? And Xen cannot do anything about it.

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

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

[osstest service owner]

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

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 6d3911d40610c01e843a35cefd1fec57f98a4fc2
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  143 days
Failing since 65593  2015-12-08 23:44:51 Z  142 days  189 attempts
Testing same since93183  2016-04-29 06:45:42 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Ingo Molnar]

* Stefano Stabellini  wrote:

> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the 
> > conflicts are 
> > going to be painful! There's very little reason not to carry this kind of 
> > commit:
> > 
> >  arch/arm/xen/enlighten.c   |  6 +
> >  drivers/firmware/efi/arm-runtime.c | 17 +-
> >  drivers/firmware/efi/efi.c | 45 
> > --
> >  3 files changed, 56 insertions(+), 12 deletions(-)
> > 
> > in the EFI tree.
> 
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.

Thanks!

Ingo

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

Re: [Xen-devel] pvops xen_blkfront does not enforce device names

[Andrew Cooper]

On 29/04/16 10:39, David Vrabel wrote:
> On 29/04/16 08:29, Jan Beulich wrote:
> On 29.04.16 at 08:45,  wrote:
>>> On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
 Why does xen_blkfront not enforce kernel device names from domU.cfg?
 In my PV domU.cfg I still have something like this:
 disk=[ 'file:/path,hda,w' ]

 With pvops and xen_blkfront I get xvda.
 With xenlinux and xenblk I get hda.
>>> It has no business subverting the hda device names which
>>> are specifically for legacy devices.
>> That's one view. The other is that people moving from XenoLinux to
>> pv-ops are in trouble without it. How did you (or Citrix, if anyone of
>> them looks) deal with this when doing the transition?
> XenServer always named its PV disks as xvda etc.

The toolstack has no business trying to control how the guest chooses to
name its block devices.  The device name is private information to the
guest.

It should continue to function in exactly the same way even if the guest
admin edits their udev rules to rename it to something crazy like "".

~Andrew

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