date:20170428

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 107819
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 107819
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 107819
 test-amd64-amd64-rumprun-amd64  6 xen-boot   fail REGR. vs. 107819
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 107819
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 107819
 test-amd64-amd64-pair 9 xen-boot/src_hostfail REGR. vs. 107819
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 107819
 test-amd64-amd64-pair10 xen-boot/dst_hostfail REGR. vs. 107819
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host   fail REGR. vs. 107819
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host   fail REGR. vs. 107819
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 107819
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 107819
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot   fail REGR. vs. 107819
 test-amd64-i386-libvirt   6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-libvirt-xsm   6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 107819
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-i386-pvgrub  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 107819
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 107819
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107819
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 107819
 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 107819
 test-amd64-amd64-pygrub   6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-xsm   6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 107819
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 107819
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-rumprun-i386  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-bootfail REGR. vs. 107819
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107819
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107819
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107819
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-bootfail REGR. vs. 107819
 test-amd64-amd64-qemuu-nested-amd  6 xen-bootfail REGR. vs. 107819
 test-amd64-amd64-xl-pvh-amd   6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107819
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot fail REGR. vs. 107819
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107819
 test-arm64-arm64-libvirt  6 xen-boot fail REGR. vs. 107819
 test-arm64-arm64-xl-xsm   6 xen-boot

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

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

Regressions :-(

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

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

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

2017-04-28 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
baseline version:
 ovmf fcdb928a82c4ed3d776d05c277d5fb30f00f2120

Last test of basis71238  2017-04-27 20:17:28 Z1 days
Testing same since71241  2017-04-29 01:51:01 Z0 days1 attempts


People who touched revisions under test:
  Leif Lindholm 

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



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

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

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


Push not applicable.


commit 65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
Author: Leif Lindholm 
Date:   Wed Apr 26 22:49:16 2017 +0100

StdLib: GCC 6 build fixes

Resolve mainly 'misleading indentation', but also one 'defined but not used'
warning when building with GCC 6 (using GCC5 profile).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Jaben Carsey 

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

[Xen-devel] [seabios test] 107912: regressions - FAIL

flight 107912 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107912/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
106986
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
106986
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stop  fail REGR. vs. 106986

Tests which did not succeed, but are not blocking:
 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   29 days
Testing same since   107663  2017-04-25 17:17:46 Z3 days   30 attempts


People who touched revisions under test:
  Julius Werner 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-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-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3fail



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to support the new format. (SeaBIOS versions with this
patch will continue to work fine with older version of coreboot. SeaBIOS
versions without this patch may fail to log messages to the CBMEM
console if run with newer versions of coreboot, but should not
experience any more serious issues than that.)

Signed-off-by: Julius Werner 

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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
baseline version:
 ovmf fcdb928a82c4ed3d776d05c277d5fb30f00f2120

Last test of basis   107800  2017-04-27 13:48:53 Z1 days
Testing same since   107913  2017-04-28 16:16:28 Z0 days1 attempts


People who touched revisions under test:
  Leif Lindholm 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
+ branch=ovmf
+ revision=65ed9d7ff55ad5c149e713d73b8d52ee8cbce601
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x65ed9d7ff55ad5c149e713d73b8d52ee8cbce601 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ :

[Xen-devel] [libvirt bisection] complete build-armhf-libvirt

branch xen-unstable
xenbranch xen-unstable
job build-armhf-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  02fb15fb60274a684497293fecba400e37687d95
  Bug not present: ab54d5f15239940d4e3d142c553d7e55ec0ff13b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107929/


  commit 02fb15fb60274a684497293fecba400e37687d95
  Author: Daniel P. Berrange 
  Date:   Thu Mar 2 10:46:53 2017 +
  
  util: switch over to use keycodemapdb GIT submodule
  
  A long time ago we imported the keymaps.csv file from GTK-VNC so we
  can do conversions between keycode sets. Meanwhile lots of bug fixes
  have gone into this CSV file and libvirt hasn't kept in sync. The
  keymaps.csv file and associated generator script has been pulled out
  of GTK-VNC into a dedicated GIT repo for use as a submodule. This
  allows GTK-VNC, SPICE-GTK, QEMU and libvirt to share the same master
  database and tools and pushing updates merely requires a submodule
  commit update as with gnulib.
  
  The test suite is updated to cover some extra boundary conditions.
  
  Signed-off-by: Daniel P. Berrange 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-armhf-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-armhf-libvirt.libvirt-build 
--summary-out=tmp/107929.bisection-summary --basis-template=107640 
--blessings=real,real-bisect libvirt build-armhf-libvirt libvirt-build
Searching for failure / basis pass:
 107851 fail [host=arndale-lakeside] / 107640 [host=arndale-westfield] 107613 
[host=arndale-westfield] 107594 ok.
Failure / basis pass flights: 107851 / 107594
(tree in basispass but not in latest: libvirt_gnulib)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5ade0ff90581cddce71dd40840ca72f87825cb54 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
Basis pass 997134fb8b17eef6eba439303b382b239996208b 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
f97838bbd980a0104e16c4a12fbf514f9fa805f1
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#997134fb8b17eef6eba439303b382b239996208b-5ade0ff90581cddce71dd40840ca72f87825cb54
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7
 
git://xenbits.xen.org/xen.git#f97838bbd980a0104e16c4a12fbf514f9fa805f1-8829d12ac0f9e3f7b01f276cd966c5a39497da92
Loaded 2001 nodes in revision graph
Searching for test results:
 107613 [host=arndale-westfield]
 107594 pass 997134fb8b17eef6eba439303b382b239996208b 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
f97838bbd980a0104e16c4a12fbf514f9fa805f1
 107696 fail irrelevant
 107640 [host=arndale-westfield]
 107755 fail 26d21e5de8743ab0d594d7dc46ecfc5524c08cd3 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107851 fail 5ade0ff90581cddce71dd40840ca72f87825cb54 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107910 pass ab54d5f15239940d4e3d142c553d7e55ec0ff13b 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107922 pass ab54d5f15239940d4e3d142c553d7e55ec0ff13b 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107909 fail 5ade0ff90581cddce71dd40840ca72f87825cb54 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107914 fail 4b6264508fb3e27a7ac48bfca616e5fb06f8f4ac 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107894 pass 997134fb8b17eef6eba439303b382b239996208b 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
f97838bbd980a0104e16c4a12fbf514f9fa805f1
 107918 fail e6c3b59c193ec1d17d72b65d460a951227c12a72 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107916 fail 859a2d162ac6dd141539819cfc6157724d12bde6 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107915 fail a94d431dc46070034de7798f572dc1d257542a50 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107921 fail 02fb15fb60274a684497293fecba400e37687d95 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107926 fail 02fb15fb60274a684497293fecba400e37687d95 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107928 pass

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

On Thu, 13 Apr 2017, Herongguang (Stephen) wrote:
> On 2017/4/13 7:51, Stefano Stabellini wrote:
> > On Wed, 12 Apr 2017, Herongguang (Stephen) wrote:
> > > On 2017/4/12 6:32, Stefano Stabellini wrote:
> > > > On Tue, 11 Apr 2017, hrg wrote:
> > > > > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini
> > > > >  wrote:
> > > > > > On Mon, 10 Apr 2017, Stefano Stabellini wrote:
> > > > > > > On Mon, 10 Apr 2017, hrg wrote:
> > > > > > > > On Sun, Apr 9, 2017 at 11:55 PM, hrg 
> > > > > > > > wrote:
> > > > > > > > > On Sun, Apr 9, 2017 at 11:52 PM, hrg 
> > > > > > > > > wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > In xen_map_cache_unlocked(), map to guest memory maybe in
> > > > > > > > > > entry->next
> > > > > > > > > > instead of first level entry (if map to rom other than guest
> > > > > > > > > > memory
> > > > > > > > > > comes first), while in xen_invalidate_map_cache(), when VM
> > > > > > > > > > ballooned
> > > > > > > > > > out memory, qemu did not invalidate cache entries in linked
> > > > > > > > > > list(entry->next), so when VM balloon back in memory, gfns
> > > > > > > > > > probably
> > > > > > > > > > mapped to different mfns, thus if guest asks device to DMA
> > > > > > > > > > to
> > > > > > > > > > these
> > > > > > > > > > GPA, qemu may DMA to stale MFNs.
> > > > > > > > > > 
> > > > > > > > > > So I think in xen_invalidate_map_cache() linked lists should
> > > > > > > > > > also be
> > > > > > > > > > checked and invalidated.
> > > > > > > > > > 
> > > > > > > > > > What’s your opinion? Is this a bug? Is my analyze correct?
> > > > > > > Yes, you are right. We need to go through the list for each
> > > > > > > element of
> > > > > > > the array in xen_invalidate_map_cache. Can you come up with a
> > > > > > > patch?
> > > > > > I spoke too soon. In the regular case there should be no locked
> > > > > > mappings
> > > > > > when xen_invalidate_map_cache is called (see the DPRINTF warning at
> > > > > > the
> > > > > > beginning of the functions). Without locked mappings, there should
> > > > > > never
> > > > > > be more than one element in each list (see xen_map_cache_unlocked:
> > > > > > entry->lock == true is a necessary condition to append a new entry
> > > > > > to
> > > > > > the list, otherwise it is just remapped).
> > > > > > 
> > > > > > Can you confirm that what you are seeing are locked mappings
> > > > > > when xen_invalidate_map_cache is called? To find out, enable the
> > > > > > DPRINTK
> > > > > > by turning it into a printf or by defininig MAPCACHE_DEBUG.
> > > > > In fact, I think the DPRINTF above is incorrect too. In
> > > > > pci_add_option_rom(), rtl8139 rom is locked mapped in
> > > > > pci_add_option_rom->memory_region_get_ram_ptr (after
> > > > > memory_region_init_ram). So actually I think we should remove the
> > > > > DPRINTF warning as it is normal.
> > > > Let me explain why the DPRINTF warning is there: emulated dma operations
> > > > can involve locked mappings. Once a dma operation completes, the related
> > > > mapping is unlocked and can be safely destroyed. But if we destroy a
> > > > locked mapping in xen_invalidate_map_cache, while a dma is still
> > > > ongoing, QEMU will crash. We cannot handle that case.
> > > > 
> > > > However, the scenario you described is different. It has nothing to do
> > > > with DMA. It looks like pci_add_option_rom calls
> > > > memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a
> > > > locked mapping and it is never unlocked or destroyed.
> > > > 
> > > > It looks like "ptr" is not used after pci_add_option_rom returns. Does
> > > > the append patch fix the problem you are seeing? For the proper fix, I
> > > > think we probably need some sort of memory_region_unmap wrapper or maybe
> > > > a call to address_space_unmap.
> > > 
> > > Yes, I think so, maybe this is the proper way to fix this.
> > 
> > Would you be up for sending a proper patch and testing it? We cannot call
> > xen_invalidate_map_cache_entry directly from pci.c though, it would need
> > to be one of the other functions like address_space_unmap for example.
> > 
> 
> 
> Yes, I will look into this.

Any updates?


> > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > index e6b08e1..04f98b7 100644
> > > > --- a/hw/pci/pci.c
> > > > +++ b/hw/pci/pci.c
> > > > @@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev,
> > > > bool
> > > > is_default_rom,
> > > >}
> > > >  pci_register_bar(pdev, PCI_ROM_SLOT, 0, >rom);
> > > > +xen_invalidate_map_cache_entry(ptr);
> > > >}
> > > >  static void pci_del_option_rom(PCIDevice *pdev)
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-04-28 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 71240 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71240/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
71236
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
71236

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71236
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71236
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71236
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71236
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 71236
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71236
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 71236
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 71236

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0a5370ee1f9808fbb16bb03d7f349921cf73a2d4
baseline version:
 xen  8829d12ac0f9e3f7b01f276cd966c5a39497da92

Last test of basis71236  2017-04-26 20:47:10 Z2 days
Testing same since71240  2017-04-28 14:17:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Jennifer Herbert

Re: [Xen-devel] [PATCH 07/10 v2] xen/arm: vpl011: Add support for vuart in xenconsole

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Xenconsole supports only PV console currently. This patch adds support
> for vuart, which allows emulated pl011 uart to be accessed as a console.
> 
> This patch modifies different data structures and APIs used
> in xenconsole to support two console types: PV and VUART.
> 
> Change summary:
> 
> 1. Split the domain structure into a console structure and the
>domain structure. Each PV and VUART will have seprate console
>structures.
> 
> 2. Modify different APIs such as buffer_append() etc. to take
>console structure as input and perform per console specific
>operations.
> 
> 3. Modfications in domain_create_ring():
> - Bind to the vpl011 event channel obtained from the xen store as a
>   new parameter.
> - Map the PFN to its address space to be used as IN/OUT ring
>   buffers.
>   It obtains the PFN from the xen store as a new parameter
> 
> 4. Modifications in handle_ring_read() to handle both PV and VUART
>events.
> 
> 5. Add a new log_file for VUART console logs.

This patch is too big. It might be best to split this patch in two: one
to refactor the code to introduce struct console, and the other to
introduce the vuart console.  It would make it far easier to review.


> Signed-off-by: Bhupinder Thakur 
> ---
> 
> Changes since v1:
> 
> - Split the domain struture to a separate console structure
> - Modified the functions to operate on the console struture
> - Replaced repetitive per console code with generic code
> 
>  tools/console/daemon/io.c | 514 
> --
>  1 file changed, 365 insertions(+), 149 deletions(-)
> 
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index 7e6a886..55fda37 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -61,6 +61,10 @@
>  /* Duration of each time period in ms */
>  #define RATE_LIMIT_PERIOD 200
>  
> +#define MAX_CONSOLE 2
> +#define CONSOLE_TYPE_PV 0
> +#define CONSOLE_TYPE_VUART 1

It would be nice to protect this by something like:

#ifdef CONFIG_ARM64 && CONFIG_ACPI

so that we don't waste memory in all other cases. The end result would
be to have an console array of only one element on arm32 and x86 and
when acpi is disabled.


>  extern int log_reload;
>  extern int log_guest;
>  extern int log_hv;
> @@ -89,29 +93,75 @@ struct buffer {
>   size_t max_capacity;
>  };
>  
> -struct domain {
> - int domid;
> +struct console {
> + char *name;
> + char *ttyname;
>   int master_fd;
>   int master_pollfd_idx;
>   int slave_fd;
>   int log_fd;
> - bool is_dead;
> - unsigned last_seen;
>   struct buffer buffer;
> - struct domain *next;
> - char *conspath;
>   int ring_ref;
>   xenevtchn_port_or_error_t local_port;
>   xenevtchn_port_or_error_t remote_port;
> + struct xencons_interface *interface;
> + struct domain *d;  /* Reference to the domain it is contained in. */
> +};
> +
> +struct domain {
> + int domid;
> + bool is_dead;
> + unsigned last_seen;
> + struct domain *next;
> + char *conspath;
>   xenevtchn_handle *xce_handle;
>   int xce_pollfd_idx;
> - struct xencons_interface *interface;
>   int event_count;
>   long long next_period;
> + struct console console[MAX_CONSOLE];
>  };
>  
>  static struct domain *dom_head;
>  
> +static inline bool console_enabled(struct console *con) { return 
> con->local_port != -1; }

Long lines through this patch. Max length is supposed to be 80 chars.


> +
> +static inline void console_iter_no_check(struct domain *d, void (* 
> iter_func)(struct console *))
> +{
> + int i = 0;
> + struct console *con = &(d->console[0]);
> +
> + for (i=0; i < MAX_CONSOLE; i++, con++)

code style i = 0


> + {
> + iter_func(con);
> + }
> +}
> +
> +static inline bool console_iter_bool_check(struct domain *d, bool (* 
> iter_func)(struct console *))
> +{
> + int i = 0;
> + struct console *con = &(d->console[0]);
> +
> + for (i=0; i < MAX_CONSOLE; i++, con++)

code style


> + {
> + if (iter_func(con))
> + return true;
> + }
> + return false;
> +}
> +
> +static inline int console_iter_err_check(struct domain *d, int (* 
> iter_func)(struct console *))
> +{
> + int i = 0;
> + struct console *con = &(d->console[0]);
> +
> + for (i=0; i < MAX_CONSOLE; i++, con++)

code style


> + {
> + if (!iter_func(con))
> + return 0;
> + }
> + return 1;
> +}
> +
>  static int write_all(int fd, const char* buf, size_t len)
>  {
>   while (len) {
> @@ -158,11 +208,24 @@ static int write_with_timestamp(int fd, const char 
> *data, size_t sz,
>   return 0;
>  }
>  
> -static void buffer_append(struct domain *dom)
> +static inline bool buffer_available(struct console *con)
> +{
> + if

[Xen-devel] [linux-4.9 test] 107879: regressions - FAIL

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 107776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 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-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass

version targeted for testing:
 linuxa8c90ef62281db933118aa84489eb0e1e9cc347c
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   18 days
Failing since107396  2017-04-12 11:15:19 Z   16 days   29 attempts
Testing same since   107776  2017-04-27 09:07:29 Z1 days3 attempts


People who touched revisions under test:
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Alexandre Belloni 
  Amit Pundir 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Smetanin 
  Andy Gross 
  Andy Lutomirski 
  Andy Shevchenko 
  Ard Biesheuvel

Re: [Xen-devel] [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

On 04/28/2017 09:42 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> We want to track why a guest was shutdown; in particular, being able
>> to tell the difference between a guest request (such as ACPI request)
>> and host request (such as SIGINT) will prove useful to libvirt.
>> Since all requests eventually end up changing shutdown_requested in
>> vl.c, the logical change is to make that value track the reason,
>> rather than its current 0/1 contents.
>>
>> Since command-line options control whether a reset request is turned
>> into a shutdown request instead, the same treatment is given to
>> reset_requested.
>>
>> This patch adds a QAPI enum ShutdownCause that describes reasons
>> that a shutdown can be requested, and changes qemu_system_reset() to
>> pass the reason through, although for now it is not reported.  The
>> next patch will actually wire things up to modify events to report
>> data based on the reason, and to pass the correct enum value in from
>> various call-sites that can trigger a reset/shutdown.  Since QAPI
>> generates enums starting at 0, it's easier if we use a different
>> number as our sentinel that no request has happened yet.  Most of
>> the changes are in vl.c, but xen was using things externally.
>>

>> -static int reset_requested;
>> -static int shutdown_requested, shutdown_signal;
>> +static int reset_requested = -1;
>> +static int shutdown_requested = -1, shutdown_signal;
> 
> Peeking ahead, I see that shutdown_requested and reset_requested take
> ShutdownCause values and -1.  The latter means "no shutdown requested".
> What about adding 'none' to ShutdownCause, with value 0, und use that
> instead of literal -1?  Would avoid the unusual "negative means false,
> non-negative means true".

Works nicely if the enum is internal-use only.  Gets a bit more awkward
if the enum is exposed to the end-user.

The fact that I let QAPI generate the enum in patch 3 is evidence that
I'm leaning towards exposing it to the end user (patch 4); if we want to
keep it internal-only, a better place for the enum might be in sysemu.h
(where we also have the weird '#define VMRESET_SILENT false' '#define
VMRESET_REPORT true' to name a boolean parameter).

> 
> PATCH 4 exposes ShutdownCause in event SHUTDOWN, and 'none' must not
> occur there.  However, if we ever add a query-shutdown to go with this
> event, we will need 'none' there.

So, query-shutdown would basically be: what is the last-reported
shutdown event (normally none, when the guest is still running; but if,
like libvirt, you start qemu -no-shutdown, it can then be the cause of
why we are in a shutdown/stopped state while waiting for final cleanup)?

How important/likely is such an event?  (Hmm, from libvirt's
perspective, events are usually reliable, but can be lost; if we can
restart libvirtd and reconnect to a qemu process that is hanging on to
life only because no one has cleaned it up yet, query-shutdown does seem
like a useful thing for libvirt to have at the time it reconnects to
that qemu process).

We could always include 'none' in the QAPI enum, then document in
'SHUTDOWN' and 'RESET' events that the cause will never be 'none'.  Doc
hacks like that feel a little unclean, but not so horrible as to be
unforgivable.

> 
> I'd be tempted to reshuffle declarations here, because shutdown_signal's
> int is a different one than reset_requested's and shutdown_requested,
> and the latter two's "negative means false, non-negative means true" is
> unusual enough to justify a comment.
...
> 
> Hmm.  In case we stick to literal -1: consider splitting this patch into
> a part that changes @shutdown_requested from zero/non-zero to
> negative/non-negative, and a part that uses ShutdownCause for the
> non-negative values.

You're definitely right that if the enum doesn't have a nice none=0
state, then reshuffling to the magic -1 as no request is awkward enough
to be done alone.

But part of the answer is also dependent on whether we want PATCH 4 or
not (or, as you brought up, the possibility of a query-shutdown command
with even more persistent storage of the last-reported event).

>> @@ -1650,11 +1650,11 @@ static void qemu_kill_report(void)
>>  static int qemu_reset_requested(void)
>>  {
>>  int r = reset_requested;
>> -if (r && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) {
>> -reset_requested = 0;
>> +if (r >= 0 && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) {
>> +reset_requested = -1;
>>  return r;
>>  }
>> -return false;
>> +return -1;
> 
> "return false" in a function returning int smells, good riddance.
> 

In one of my earlier drafts of the patch, I even tried to change the
return type from int to bool, but decided that keeping it as int worked
best (if I have to use the -1/cause dichotomy).  But you're also right
that with a 'none' value in the enum, I could directly return ShutdownCause.

>>  }
>>
>>  static int qemu_suspend_requested(void)
>> @@

Re: [Xen-devel] [PATCH 10/10 v2] xen/arm: vpl011: Update documentation for vuart console support

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> 1. Update documentation for vuart = "pl011" option added.
> 2. Update documentation about SPI irq reserved for vpl011.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
>  docs/man/xl.cfg.pod.5.in |  8 
>  docs/misc/console.txt| 14 +-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index 13167ff..44118a8 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1085,6 +1085,14 @@ Allow a guest to access specific physical IRQs.
>  It is recommended to use this option only for trusted VMs under
>  administrator control.
>  
> +If vuart console is enabled then irq 32 is reserved for vuart. By default
> +vuart console is disabled. If user specifies the following option in
> +the guest config file then vuart console is enabled.

Please rewrite this as:

  If the virtual uart is enabled then irq 32 is reserved for it. By
  default, it is disabled. If the user specifies the following option in
  the VM config file then the vuart gets enabled. Today, only the
  "pl011" model is supported.


> +vuart = "pl011"
> +
> +vuart console is currently enabled only for ARM64.
  ^ available


>  =item

Re: [Xen-devel] [PATCH 08/10 v2] xen/arm: vpl011: Add a new vuart console type to xenconsole client

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Add a new console type VUART to connect to guest vuart.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
>  tools/console/client/main.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/console/client/main.c b/tools/console/client/main.c
> index 99f..ec5c6e1 100644
> --- a/tools/console/client/main.c
> +++ b/tools/console/client/main.c
> @@ -76,7 +76,7 @@ static void usage(const char *program) {
>  "\n"
>  "  -h, --help   display this help and exit\n"
>  "  -n, --num N  use console number N\n"
> -"  --type TYPE  console type. must be 'pv' or 'serial'\n"
> +"  --type TYPE  console type. must be 'pv', 'serial' or 
> 'vuart'\n"
>  "  --start-notify-fd N file descriptor used to notify parent\n"
>  , program);
>  }
> @@ -264,6 +264,7 @@ typedef enum {
> CONSOLE_INVAL,
> CONSOLE_PV,
> CONSOLE_SERIAL,
> +   CONSOLE_VUART,
>  } console_type;
>  
>  static struct termios stdin_old_attr;
> @@ -361,6 +362,8 @@ int main(int argc, char **argv)
>   type = CONSOLE_SERIAL;
>   else if (!strcmp(optarg, "pv"))
>   type = CONSOLE_PV;
> + else if (!strcmp(optarg, "vuart"))
> + type = CONSOLE_VUART;
>   else {
>   fprintf(stderr, "Invalid type argument\n");
>   fprintf(stderr, "Console types supported are: 
> serial, pv\n");
> @@ -436,6 +439,9 @@ int main(int argc, char **argv)
>   else
>   snprintf(path, strlen(dom_path) + 
> strlen("/device/console/%d/tty") + 5, "%s/device/console/%d/tty", dom_path, 
> num);
>   }
> + if (type == CONSOLE_VUART) {
> + snprintf(path, strlen(dom_path) + strlen("/console/vtty") + 1, 
> "%s/console/vtty", dom_path);

It looks like this xenstore path is missing a description in patch #10.


> + }
>  
>   /* FIXME consoled currently does not assume domain-0 doesn't have a
>  console which is good when we break domain-0 up.  To keep us
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH 06/10 v2] xen/arm: vpl011: Add vuart ring-buf and evtchn to xenstore

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Add two new parameters to the xen store to be used by xenconsoled:
> - newly allocated PFN to be used as IN/OUT ring buffer
> - get a new event channel allocated by Xen using a domctl call
> 
> These paramters are added to xenstore only if vuart console is enabled
> by the user.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> 
> Changes since v1:
> - Modified the xenstore key names to /vuart/0/ring-ref and 
>   /vuart/0/port.
> - Replaced the hvm call with domctl call to get the event channel.
> 
>  tools/libxl/libxl_console.c | 10 ++
>  tools/libxl/libxl_dom.c |  4 
>  2 files changed, 14 insertions(+)
> 
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 446e766..ef3bd44 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -67,6 +67,9 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int 
> cons_num,
>  case LIBXL_CONSOLE_TYPE_SERIAL:
>  cons_type_s = "serial";
>  break;
> +case LIBXL_CONSOLE_TYPE_VUART:
> +cons_type_s = "vuart";
> +break;
>  default:
>  goto out;
>  }
> @@ -326,6 +329,13 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
> domid,
>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
> state->console_port));
>  flexarray_append(ro_front, "ring-ref");
>  flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
> +if (state->vuart_enabled)
> +{
> +flexarray_append(ro_front, "vuart/0/port");
> +flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
> state->vuart_port));
> +flexarray_append(ro_front, "vuart/0/ring-ref");
> +flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_mfn));
> +}

It looks like you are reusing the libxl__device_console_add call for the
main PV console for the domain, to also add the vuart nodes to xenstore.

I don't think it is a good idea to mix the two. I suggest to introduce a
new libxl__device call to introduce the vuart nodes to xenstore, given
that they have no relantionship with the principal PV console of the
domain.


>  } else {
>  flexarray_append(front, "state");
>  flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 5d914a5..06ff3b7 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -434,6 +434,9 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
> state->store_domid);
>  state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
> state->console_domid);
>  
> +if (state->vuart_enabled)
> +xc_domain_vuart_get_evtchn(ctx->xch, domid, >vuart_port);
> +
>  if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
>  hvm_set_conf_params(ctx->xch, domid, info);
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -788,6 +791,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
>  if (xc_dom_translated(dom)) {
>  state->console_mfn = dom->console_pfn;
>  state->store_mfn = dom->xenstore_pfn;
> +state->vuart_mfn = dom->vuart_pfn;
>  } else {
>  state->console_mfn = xc_dom_p2m(dom, dom->console_pfn);
>  state->store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);

These two changes to libxl_dom.c probably belong to patch #4

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

Re: [Xen-devel] [PATCH 05/10 v2] xen/arm: vpl011: Allocate a new PFN in the toolstack for vuart

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Allocate a new pfn and pass on to Xen using a domctl call.
> 
> Signed-off-by: Bhupinder Thakur 

Reviewed-by: Stefano Stabellini 


> 
> Changes since v1:
> - Replaced the hvm call with the domctl call to set the pfn.
> 
>  tools/libxc/include/xc_dom.h | 2 ++
>  tools/libxc/xc_dom_arm.c | 7 ++-
>  tools/libxc/xc_dom_boot.c| 2 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index ce47058..ca8bc23 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -216,6 +216,8 @@ struct xc_dom_image {
>  
>  /* Extra SMBIOS structures passed to HVMLOADER */
>  struct xc_hvm_firmware_module smbios_module;
> +
> +xen_pfn_t vuart_pfn;
>  };
>  
>  /* --- pluggable kernel loader - */
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index e7d4bd0..ad805d1 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -26,10 +26,11 @@
>  #include "xg_private.h"
>  #include "xc_dom.h"
>  
> -#define NR_MAGIC_PAGES 3
> +#define NR_MAGIC_PAGES 4
>  #define CONSOLE_PFN_OFFSET 0
>  #define XENSTORE_PFN_OFFSET 1
>  #define MEMACCESS_PFN_OFFSET 2
> +#define VUART_PFN_OFFSET 3
>  
>  #define LPAE_SHIFT 9
>  
> @@ -85,16 +86,20 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>  
>  dom->console_pfn = base + CONSOLE_PFN_OFFSET;
>  dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> +dom->vuart_pfn = base + VUART_PFN_OFFSET;
>  
>  xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
>  xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
>  xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
> MEMACCESS_PFN_OFFSET);
> +xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
> VUART_PFN_OFFSET);
>  xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
>  dom->console_pfn);
>  xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
>  dom->xenstore_pfn);
>  xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
>  base + MEMACCESS_PFN_OFFSET);
> +xc_domain_vuart_set_pfn(dom->xch, dom->guest_domid, base + 
> VUART_PFN_OFFSET);
> +
>  /* allocated by toolstack */
>  xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
>  dom->console_evtchn);
> diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
> index c3b44dd..5e4b322 100644
> --- a/tools/libxc/xc_dom_boot.c
> +++ b/tools/libxc/xc_dom_boot.c
> @@ -226,6 +226,8 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>  return rc;
>  if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
>  return rc;
> +if ( (rc = clear_page(dom, dom->vuart_pfn)) != 0 )
> +return rc;
>  
>  /* start info page */
>  if ( dom->arch_hooks->start_info )
> -- 
> 2.7.4
> 

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

[Xen-devel] [linux-linus test] 107869: regressions - trouble: broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 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-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  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-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux8b5d11e4b095450e2f259d5f60ea18c13d2fe0a2
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  659 days
Failing since 59348  2015-07-10 04:24:05 Z  658 days  412 attempts
Testing same since   107869  2017-04-28 07:58:01 Z0 days1 attempts


8182 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  fail
 test-armhf-armhf-xl  broken  
 test-amd64-i386-xl   pass

Re: [Xen-devel] [PATCH 04/10 v2] xen/arm: vpl011: Add support for vuart in libxl

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> An option is provided in libxl to enable/disable pl011 vuart while
> creating a guest domain.
> 
> Libxl now suppots a generic vuart console and pl011 is a specific type.
> In future support can be added for multiple vuart of different types.
> 
> User can enable pl011 vuart by adding the following line in the guest
> configuration file:
> 
> vuart = "pl011"
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> 
> Changes since v1:
> - Modified the syntax for taking the pl011 as a console type in the
>   configuration file. Now the syntax is vuart = "pl011".
> - Replaced the console type VCON with VUART, as it is more 
>   intuitive.
> 
>  tools/libxl/libxl.h  |  6 ++
>  tools/libxl/libxl_create.c   | 10 ++
>  tools/libxl/libxl_internal.h |  4 
>  tools/libxl/libxl_types.idl  |  2 ++
>  tools/xl/xl_console.c|  4 +++-
>  tools/xl/xl_parse.c  |  3 +++
>  6 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index cf8687a..bcfbb6c 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -306,6 +306,12 @@
>  #define LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE 1
>  
>  /*
> + * LIBXL_HAVE_VUART indicates that xenconsole/client supports
> + * virtual uart.
> + */
> +#define LIBXL_HAVE_VUART 1
> +
> +/*
>   * libxl ABI compatibility
>   *
>   * The only guarantee which libxl makes regarding ABI compatibility
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index bffbc45..5d70bc2 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -536,6 +536,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
> *d_config,
>  flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
>  }
>  
> +if (!strcmp(d_config->b_info.vuart, "pl011"))
> +flags |= XEN_DOMCTL_VUART_enable;
> +
>  /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
>  libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);
>  
> @@ -900,6 +903,11 @@ static void initiate_domain_create(libxl__egc *egc,
>  goto error_out;
>  }
>  
> +if (!strcmp(d_config->b_info.vuart, "pl011"))
> +state->vuart_enabled = true;
> +else
> +state->vuart_enabled = false;
> +
>  if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
>  (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
>  (libxl_defbool_val(d_config->b_info.u.hvm.altp2m) ||
> @@ -918,6 +926,8 @@ static void initiate_domain_create(libxl__egc *egc,
>  goto error_out;
>  }
>  
> +state->config.console_domid = state->console_domid;
> +
>  ret = libxl__domain_make(gc, d_config, , >config);
>  if (ret) {
>  LOGD(ERROR, domid, "cannot make domain: %d", ret);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 5d082c5..9dba8e7 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1135,6 +1135,10 @@ typedef struct {
>  uint32_t num_vmemranges;
>  
>  xc_domain_configuration_t config;
> +
> +unsigned long vuart_mfn;
> +uint32_tvuart_port;
> +boolvuart_enabled;
>  } libxl__domain_build_state;
>  
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 2204425..5d53f2c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -105,6 +105,7 @@ libxl_console_type = Enumeration("console_type", [
>  (0, "UNKNOWN"),
>  (1, "SERIAL"),
>  (2, "PV"),
> +(3, "VUART"),
>  ])
>  
>  libxl_disk_format = Enumeration("disk_format", [
> @@ -470,6 +471,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("disable_migrate", libxl_defbool),
>  ("cpuid",   libxl_cpuid_policy_list),
>  ("blkdev_start",string),
> +("vuart",   string),

I think it's best to store the vuart type as an enum rather than a
string, that would remove the strcmp calls from in
tools/libxl/libxl_create.c.


>  ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
>  
> diff --git a/tools/xl/xl_console.c b/tools/xl/xl_console.c
> index 0508dda..6f3cd7f 100644
> --- a/tools/xl/xl_console.c
> +++ b/tools/xl/xl_console.c
> @@ -34,8 +34,10 @@ int main_console(int argc, char **argv)
>  type = LIBXL_CONSOLE_TYPE_PV;
>  else if (!strcmp(optarg, "serial"))
>  type = LIBXL_CONSOLE_TYPE_SERIAL;
> +else if (!strcmp(optarg, "vuart"))
> +type = LIBXL_CONSOLE_TYPE_VUART;
>  else {
> -fprintf(stderr, "console type supported are: pv, serial\n");
> +fprintf(stderr, "console type supported are: pv, serial, 
> vuart\n");
>  return EXIT_FAILURE;
>  }
>  break;
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index

[Xen-devel] [qemu-mainline bisection] complete build-arm64-xsm

branch xen-unstable
xenbranch xen-unstable
job build-arm64-xsm
testid xen-build

Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  52e94ea5de3ed9d7ddf1b0e5fc6ff7c2807ae711
  Bug not present: fe491fa85c4634453b340b18046aae2eaf8147db
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107923/


  commit 52e94ea5de3ed9d7ddf1b0e5fc6ff7c2807ae711
  Merge: fe491fa 28b99f4
  Author: Peter Maydell 
  Date:   Wed Apr 26 10:22:31 2017 +0100
  
  Merge remote-tracking branch 
'remotes/sstabellini/tags/xen-20170421-v2-tag' into staging
  
  Xen 2017/04/21 + fix
  
  # gpg: Signature made Tue 25 Apr 2017 19:10:37 BST
  # gpg:using RSA key 0x894F8F4870E1AE90
  # gpg: Good signature from "Stefano Stabellini 
"
  # gpg: aka "Stefano Stabellini "
  # Primary key fingerprint: D04E 33AB A51F 67BA 07D3  0AEA 894F 8F48 70E1 
AE90
  
  * remotes/sstabellini/tags/xen-20170421-v2-tag: (21 commits)
move xen-mapcache.c to hw/i386/xen/
move xen-hvm.c to hw/i386/xen/
move xen-common.c to hw/xen/
add xen-9p-backend to MAINTAINERS under Xen
xen/9pfs: build and register Xen 9pfs backend
xen/9pfs: send responses back to the frontend
xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
xen/9pfs: receive requests from the frontend
xen/9pfs: connect to the frontend
xen/9pfs: introduce Xen 9pfs backend
9p: introduce a type for the 9p header
xen: import ring.h from xen
configure: use pkg-config for obtaining xen version
xen: additionally restrict xenforeignmemory operations
xen: use libxendevice model to restrict operations
xen: use 5 digit xen versions
xen: use libxendevicemodel when available
configure: detect presence of libxendevicemodel
xen: create wrappers for all other uses of xc_hvm_XXX() functions
xen: rename xen_modified_memory() to xen_hvm_modified_memory()
...
  
  Signed-off-by: Peter Maydell 
  
  commit 28b99f473bda682385da944b0404aedbe11ea0dc
  Author: Anthony Xu 
  Date:   Wed Apr 5 16:21:31 2017 -0700
  
  move xen-mapcache.c to hw/i386/xen/
  
  move xen-mapcache.c to hw/i386/xen/
  
  Signed-off -by: Anthony Xu 
  Reviewed-by: Stefano Stabellini 
  
  commit 93d43e7e11ad43f7aa1e648319385ecf289b1884
  Author: Anthony Xu 
  Date:   Wed Apr 5 16:21:30 2017 -0700
  
  move xen-hvm.c to hw/i386/xen/
  
  move xen-hvm.c to hw/i386/xen/
  
  Signed-off -by: Anthony Xu 
  Reviewed-by: Stefano Stabellini 
  
  commit 56e2cd24527867ac65aa86fc1820e5b700ccfa03
  Author: Anthony Xu 
  Date:   Wed Apr 5 16:21:29 2017 -0700
  
  move xen-common.c to hw/xen/
  
  move xen-common.c to hw/xen/
  
  Signed-off -by: Anthony Xu 
  Reviewed-by: Stefano Stabellini 
  
  commit d6a3f64ad3e8136758bc71e47f860974204c7a12
  Author: Stefano Stabellini 
  Date:   Wed Mar 22 10:18:09 2017 -0700
  
  add xen-9p-backend to MAINTAINERS under Xen
  
  Signed-off-by: Stefano Stabellini 
  Signed-off-by: Stefano Stabellini 
  Reviewed-by: Greg Kurz 
  CC: gr...@kaod.org
  CC: anthony.per...@citrix.com
  
  commit e737b6d5c3d69bde91c8cc554a8ce6d20e14feaa
  Author: Stefano Stabellini 
  Date:   Wed Mar 22 10:17:09 2017 -0700
  
  xen/9pfs: build and register Xen 9pfs backend
  
  Signed-off-by: Stefano Stabellini 
  Reviewed-by: Greg Kurz 
  CC: anthony.per...@citrix.com
  CC: jgr...@suse.com
  CC: Aneesh Kumar K.V 
  CC: Greg Kurz 
  
  commit 4476e09e34d4257d2bfbdb70d106a154f42c928b
  Author: Stefano Stabellini 
  Date:   Wed Mar 22 10:16:09 2017 -0700
  
  xen/9pfs: send responses back to the frontend
  
  Once a request is completed, xen_9pfs_push_and_notify gets called. In
  xen_9pfs_push_and_notify, update the indexes (data has already been
  copied to the sg by the common code) and send a notification to the
  frontend.
  
  Schedule the bottom-half to check if we already have any other requests
  pending.
  
  Signed-off-by: Stefano Stabellini 
  CC: anthony.per...@citrix.com
  CC: jgr...@suse.com
  CC:

Re: [Xen-devel] [PATCH v3 0/2][XTF] xtf/vpmu VPMU tests




On 04/25/2017 02:50 PM, Andrew Cooper wrote:

On 24/04/17 18:54, Mohit Gambhir wrote:

Mohit Gambhir (2):
   xtf/vpmu: Add Intel PMU MSR addresses
   xtf/vpmu: MSR read/write tests for VPMU

  arch/x86/include/arch/msr-index.h |  11 +
  tests/vpmu/Makefile   |   9 +
  tests/vpmu/main.c | 504 ++
  3 files changed, 524 insertions(+)
  create mode 100644 tests/vpmu/Makefile
  create mode 100644 tests/vpmu/main.c


Independently from the content of this series, how have you found the
XTF to use?  Any issues or unexpected corner cases which can be improved?
I think overall it was fairly easy to use and was very useful for the 
kind of testing we wanted to do for VPMU.
It helped me find 3 bugs - one hypervisor crash, one potential state 
leak and one missing functionality.
I didnt find any bugs/corner cases in XTF but here are the few nice to 
have features that you can consider adding -


1. As said in responses to one of the comments, I think it will be nice 
to have some kind of
"expected failure" return type that indicates that it is a known bug. 
Thats particularly
useful if the person writing the tests is not a Xen developer. You seem 
to have indicated
that xtf_error() means that it is a known error but that wasn't 
intuitive to me.


2. Its useful to print __LINE__ number from where an error/failure is 
reported.


3. Is test_main() considered 1 test?  If so it would be useful to define 
a test at a finer granularity.
For instance in VPMU case, each MSR test should really be a separate 
test. It would require
adding some semantics to names of the functions that define a test. That 
way, its easier to

keep track of the health of the software I think.

4. Is there a way to build just one test? Something like make 
test-hvm64-vpmu?


Thanks,
Mohit

~Andrew



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

Re: [Xen-devel] [PATCH 02/10 v2] xen/arm: vpl011: Add new vuart domctl interface to setup pfn and evtchn

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> 1. Add two new domctl API to:
> - Allocate a new event channel for sending/receiving events to/from Xen.
> - Map the PFN allocted by the toolstack to be used as IN/OUT ring buffers.
> 
> Xen will communicate with xenconsole over the ring buffer and the event
> channel to transmit and receive pl011 data on guest domain's behalf.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> 
> Changes since v1:
> 
> - Replaced the hvm interface with domctl interface
> 
>  tools/libxc/include/xenctrl.h | 26 ++
>  tools/libxc/xc_domain.c   | 39 +++
>  xen/arch/arm/domctl.c | 20 
>  xen/arch/x86/domctl.c |  4 
>  xen/include/public/domctl.h   | 11 +++
>  5 files changed, 100 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 1629f41..bebfe7d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -886,6 +886,32 @@ int xc_vcpu_getcontext(xc_interface *xch,
> vcpu_guest_context_any_t *ctxt);
>  
>  /**
> + * This function returns information about the pfn and the event channel
> + * to be used for setting up a virtual uart console.

"and the event channel", shouldn't it be one or the other? The
description should be "This function sets the pfn to be used for vuart
communications."


> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain to get information from
> + * @parm vuart_pfn the pfn to be used for the ring buffer
> + * @return 0 on success, negative error on failure
> + */
> +int xc_domain_vuart_set_pfn(xc_interface *xch,
> +uint32_t domid,
> +uint32_t vuart_pfn);
> +
> +/**
> + * This function returns information about the pfn and the event channel
> + * to be used for setting up a virtual console.

In this case you should remove the part on the pfn.


> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain to get information from
> + * @parm vuart_evtchn the event channel to be used for console events
> + * @return 0 on success, negative error on failure
> + */
> +int xc_domain_vuart_get_evtchn(xc_interface *xch,
> +   uint32_t domid,
> +   uint32_t *vuart_evtchn);
> +
> +/**
>   * This function returns information about the XSAVE state of a particular
>   * vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
>   * the call is considered a query to retrieve them and the buffer is not
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 00909ad4..943f202 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -343,6 +343,45 @@ int xc_domain_get_guest_width(xc_interface *xch, 
> uint32_t domid,
>  return 0;
>  }
>  
> +int xc_domain_vuart_set_pfn(xc_interface *xch,
> +uint32_t domid,
> +uint32_t vuart_pfn)
> +{
> +DECLARE_DOMCTL;
> +int rc = 0;
> +
> +domctl.cmd = XEN_DOMCTL_vuart_op;
> +domctl.domain = (domid_t)domid;
> +domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_SET_PFN;
> +domctl.u.vuart_op.pfn = vuart_pfn;
> +
> +if ( (rc = do_domctl(xch, )) < 0 )
> +return rc;
> +
> +return rc;
> +}
> +
> +int xc_domain_vuart_get_evtchn(xc_interface *xch,
> +   uint32_t domid,
> +   uint32_t *vuart_evtchn)
> +{
> +DECLARE_DOMCTL;
> +int rc = 0;
> +
> + *vuart_evtchn = -1;

tabs


> +domctl.cmd = XEN_DOMCTL_vuart_op;
> +domctl.domain = (domid_t)domid;
> +domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_GET_EVTCHN;
> +
> +if ( (rc = do_domctl(xch, )) < 0 )
> +return rc;
> +
> +*vuart_evtchn = domctl.u.vuart_op.evtchn;
> +
> +return rc;
> +}
> +
>  int xc_domain_getinfo(xc_interface *xch,
>uint32_t first_domid,
>unsigned int max_doms,
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 971caec..e400f87 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -119,6 +120,25 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
> domain *d,
>  d->disable_migrate = domctl->u.disable_migrate.disable;
>  return 0;
>  
> +case XEN_DOMCTL_vuart_op:
> +{
> +int rc;
> +if ( d->arch.vpl011.initialized )
> +{
> +if ( domctl->u.vuart_op.cmd == XEN_DOMCTL_VUART_OP_SET_PFN )
> +{
> +rc = vpl011_map_guest_page(d, domctl->u.vuart_op.pfn);
> +}
> +else
> +{
> +domctl->u.vuart_op.evtchn = d->arch.vpl011.evtchn;
> +

Re: [Xen-devel] [PATCH 03/10 v2] xen/arm: vpl011: Enable pl011 emulation for a guest domain in Xen

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Vpl011 emulation is enabled for a guest domain in Xen only when it is
> enabled through an option in libxl provided by the user through
> guest configuration.
> 
> The pl011 enable/disable knob in libxl is introduced in the following
> patch:
> 
> xen/arm: vpl011: Add support for vuart in libxl
> 
> Signed-off-by: Bhupinder Thakur 
> ---
>  xen/arch/arm/domain.c   | 6 ++
>  xen/common/domctl.c | 3 +++
>  xen/include/public/domctl.h | 2 ++
>  xen/include/xen/sched.h | 4 
>  4 files changed, 15 insertions(+)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 76310ed..23baa81 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include "vtimer.h"
>  #include "vuart.h"
> +#include 
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  if ( (rc = domain_vtimer_init(d, config)) != 0 )
>  goto fail;
>  
> +if ( domcr_flags & DOMCRF_vuart )
> +if ( (rc = domain_vpl011_init(d, config)) != 0 )
> +goto fail;
>  update_domain_wallclock_time(d);
>  
>  /*
> @@ -665,6 +669,8 @@ fail:
>  
>  void arch_domain_destroy(struct domain *d)
>  {
> +domain_vpl011_deinit(d);
> +
>  /* IOMMU page table is shared with P2M, always call
>   * iommu_domain_destroy() before p2m_teardown().
>   */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 951a5dc..902dd71 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -501,6 +501,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
> | XEN_DOMCTL_CDF_hap
> | XEN_DOMCTL_CDF_s3_integrity
> | XEN_DOMCTL_CDF_oos_off
> +   | XEN_DOMCTL_VUART_enable
> | XEN_DOMCTL_CDF_xs_domain)) )

Please place XEN_DOMCTL_VUART_enable at last item. Aside from this:

Reviewed-by: Stefano Stabellini 


>  break;
>  
> @@ -539,6 +540,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  domcr_flags |= DOMCRF_oos_off;
>  if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_xs_domain )
>  domcr_flags |= DOMCRF_xs_domain;
> +if ( op->u.createdomain.flags & XEN_DOMCTL_VUART_enable )
> +domcr_flags |= DOMCRF_vuart;
>  
>  d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
>>u.createdomain.config);
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 8bee0c3..c307013 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -63,6 +63,8 @@ struct xen_domctl_createdomain {
>   /* Is this a xenstore domain? */
>  #define _XEN_DOMCTL_CDF_xs_domain 4
>  #define XEN_DOMCTL_CDF_xs_domain  (1U<<_XEN_DOMCTL_CDF_xs_domain)
> +#define _XEN_DOMCTL_VUART_enable  6
> +#define XEN_DOMCTL_VUART_enable   (1U<<_XEN_DOMCTL_VUART_enable)
>  uint32_t flags;
>  struct xen_arch_domainconfig config;
>  };
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 1127ca9..ee7dc7a 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -555,6 +555,10 @@ struct domain *domain_create(domid_t domid, unsigned int 
> domcr_flags,
>  #define _DOMCRF_xs_domain   5
>  #define DOMCRF_xs_domain(1U<<_DOMCRF_xs_domain)
>  
> + /* DOMCRF_vuart: enable virtual uart emulation. Used for Aarch64. */
> +#define _DOMCRF_vuart  7
> +#define DOMCRF_vuart   (1U<<_DOMCRF_vuart)
> +
>  /*
>   * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
>   * This is the preferred function if the returned domain reference
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH 01/10 v2] xen/arm: vpl011: Add pl011 uart emulation in Xen

On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
> Add emulation code to emulate read/write access to pl011 registers
> and pl011 interrupts:
> 
> - Emulate DR read/write by reading and writing from/to the IN
>   and OUT ring buffers and raising an event to the backend when
>   there is data in the OUT ring buffer and injecting an interrupt
>   to the guest when there is data in the IN ring buffer
> 
> - Other registers are related to interrupt management and
>   essentially control when interrupts are delivered to the guest
> 
> The SBSA compliant pl011 uart is covered in Appendix B of
> https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> 
> Changes since v1:
> 
> - Removed the optimiztion related to sendiing events to xenconsole 
> - Use local variables as ring buffer indices while using the ring buffer
> 
>  xen/arch/arm/Kconfig |   5 +
>  xen/arch/arm/Makefile|   1 +
>  xen/arch/arm/vpl011.c| 340 
> +++
>  xen/include/asm-arm/domain.h |   3 +
>  xen/include/asm-arm/pl011-uart.h |   2 +
>  xen/include/public/arch-arm.h|   8 +
>  xen/include/xen/vpl011.h |  74 +
>  7 files changed, 433 insertions(+)
>  create mode 100644 xen/arch/arm/vpl011.c
>  create mode 100644 xen/include/xen/vpl011.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index d46b98c..c1a0e7f 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -50,6 +50,11 @@ config HAS_ITS
>  prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
>  depends on HAS_GICV3
>  
> +config VPL011_CONSOLE
> + bool "Emulated pl011 console support"
> + default y
> + ---help---
> +   Allows a guest to use pl011 UART as a console
>  endmenu
>  
>  menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 49e1fb2..15efc13 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -52,6 +52,7 @@ obj-y += vm_event.o
>  obj-y += vtimer.o
>  obj-y += vpsci.o
>  obj-y += vuart.o
> +obj-$(CONFIG_VPL011_CONSOLE) += vpl011.o
>  
>  #obj-bin-y += o
>  
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> new file mode 100644
> index 000..51abade
> --- /dev/null
> +++ b/xen/arch/arm/vpl011.c
> @@ -0,0 +1,340 @@
> +/*
> + * arch/arm/vpl011.c
> + *
> + * Virtual PL011 UART
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
> +
> +static void vgic_inject_vpl011_spi(struct domain *d)
> +{
> +struct vpl011_s *vpl011 = >arch.vpl011;
> +
> +if ( (vpl011->uartris & vpl011->uartimsc) )
> +vgic_vcpu_inject_spi(d, GUEST_VPL011_SPI);
> +}
> +
> +static void vpl011_read_data(struct domain *d, uint8_t *data)
> +{
> +unsigned long flags;
> +struct vpl011_s *vpl011 = >arch.vpl011;
> +struct xencons_interface *intf = vpl011->ring_buf;
> +
> +/*
> + * Initialize the data so that even if there is no data in ring buffer
> + * 0 is returned.
> + */
> +*data = 0;
> +
> +VPL011_LOCK(d, flags);
> +
> +/*
> + * It is expected that there will be data in the ring buffer when this
> + * function is called since the guest is expected to read the data 
> register
> + * only if the TXFE flag is not set.
> + * If the guest still does read when TXFE bit is set then 0 will be 
> returned.
> + */
> +if ( !VPL011_IN_RING_EMPTY(intf) )
> +{
> +uint32_t in_cons = intf->in_cons;

Use XENCONS_RING_IDX for the indexes type everywhere in this file.


> +*data = intf->in[MASK_XENCONS_IDX(in_cons, intf->in)];
> +smp_mb();
> +intf->in_cons = in_cons + 1;
> +}
> +
> +if ( VPL011_IN_RING_EMPTY(intf) )
> +{
> +vpl011->uartfr |= (RXFE);
> +vpl011->uartris &= ~(RXI);
> +}
> +vpl011->uartfr &= ~(RXFF);
> +VPL011_UNLOCK(d, flags);
> +
> +notify_via_xen_event_channel(d, vpl011->evtchn);
> +}
> +
> +static void vpl011_write_data(struct domain *d, uint8_t data)
> +{
> +unsigned long flags;
> +struct

[Xen-devel] [PATCH v2 1/2] xtf/vpmu: Add Intel PMU MSR addresses

This patch adds Intel PMU MSR addresses as macros for VPMU testing

Signed-off-by: Mohit Gambhir 
---
 arch/x86/include/arch/msr-index.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/include/arch/msr-index.h 
b/arch/x86/include/arch/msr-index.h
index 72373c6..911d7f9 100644
--- a/arch/x86/include/arch/msr-index.h
+++ b/arch/x86/include/arch/msr-index.h
@@ -3,6 +3,8 @@
 
 #include 
 
+#define MSR_PMC(n)  (0x00c1 + (n))
+
 #define MSR_INTEL_PLATFORM_INFO 0x00ce
 #define _MSR_PLATFORM_INFO_CPUID_FAULTING   31
 #define MSR_PLATFORM_INFO_CPUID_FAULTING(1ULL << 
_MSR_PLATFORM_INFO_CPUID_FAULTING)
@@ -11,10 +13,20 @@
 #define _MSR_MISC_FEATURES_CPUID_FAULTING0
 #define MSR_MISC_FEATURES_CPUID_FAULTING (1ULL << 
_MSR_MISC_FEATURES_CPUID_FAULTING)
 
+#define MSR_PERFEVTSEL(n)   (0x0186 + (n))
+
 #define MSR_DEBUGCTL0x01d9
 #define _MSR_DEBUGCTL_LBR   0 /* Last Branch Record. */
 #define MSR_DEBUGCTL_LBR(_AC(1, L) << _MSR_DEBUGCTL_LBR)
 
+#define MSR_FIXED_CTR(n)(0x0309 + (n))
+#define MSR_PERF_CAPABILITIES   0x0345
+#define MSR_FIXED_CTR_CTRL  0x038d
+#define MSR_PERF_GLOBAL_STATUS  0x038e
+#define MSR_PERF_GLOBAL_CTRL0x038f
+#define MSR_PERF_GLOBAL_OVF_CTRL0x0390
+#define MSR_A_PMC(n)(0x04c1 + (n))
+
 #define MSR_EFER0xc080 /* Extended Feature 
register. */
 #define _EFER_SCE   0  /* SYSCALL Enable. */
 #define EFER_SCE(_AC(1, L) << _EFER_SCE)
-- 
2.9.3


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

[Xen-devel] [PATCH v2 2/2] xtf/vpmu: MSR read/write tests for VPMU

This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.

The tests are currently unsupported for AMD machines and PV guests.

Signed-off-by: Mohit Gambhir 
---
 tests/vpmu/Makefile |   9 ++
 tests/vpmu/main.c   | 442 
 2 files changed, 451 insertions(+)
 create mode 100644 tests/vpmu/Makefile
 create mode 100644 tests/vpmu/main.c

diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
new file mode 100644
index 000..57eb29d
--- /dev/null
+++ b/tests/vpmu/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME  := vpmu
+CATEGORY  := functional
+TEST-ENVS := hvm64 hvm32
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
diff --git a/tests/vpmu/main.c b/tests/vpmu/main.c
new file mode 100644
index 000..b7f9398
--- /dev/null
+++ b/tests/vpmu/main.c
@@ -0,0 +1,442 @@
+/**
+ * @file tests/vpmu/main.c
+ * @ref test-vpmu
+ *
+ * @page test-vpmu vpmu
+ *
+ * Test Virtual Performance Monitoring Unit implementation, which allows 
guests 
+ * to program fixed and general purpose performance counters to measure 
hardware
+ * performance. 
+ *
+ * The tests read and write MSRs that are  exposed by VPMU for various versions
+ * of Architectural Performance Monitoring
+ *
+ * @see tests/vpmu/main.c
+ */
+
+#include 
+#include 
+#include 
+
+#define EVENT_UOPS_RETIRED   0x004101c2
+#define EVENT_UOPS_RETIRED_ANYTHREAD 0x006101c2
+#define FIXED_CTR_CTL_BITS   4
+#define FIXED_CTR_ENABLE 0x000A
+#define FIXED_CTR_ENABLE_ANYTHREAD   0x000E
+#define PERFEVENTSELx_ENABLE_ANYTHREAD   (1ull << 21)
+#define PERFEVENTSELx_ENABLE_PCB (1ull << 19)
+#define DEBUGCTL_Freeze_LBR_ON_PMI   (1ull << 11)
+#define DEBUGCTL_Freeze_PerfMon_On_PMI   (1ull << 12)
+#define PERF_CAPABILITIES_Full_Width (1ull << 13)
+
+const char test_title[] = "Test vpmu";
+
+static void test_valid_msr_write(uint32_t idx, uint64_t wval)
+{
+uint64_t rval = 0;
+
+if( wrmsr_safe(idx, wval) )
+xtf_failure("Fail: wrmsr(0x%08x, 0x%016"PRIx64") got unexpected fault"
+"\n", idx, wval);
+
+/* check to see if the values were written correctly */
+if ( rdmsr_safe(idx, ) )
+xtf_failure("Fail: rdmsr(0x%08x, 0x016%"PRIxPTR") got unexpected fault"
+"\n", idx, (uintptr_t) );
+
+if ( rval != wval )
+xtf_failure("Fail: rdmsr mismatch idx 0x%08x, wval 0x%016"PRIx64
+", rval 0x%016"PRIx64"\n", idx, wval, rval);
+}
+
+static void test_invalid_msr_write(uint32_t idx, uint64_t wval)
+{
+/* wrmsr_safe must return false after faulting */
+if( !wrmsr_safe(idx, wval) )
+xtf_failure("Fail: wrmsr(0x%08x, 0x%016"PRIx64") did not fault.\n", 
+idx, wval);
+}
+
+static void test_transparent_msr_write(uint32_t idx, uint64_t wval)
+{
+uint64_t rval1 = 0, rval2 = 0;
+
+/* read current value */
+if ( rdmsr_safe(idx, ) )
+xtf_failure("Fail: rdmsr(0x%08x, 0x016%"PRIxPTR") got unexpected fault"
+"\n", idx, (uintptr_t));
+
+/* wrmsr should not fault but should not write anything either */
+if  ( wrmsr_safe(idx, wval) )
+xtf_failure("Fail: wrmsr(0x%08x, 0x%016"PRIx64") got unexpected fault"
+"\n", idx, wval);
+
+/* read new value */
+if ( rdmsr_safe(idx, ) )
+xtf_failure("Fail: rdmsr(0x%08x, 0x016%"PRIxPTR") got unexpected fault"
+"\n", idx, (uintptr_t) );
+
+/* Check if the new value is the same as the one before wrmsr */
+if ( rval1 != rval2 )
+xtf_failure("Fail: rdmsr mismatch idx 0x%08x, wval 0x%016"PRIx64
+", rval 0x%016"PRIx64"\n", idx, rval1, rval2);
+}
+
+static void test_intel_pmu_ver1(uint8_t ng)
+{
+/* 
+ * Intel Sofwtare Development Manual Vol. 3B,
+ * Section 18.2.1 - Architectural Performance Monitoring Version 1
+ *
+ * MSRs made available by the VPMU
+ *
+ * PMCx (start at address 0xc1)
+ * PERFEVENTSELx (start at address 0x186)
+ */
+
+uint32_t idx;
+uint64_t wval = 0;
+unsigned i;
+
+printk("Testing version 1\n");
+
+/* for all general purpose counters */
+for ( i = 0; i < ng; i++ )
+{
+/* test writing to PMCx */
+idx = MSR_PMC(i);
+
+/* 
+ * test we can write to all valid bits in the counters
+ * don't set bit 31 since that gets sign-extended
+ */
+wval = ((1ull << 31) - 1) ;
+
+test_valid_msr_write(idx, wval);
+
+/* set all valid bits in MSR_EVENTSELx */
+idx = MSR_PERFEVTSEL(i);
+wval = ((1ull << 32) - 1) ^

[Xen-devel] [PATCH v2 0/2] xtf/vpmu VPMU tests

v2: 

Incorporated review comments received on patch v1. 

+ Changed test type from utility to functional
+ Test is now defined only for hvm64 and hvm32 instead of ALL_ENVIRONMENTS
+ Several code styling and formatting changes
+ Expanded test description for doxygen
+ Added max_leaf check before cpuid_count
+ Addded PDCM bit check before reading MSR_PERF_CAPABILTIES

v1: 

This patch series adds tests to validate VPMU functionality on x86. The tests
write and read PMU MSRs to make sure that that they have been exposed
correctly.

The ultimate goal is to address security vulnerabilities, if any, that are
vaguely mentioned in XSA-163 and make VPMU available to guests with reasonable
caveats.

Further testing is required to validate the MSR state save/restore functionality
of the VPMU, concurrent usage of the counters by a number of guests and analyze
if any other non-PMU MSRs have been exposed incorrectly.

Mohit Gambhir (2):
  xtf/vpmu: Add Intel PMU MSR addresses
  xtf/vpmu: MSR read/write tests for VPMU

 arch/x86/include/arch/msr-index.h |  12 ++
 tests/vpmu/Makefile   |   9 +
 tests/vpmu/main.c | 433 ++
 3 files changed, 454 insertions(+)
 create mode 100644 tests/vpmu/Makefile
 create mode 100644 tests/vpmu/main.c

-- 
2.9.3


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

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

* Eric Blake (ebl...@redhat.com) wrote:
> On 04/28/2017 11:09 AM, Dr. David Alan Gilbert wrote:
> 
> >>> At a higher level, using your tags, I'm not sure where a reset triggered
> >>> by a fault detected by the hypervisor lives - e.g. an x86 triple fault
> >>> where the guest screws up so badly that it just gets reset.  Is
> >>> that a guest-reset or a guest-panic or what - neither case
> >>> was actually asked for by the guest itself.
> >>
> >> Wouldn't that be host-error (qemu detected an error that prevents
> >> further execution of the guest without a reset - and a triple fault
> >> seems to fall into the category of the guest getting itself wedged
> >> rather than actually trying to reset)?  Except patch 3 only used
> >> SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.
> >>
> >> So if any x86 expert has an opinion on where triple-fault handling is
> >> emulated, and what category should be used there, I'm welcome to
> >> tweaking this series.
> > 
> > It's pretty much on the border anyway, I don't think it matters too
> > much; it sounds perfectly reasonable.
> 
> Actually, reading
> https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-syscall-trap-redux/
> makes it sound like the triple-fault = reset is exploited by existing OS
> (dating back to days of targetting 286 machines), so it is bare-metal
> behavior that we have to faithfully emulate as a guest-triggered reset,
> and not something where the guest has wedged itself to the point where
> qemu can no longer execute the guest.

The point is it's both :-)
A lot of x86 reset code tries four or five different ways to invoke
a reset and if all else fails they triple fault.

Dave

> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 



--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

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

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

On 04/28/2017 11:09 AM, Dr. David Alan Gilbert wrote:

>>> At a higher level, using your tags, I'm not sure where a reset triggered
>>> by a fault detected by the hypervisor lives - e.g. an x86 triple fault
>>> where the guest screws up so badly that it just gets reset.  Is
>>> that a guest-reset or a guest-panic or what - neither case
>>> was actually asked for by the guest itself.
>>
>> Wouldn't that be host-error (qemu detected an error that prevents
>> further execution of the guest without a reset - and a triple fault
>> seems to fall into the category of the guest getting itself wedged
>> rather than actually trying to reset)?  Except patch 3 only used
>> SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.
>>
>> So if any x86 expert has an opinion on where triple-fault handling is
>> emulated, and what category should be used there, I'm welcome to
>> tweaking this series.
> 
> It's pretty much on the border anyway, I don't think it matters too
> much; it sounds perfectly reasonable.

Actually, reading
https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-syscall-trap-redux/
makes it sound like the triple-fault = reset is exploited by existing OS
(dating back to days of targetting 286 machines), so it is bare-metal
behavior that we have to faithfully emulate as a guest-triggered reset,
and not something where the guest has wedged itself to the point where
qemu can no longer execute the guest.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [Xen-devel] [PATCH] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

2017-04-28 Thread Juergen Gross

On 24/04/17 21:04, Boris Ostrovsky wrote:
> Recent discussion (http://marc.info/?l=xen-devel=149192184523741)
> established that commit 72a9b186292d ("xen: Remove event channel
> notification through Xen PCI platform device") (and thus commit
> da72ff5bfcb0 ("partially revert "xen: Remove event channel
> notification through Xen PCI platform device"")) are unnecessary and,
> in fact, prevent HVM guests from booting on Xen releases prior to 4.0
> 
> Therefore we revert both of those commits.
> 
> The summary of that discussion is below:
> 
>   Here is the brief summary of the current situation:
> 
>   Before the offending commit (72a9b186292):
> 
>   1) INTx does not work because of the reset_watches path.
>   2) The reset_watches path is only taken if you have Xen > 4.0
>   3) The Linux Kernel by default will use vector inject if the hypervisor
>  support. So even INTx does not work no body running the kernel with
>  Xen > 4.0 would notice. Unless he explicitly disabled this feature
>  either in the kernel or in Xen (and this can only be disabled by
>  modifying the code, not user-supported way to do it).
> 
>   After the offending commit (+ partial revert):
> 
>   1) INTx is no longer support for HVM (only for PV guests).
>   2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
>  not have vector injection support. Since the only other mode
>  supported is INTx which.
> 
>   So based on this summary, I think before commit (72a9b186292) we were
>   in much better position from a user point of view.
> 
> Signed-off-by: Boris Ostrovsky 

Pushed to xen/tip for-linus-4.12


Juergen


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

Re: [Xen-devel] [PATCH] xen/x86: Call xen_smp_intr_init_pv() on BSP

2017-04-28 Thread Juergen Gross

On 26/04/17 15:42, Boris Ostrovsky wrote:
> Recent code rework that split handling ov PV, HVM and PVH guests into
> separate files missed calling xen_smp_intr_init_pv() on CPU0.
> 
> Add this call.
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Sander Eikelenboom 

Pushed to xen/tip for-linus-4.12


Juergen

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

Re: [Xen-devel] [PATCH 1/3 v2] xen: Export xen_reboot

2017-04-28 Thread Juergen Gross

On 25/04/17 06:02, Juergen Gross wrote:
> On 24/04/17 20:21, Boris Ostrovsky wrote:
>> On 04/24/2017 01:58 PM, Julien Grall wrote:
>>> The helper xen_reboot will be called by the EFI code in a later patch.
>>>
>>> Note that the ARM version does not yet exist and will be added in a
>>> later patch too.
>>>
>>> Signed-off-by: Julien Grall 
>>
>> I don't think these changes are worth a whole patch. They can be folded
>> into the third patch.
> 
> No, the 2nd patch needs this, too.
> 
> So:
> 
> Reviewed-by: Juergen Gross 

Julien, this patch no longer applies to the for-linus-4.12 branch of
xen/tip. Can you please rebase?


Juergen


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

[Xen-devel] [xen-unstable-smoke test] 107904: tolerable trouble: broken/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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  ba39e9b2108319d2b7b842781106386b8ed62fab
baseline version:
 xen  0a5370ee1f9808fbb16bb03d7f349921cf73a2d4

Last test of basis   107720  2017-04-26 16:01:20 Z2 days
Testing same since   107904  2017-04-28 15:01:26 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=ba39e9b2108319d2b7b842781106386b8ed62fab
+ . ./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 
ba39e9b2108319d2b7b842781106386b8ed62fab
+ branch=xen-unstable-smoke
+ revision=ba39e9b2108319d2b7b842781106386b8ed62fab
+ . ./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.8-testing
+ '[' xba39e9b2108319d2b7b842781106386b8ed62fab = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ :

Re: [Xen-devel] Xen 4.9.0 RC3

2017-04-28 Thread Pry Mar

Hello,

the tarball has not been uploaded to the URL in the mail.

Its 4pm BST when I send this, so maybe there is still time before everyone
leaves for the weekend.

Is it possible to post an xz tarball with a Debian delta naming scheme?
Something like:
xen_4.9~rc3.orig.tar.xz

thanks,
PryMar56
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

* Eric Blake (ebl...@redhat.com) wrote:
> On 04/28/2017 10:27 AM, Dr. David Alan Gilbert wrote:
> 
>  +# Enumeration of various causes for shutdown.
>  +#
>  +# @host-qmp: Reaction to a QMP command, such as 'quit'
>  +# @host-signal: Reaction to a signal, such as SIGINT
>  +# @host-ui: Reaction to a UI event, such as closing the window
>  +# @host-replay: The host is replaying an earlier shutdown event
>  +# @host-error: Qemu encountered an error that prevents further use of 
>  the guest
>  +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
>  +#  other hardware-specific action
>  +# @guest-reset: The guest requested a reset, and the command line
>  +#   response to a reset is to instead trigger a shutdown
>  +# @guest-panic: The guest panicked, and the command line response to
>  +#   a panic is to trigger a shutdown
> >>>
> 
> > At a higher level, using your tags, I'm not sure where a reset triggered
> > by a fault detected by the hypervisor lives - e.g. an x86 triple fault
> > where the guest screws up so badly that it just gets reset.  Is
> > that a guest-reset or a guest-panic or what - neither case
> > was actually asked for by the guest itself.
> 
> Wouldn't that be host-error (qemu detected an error that prevents
> further execution of the guest without a reset - and a triple fault
> seems to fall into the category of the guest getting itself wedged
> rather than actually trying to reset)?  Except patch 3 only used
> SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.
> 
> So if any x86 expert has an opinion on where triple-fault handling is
> emulated, and what category should be used there, I'm welcome to
> tweaking this series.

It's pretty much on the border anyway, I don't think it matters too
much; it sounds perfectly reasonable.

Dave

> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 



--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

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

[Xen-devel] [PATCH 08/10 v2] xen/arm: vpl011: Add a new vuart console type to xenconsole client

Add a new console type VUART to connect to guest vuart.

Signed-off-by: Bhupinder Thakur 
---
 tools/console/client/main.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index 99f..ec5c6e1 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -76,7 +76,7 @@ static void usage(const char *program) {
   "\n"
   "  -h, --help   display this help and exit\n"
   "  -n, --num N  use console number N\n"
-  "  --type TYPE  console type. must be 'pv' or 'serial'\n"
+  "  --type TYPE  console type. must be 'pv', 'serial' or 
'vuart'\n"
   "  --start-notify-fd N file descriptor used to notify parent\n"
   , program);
 }
@@ -264,6 +264,7 @@ typedef enum {
CONSOLE_INVAL,
CONSOLE_PV,
CONSOLE_SERIAL,
+   CONSOLE_VUART,
 } console_type;
 
 static struct termios stdin_old_attr;
@@ -361,6 +362,8 @@ int main(int argc, char **argv)
type = CONSOLE_SERIAL;
else if (!strcmp(optarg, "pv"))
type = CONSOLE_PV;
+   else if (!strcmp(optarg, "vuart"))
+   type = CONSOLE_VUART;
else {
fprintf(stderr, "Invalid type argument\n");
fprintf(stderr, "Console types supported are: 
serial, pv\n");
@@ -436,6 +439,9 @@ int main(int argc, char **argv)
else
snprintf(path, strlen(dom_path) + 
strlen("/device/console/%d/tty") + 5, "%s/device/console/%d/tty", dom_path, 
num);
}
+   if (type == CONSOLE_VUART) {
+   snprintf(path, strlen(dom_path) + strlen("/console/vtty") + 1, 
"%s/console/vtty", dom_path);
+   }
 
/* FIXME consoled currently does not assume domain-0 doesn't have a
   console which is good when we break domain-0 up.  To keep us
-- 
2.7.4


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

[Xen-devel] [PATCH 00/10 v2] pl011 emulation support in Xen

PL011 emulation for guests in Xen
===
Linaro has published VM System specification for ARM Processors, which
provides a set of guidelines for both guest OS and hypervisor implementations,
such that building OS images according to these guidelines guarantees
that those images can also run on hypervisors compliant with this specification.

One of the spec requirements is that the hypervisor must provide an
emulated PL011 UART as a serial console which meets the minimum requirements in
SBSA UART as defined in appendix B of the following ARM Server Base
Architecture Document:

https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf.

This feature allows the Xen guests to use SBSA compliant pl011 UART as
as a console.

Note that SBSA pl011 UART is a subset of full featured ARM pl011 UART and
supports only a subset of registers as mentioned below. It does not support
rx/tx DMA.

Currently, Xen supports paravirtualized (aka PV console) and an emulated serial
consoles. This feature will expose an emulated SBSA pl011 UART console to the
guest, which a user can access using xenconsole.

The device tree passed to the guest VM will contain the pl011 MMIO address
range and an irq for receiving rx/tx pl011 interrupts. The device tree format
is specified in Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt.

The Xen hypervisor will expose two types of interfaces to the backend and domU.

The interface exposed to domU will be an emulated pl011 UART by emulating the
access to the following pl011 registers by the guest.

- Data register (DR)- RW
- Raw interrupt status register (RIS) - RO
- Masked interrupt status register (MIS)- RO
- Interrupt Mask (IMSC) - RW
- Interrupt Clear (ICR) - WO

It will also inject the pl011 interrupts to the guest in the following
conditions:

- incoming data in the rx buffer for the guest
- there is space in the tx buffer for the guest to write more data

The interface exposed to the backend will be the same PV console interface,
which minimizes the changes required in xenconsole to support a new pl011
console.

This interface has rx and tx ring buffers and an event channel for
sending/receiving events from the backend.

So essentially Xen handles the data on behalf of domU and the backend. Any data
written by domU is captured by Xen and written to the TX (OUT) ring buffer
and a pl011 event is raised to the backend to read the TX ring buffer.

Similarly on reciving a pl011 event, Xen injects an interrupt to guest to
indicate there is data available in the RX (IN) ring buffer.

Note that the pl011 UART state is completely captured in the set of registers
mentioned above and this state is updated everytime there is an event from
the backend or there is register read/write access from domU.

For example, if domU has masked the rx interrupt in the IMSC register, then Xen
will not inject an interrupt to guest and will just update the RIS register.
Once the interrupt is unmasked by guest, the interrupt will be delivered to the
guest.

Changes summary:

Xen Hypervisor
===

1. Add emulation code to emulate read/write access to pl011 registers and pl011
interrupts:
- It emulates DR read/write by reading and writing from/to the IN and
OUT ring buffers and raising an event to dom0 when there is data in
the OUT ring buffer and injecting an interrupt to the guest when there
is data in the IN ring buffer.
- Other registers are related to interrupt management and essentially
control when interrupts are delivered to the guest.

2. Add two new domctl API to set and get pfn and evtchn respectively
- Allocate a new event channel for sending/receiving events from Xen
and return to the toolstack.
- Map the PFN allocted by the toolstack to be used as IN/OUT ring
buffers.

3. Enable vpl011 emulation for a domain based on a libxl option passed during
domain creation.

Toolstack
==

1. Create a sbsa uart DT node in the guest device tree. It uses a fixed
vpl011 SPI IRQ number and MMIO address.

2. Allocate a new PFN and pass it on to Xen though a hvm call to be used
as the IN/OUT ring buffers.

3. Add two new keys to the xen store
- Allocate a PFN to be used as IN/OUT ring buffer by xenconsoled
- Read new event channel from Xen using a hvm call to be used by
xenconsoled for sending/receiving events.

Xenconsoled

1. Split the domain structure to support multiple consoles.

2. Modify different APIs such as buffer_append() etc. to operate on the
console structure.

3. Modfications in domain_create_ring():
- Bind to the vpl011 event channel obtained from the xen store as a new
parameter
- Map the PFN to its address space to be used as IN/OUT ring buffers.
It obtains the PFN from the xen store as a new parameter

4. Modifications in

[Xen-devel] [PATCH 10/10 v2] xen/arm: vpl011: Update documentation for vuart console support

1. Update documentation for vuart = "pl011" option added.
2. Update documentation about SPI irq reserved for vpl011.

Signed-off-by: Bhupinder Thakur 
---
 docs/man/xl.cfg.pod.5.in |  8 
 docs/misc/console.txt| 14 +-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 13167ff..44118a8 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1085,6 +1085,14 @@ Allow a guest to access specific physical IRQs.
 It is recommended to use this option only for trusted VMs under
 administrator control.
 
+If vuart console is enabled then irq 32 is reserved for vuart. By default
+vuart console is disabled. If user specifies the following option in
+the guest config file then vuart console is enabled.
+
+vuart = "pl011"
+
+vuart console is currently enabled only for ARM64.
+
 =item

[Xen-devel] [PATCH 09/10 v2] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

The SBSA uart node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:

ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and consequently lives
in the PL011 driver. It's baudrate and other communication parameters
cannot be adjusted at runtime, so it lacks a clock specifier here.

Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier
- current-speed: the (fixed) baud rate set by the firmware

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Stefano Stabellini 
---

Changes since v1:
- Modified the code to increment nr_spis based on the SPI value reserved for
  vpl011.
- Added a check to verify that physical irq assigment is not conflicting with
  vpl011 SPI.
- Fixed minor indentation issues.

 tools/libxl/libxl_arm.c | 54 +++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d88..45a56a8 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -43,11 +43,25 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 {
 uint32_t nr_spis = 0;
 unsigned int i;
+bool vpl011_enabled = !strcmp(d_config->b_info.vuart, "pl011");
+
+/*
+ * If pl011 vuart is enabled then increment the nr_spis to allow allocation
+ * of SPI VIRQ for pl011.
+ */
+if (vpl011_enabled)
+nr_spis += (GUEST_VPL011_SPI - 32)+1;
 
 for (i = 0; i < d_config->b_info.num_irqs; i++) {
 uint32_t irq = d_config->b_info.irqs[i];
 uint32_t spi;
 
+if (vpl011_enabled && irq == GUEST_VPL011_SPI)
+{
+LOG(ERROR, "Physical IRQ %d conflicting with pl011 SPI\n", irq);
+return ERROR_FAIL;
+}
+
 if (irq < 32)
 continue;
 
@@ -130,9 +144,10 @@ static struct arch_info {
 const char *guest_type;
 const char *timer_compat;
 const char *cpu_compat;
+const char *uart_compat;
 } arch_info[] = {
-{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15" },
-{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8" },
+{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15", "arm,sbsa-uart" },
+{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8", "arm,sbsa-uart" },
 };
 
 /*
@@ -590,6 +605,38 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
 return 0;
 }
 
+static int make_vpl011_uart_node(libxl__gc *gc, void *fdt,
+ const struct arch_info *ainfo,
+ struct xc_dom_image *dom)
+{
+int res;
+gic_interrupt intr;
+
+res = fdt_begin_node(fdt, "sbsa-pl011");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, ainfo->uart_compat);
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1,
+GUEST_PL011_BASE, GUEST_PL011_SIZE);
+if (res) return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property_interrupts(gc, fdt, , 1);
+if (res) return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
+
 static const struct arch_info *get_arch_info(libxl__gc *gc,
  const struct xc_dom_image *dom)
 {
@@ -889,6 +936,9 @@ next_resize:
 FDT( make_timer_node(gc, fdt, ainfo, xc_config->clock_frequency) );
 FDT( make_hypervisor_node(gc, fdt, vers) );
 
+if (!strcmp(info->vuart, "pl011"))
+FDT( make_vpl011_uart_node(gc, fdt, ainfo, dom) );
+
 if (pfdt)
 FDT( copy_partial_fdt(gc, fdt, pfdt) );
 
-- 
2.7.4


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

[Xen-devel] [PATCH 07/10 v2] xen/arm: vpl011: Add support for vuart in xenconsole

Xenconsole supports only PV console currently. This patch adds support
for vuart, which allows emulated pl011 uart to be accessed as a console.

This patch modifies different data structures and APIs used
in xenconsole to support two console types: PV and VUART.

Change summary:

1. Split the domain structure into a console structure and the
   domain structure. Each PV and VUART will have seprate console
   structures.

2. Modify different APIs such as buffer_append() etc. to take
   console structure as input and perform per console specific
   operations.

3. Modfications in domain_create_ring():
- Bind to the vpl011 event channel obtained from the xen store as a
  new parameter.
- Map the PFN to its address space to be used as IN/OUT ring
  buffers.
  It obtains the PFN from the xen store as a new parameter

4. Modifications in handle_ring_read() to handle both PV and VUART
   events.

5. Add a new log_file for VUART console logs.

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:

- Split the domain struture to a separate console structure
- Modified the functions to operate on the console struture
- Replaced repetitive per console code with generic code

 tools/console/daemon/io.c | 514 --
 1 file changed, 365 insertions(+), 149 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 7e6a886..55fda37 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -61,6 +61,10 @@
 /* Duration of each time period in ms */
 #define RATE_LIMIT_PERIOD 200
 
+#define MAX_CONSOLE 2
+#define CONSOLE_TYPE_PV 0
+#define CONSOLE_TYPE_VUART 1
+
 extern int log_reload;
 extern int log_guest;
 extern int log_hv;
@@ -89,29 +93,75 @@ struct buffer {
size_t max_capacity;
 };
 
-struct domain {
-   int domid;
+struct console {
+   char *name;
+   char *ttyname;
int master_fd;
int master_pollfd_idx;
int slave_fd;
int log_fd;
-   bool is_dead;
-   unsigned last_seen;
struct buffer buffer;
-   struct domain *next;
-   char *conspath;
int ring_ref;
xenevtchn_port_or_error_t local_port;
xenevtchn_port_or_error_t remote_port;
+   struct xencons_interface *interface;
+   struct domain *d;  /* Reference to the domain it is contained in. */
+};
+
+struct domain {
+   int domid;
+   bool is_dead;
+   unsigned last_seen;
+   struct domain *next;
+   char *conspath;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
-   struct xencons_interface *interface;
int event_count;
long long next_period;
+   struct console console[MAX_CONSOLE];
 };
 
 static struct domain *dom_head;
 
+static inline bool console_enabled(struct console *con) { return 
con->local_port != -1; }
+
+static inline void console_iter_no_check(struct domain *d, void (* 
iter_func)(struct console *))
+{
+   int i = 0;
+   struct console *con = &(d->console[0]);
+
+   for (i=0; i < MAX_CONSOLE; i++, con++)
+   {
+   iter_func(con);
+   }
+}
+
+static inline bool console_iter_bool_check(struct domain *d, bool (* 
iter_func)(struct console *))
+{
+   int i = 0;
+   struct console *con = &(d->console[0]);
+
+   for (i=0; i < MAX_CONSOLE; i++, con++)
+   {
+   if (iter_func(con))
+   return true;
+   }
+   return false;
+}
+
+static inline int console_iter_err_check(struct domain *d, int (* 
iter_func)(struct console *))
+{
+   int i = 0;
+   struct console *con = &(d->console[0]);
+
+   for (i=0; i < MAX_CONSOLE; i++, con++)
+   {
+   if (!iter_func(con))
+   return 0;
+   }
+   return 1;
+}
+
 static int write_all(int fd, const char* buf, size_t len)
 {
while (len) {
@@ -158,11 +208,24 @@ static int write_with_timestamp(int fd, const char *data, 
size_t sz,
return 0;
 }
 
-static void buffer_append(struct domain *dom)
+static inline bool buffer_available(struct console *con)
+{
+   if (discard_overflowed_data ||
+   !con->buffer.max_capacity ||
+   con->buffer.size < con->buffer.max_capacity)
+   return true;
+   else
+   return false;
+}
+
+static void buffer_append(struct console *con)
 {
-   struct buffer *buffer = >buffer;
+   struct buffer *buffer = >buffer;
+   struct xencons_interface *intf = con->interface;
+   xenevtchn_port_or_error_t port = con->local_port;
+   struct domain *dom = con->d;
+
XENCONS_RING_IDX cons, prod, size;
-   struct xencons_interface *intf = dom->interface;
 
cons = intf->out_cons;
prod = intf->out_prod;
@@ -187,22 +250,22 @@ static void buffer_append(struct domain *dom)
 
xen_mb();
intf->out_cons = cons;
-   xenevtchn_notify(dom->xce_handle,

[Xen-devel] [PATCH 06/10 v2] xen/arm: vpl011: Add vuart ring-buf and evtchn to xenstore

Add two new parameters to the xen store to be used by xenconsoled:
- newly allocated PFN to be used as IN/OUT ring buffer
- get a new event channel allocated by Xen using a domctl call

These paramters are added to xenstore only if vuart console is enabled
by the user.

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:
- Modified the xenstore key names to /vuart/0/ring-ref and 
  /vuart/0/port.
- Replaced the hvm call with domctl call to get the event channel.

 tools/libxl/libxl_console.c | 10 ++
 tools/libxl/libxl_dom.c |  4 
 2 files changed, 14 insertions(+)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 446e766..ef3bd44 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -67,6 +67,9 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int 
cons_num,
 case LIBXL_CONSOLE_TYPE_SERIAL:
 cons_type_s = "serial";
 break;
+case LIBXL_CONSOLE_TYPE_VUART:
+cons_type_s = "vuart";
+break;
 default:
 goto out;
 }
@@ -326,6 +329,13 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
domid,
 flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->console_port));
 flexarray_append(ro_front, "ring-ref");
 flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
+if (state->vuart_enabled)
+{
+flexarray_append(ro_front, "vuart/0/port");
+flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
state->vuart_port));
+flexarray_append(ro_front, "vuart/0/ring-ref");
+flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_mfn));
+}
 } else {
 flexarray_append(front, "state");
 flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 5d914a5..06ff3b7 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -434,6 +434,9 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
state->store_domid);
 state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
state->console_domid);
 
+if (state->vuart_enabled)
+xc_domain_vuart_get_evtchn(ctx->xch, domid, >vuart_port);
+
 if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
 hvm_set_conf_params(ctx->xch, domid, info);
 #if defined(__i386__) || defined(__x86_64__)
@@ -788,6 +791,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 if (xc_dom_translated(dom)) {
 state->console_mfn = dom->console_pfn;
 state->store_mfn = dom->xenstore_pfn;
+state->vuart_mfn = dom->vuart_pfn;
 } else {
 state->console_mfn = xc_dom_p2m(dom, dom->console_pfn);
 state->store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);
-- 
2.7.4


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

[Xen-devel] [PATCH 04/10 v2] xen/arm: vpl011: Add support for vuart in libxl

An option is provided in libxl to enable/disable pl011 vuart while
creating a guest domain.

Libxl now suppots a generic vuart console and pl011 is a specific type.
In future support can be added for multiple vuart of different types.

User can enable pl011 vuart by adding the following line in the guest
configuration file:

vuart = "pl011"

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:
- Modified the syntax for taking the pl011 as a console type in the
  configuration file. Now the syntax is vuart = "pl011".
- Replaced the console type VCON with VUART, as it is more 
  intuitive.

 tools/libxl/libxl.h  |  6 ++
 tools/libxl/libxl_create.c   | 10 ++
 tools/libxl/libxl_internal.h |  4 
 tools/libxl/libxl_types.idl  |  2 ++
 tools/xl/xl_console.c|  4 +++-
 tools/xl/xl_parse.c  |  3 +++
 6 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index cf8687a..bcfbb6c 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -306,6 +306,12 @@
 #define LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE 1
 
 /*
+ * LIBXL_HAVE_VUART indicates that xenconsole/client supports
+ * virtual uart.
+ */
+#define LIBXL_HAVE_VUART 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bffbc45..5d70bc2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -536,6 +536,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
 }
 
+if (!strcmp(d_config->b_info.vuart, "pl011"))
+flags |= XEN_DOMCTL_VUART_enable;
+
 /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
 libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);
 
@@ -900,6 +903,11 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (!strcmp(d_config->b_info.vuart, "pl011"))
+state->vuart_enabled = true;
+else
+state->vuart_enabled = false;
+
 if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
 (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
 (libxl_defbool_val(d_config->b_info.u.hvm.altp2m) ||
@@ -918,6 +926,8 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+state->config.console_domid = state->console_domid;
+
 ret = libxl__domain_make(gc, d_config, , >config);
 if (ret) {
 LOGD(ERROR, domid, "cannot make domain: %d", ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5d082c5..9dba8e7 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1135,6 +1135,10 @@ typedef struct {
 uint32_t num_vmemranges;
 
 xc_domain_configuration_t config;
+
+unsigned long vuart_mfn;
+uint32_tvuart_port;
+boolvuart_enabled;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2204425..5d53f2c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -105,6 +105,7 @@ libxl_console_type = Enumeration("console_type", [
 (0, "UNKNOWN"),
 (1, "SERIAL"),
 (2, "PV"),
+(3, "VUART"),
 ])
 
 libxl_disk_format = Enumeration("disk_format", [
@@ -470,6 +471,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("disable_migrate", libxl_defbool),
 ("cpuid",   libxl_cpuid_policy_list),
 ("blkdev_start",string),
+("vuart",   string),
 
 ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
 
diff --git a/tools/xl/xl_console.c b/tools/xl/xl_console.c
index 0508dda..6f3cd7f 100644
--- a/tools/xl/xl_console.c
+++ b/tools/xl/xl_console.c
@@ -34,8 +34,10 @@ int main_console(int argc, char **argv)
 type = LIBXL_CONSOLE_TYPE_PV;
 else if (!strcmp(optarg, "serial"))
 type = LIBXL_CONSOLE_TYPE_SERIAL;
+else if (!strcmp(optarg, "vuart"))
+type = LIBXL_CONSOLE_TYPE_VUART;
 else {
-fprintf(stderr, "console type supported are: pv, serial\n");
+fprintf(stderr, "console type supported are: pv, serial, vuart\n");
 return EXIT_FAILURE;
 }
 break;
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 856a304..80fd184 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -916,6 +916,9 @@ void parse_config_data(const char *config_source,
 if (!xlu_cfg_get_long (config, "maxvcpus", , 0))
 b_info->max_vcpus = l;
 
+if (xlu_cfg_replace_string(config, "vuart", _info->vuart, 0))
+b_info->vuart = strdup("unknown");
+
 parse_vnuma_config(config, b_info);
 
 /* Set max_memkb to target_memkb and max_vcpus to avail_vcpus if
--

[Xen-devel] [PATCH 03/10 v2] xen/arm: vpl011: Enable pl011 emulation for a guest domain in Xen

Vpl011 emulation is enabled for a guest domain in Xen only when it is
enabled through an option in libxl provided by the user through
guest configuration.

The pl011 enable/disable knob in libxl is introduced in the following
patch:

xen/arm: vpl011: Add support for vuart in libxl

Signed-off-by: Bhupinder Thakur 
---
 xen/arch/arm/domain.c   | 6 ++
 xen/common/domctl.c | 3 +++
 xen/include/public/domctl.h | 2 ++
 xen/include/xen/sched.h | 4 
 4 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 76310ed..23baa81 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -36,6 +36,7 @@
 #include 
 #include "vtimer.h"
 #include "vuart.h"
+#include 
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = domain_vtimer_init(d, config)) != 0 )
 goto fail;
 
+if ( domcr_flags & DOMCRF_vuart )
+if ( (rc = domain_vpl011_init(d, config)) != 0 )
+goto fail;
 update_domain_wallclock_time(d);
 
 /*
@@ -665,6 +669,8 @@ fail:
 
 void arch_domain_destroy(struct domain *d)
 {
+domain_vpl011_deinit(d);
+
 /* IOMMU page table is shared with P2M, always call
  * iommu_domain_destroy() before p2m_teardown().
  */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 951a5dc..902dd71 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -501,6 +501,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
| XEN_DOMCTL_CDF_hap
| XEN_DOMCTL_CDF_s3_integrity
| XEN_DOMCTL_CDF_oos_off
+   | XEN_DOMCTL_VUART_enable
| XEN_DOMCTL_CDF_xs_domain)) )
 break;
 
@@ -539,6 +540,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 domcr_flags |= DOMCRF_oos_off;
 if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_xs_domain )
 domcr_flags |= DOMCRF_xs_domain;
+if ( op->u.createdomain.flags & XEN_DOMCTL_VUART_enable )
+domcr_flags |= DOMCRF_vuart;
 
 d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
   >u.createdomain.config);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8bee0c3..c307013 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -63,6 +63,8 @@ struct xen_domctl_createdomain {
  /* Is this a xenstore domain? */
 #define _XEN_DOMCTL_CDF_xs_domain 4
 #define XEN_DOMCTL_CDF_xs_domain  (1U<<_XEN_DOMCTL_CDF_xs_domain)
+#define _XEN_DOMCTL_VUART_enable  6
+#define XEN_DOMCTL_VUART_enable   (1U<<_XEN_DOMCTL_VUART_enable)
 uint32_t flags;
 struct xen_arch_domainconfig config;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 1127ca9..ee7dc7a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -555,6 +555,10 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 #define _DOMCRF_xs_domain   5
 #define DOMCRF_xs_domain(1U<<_DOMCRF_xs_domain)
 
+ /* DOMCRF_vuart: enable virtual uart emulation. Used for Aarch64. */
+#define _DOMCRF_vuart  7
+#define DOMCRF_vuart   (1U<<_DOMCRF_vuart)
+
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
  * This is the preferred function if the returned domain reference
-- 
2.7.4


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

[Xen-devel] [PATCH 01/10 v2] xen/arm: vpl011: Add pl011 uart emulation in Xen

Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:

- Emulate DR read/write by reading and writing from/to the IN
  and OUT ring buffers and raising an event to the backend when
  there is data in the OUT ring buffer and injecting an interrupt
  to the guest when there is data in the IN ring buffer

- Other registers are related to interrupt management and
  essentially control when interrupts are delivered to the guest

The SBSA compliant pl011 uart is covered in Appendix B of
https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:

- Removed the optimiztion related to sendiing events to xenconsole 
- Use local variables as ring buffer indices while using the ring buffer

 xen/arch/arm/Kconfig |   5 +
 xen/arch/arm/Makefile|   1 +
 xen/arch/arm/vpl011.c| 340 +++
 xen/include/asm-arm/domain.h |   3 +
 xen/include/asm-arm/pl011-uart.h |   2 +
 xen/include/public/arch-arm.h|   8 +
 xen/include/xen/vpl011.h |  74 +
 7 files changed, 433 insertions(+)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/include/xen/vpl011.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..c1a0e7f 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,11 @@ config HAS_ITS
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
 depends on HAS_GICV3
 
+config VPL011_CONSOLE
+   bool "Emulated pl011 console support"
+   default y
+   ---help---
+ Allows a guest to use pl011 UART as a console
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2..15efc13 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -52,6 +52,7 @@ obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
+obj-$(CONFIG_VPL011_CONSOLE) += vpl011.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 000..51abade
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,340 @@
+/*
+ * arch/arm/vpl011.c
+ *
+ * Virtual PL011 UART
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
+
+static void vgic_inject_vpl011_spi(struct domain *d)
+{
+struct vpl011_s *vpl011 = >arch.vpl011;
+
+if ( (vpl011->uartris & vpl011->uartimsc) )
+vgic_vcpu_inject_spi(d, GUEST_VPL011_SPI);
+}
+
+static void vpl011_read_data(struct domain *d, uint8_t *data)
+{
+unsigned long flags;
+struct vpl011_s *vpl011 = >arch.vpl011;
+struct xencons_interface *intf = vpl011->ring_buf;
+
+/*
+ * Initialize the data so that even if there is no data in ring buffer
+ * 0 is returned.
+ */
+*data = 0;
+
+VPL011_LOCK(d, flags);
+
+/*
+ * It is expected that there will be data in the ring buffer when this
+ * function is called since the guest is expected to read the data register
+ * only if the TXFE flag is not set.
+ * If the guest still does read when TXFE bit is set then 0 will be 
returned.
+ */
+if ( !VPL011_IN_RING_EMPTY(intf) )
+{
+uint32_t in_cons = intf->in_cons;
+*data = intf->in[MASK_XENCONS_IDX(in_cons, intf->in)];
+smp_mb();
+intf->in_cons = in_cons + 1;
+}
+
+if ( VPL011_IN_RING_EMPTY(intf) )
+{
+vpl011->uartfr |= (RXFE);
+vpl011->uartris &= ~(RXI);
+}
+vpl011->uartfr &= ~(RXFF);
+VPL011_UNLOCK(d, flags);
+
+notify_via_xen_event_channel(d, vpl011->evtchn);
+}
+
+static void vpl011_write_data(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011_s *vpl011 = >arch.vpl011;
+struct xencons_interface *intf = vpl011->ring_buf;
+
+VPL011_LOCK(d, flags);
+
+/*
+ * It is expected that the ring is not full when this function is called
+ * as the guest is expected to write to the data register only when the
+ * TXFF flag is not set.
+ * In case the guest does write even when the TXFF flag is set then the
+ * data will be silently

[Xen-devel] [PATCH 05/10 v2] xen/arm: vpl011: Allocate a new PFN in the toolstack for vuart

Allocate a new pfn and pass on to Xen using a domctl call.

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:
- Replaced the hvm call with the domctl call to set the pfn.

 tools/libxc/include/xc_dom.h | 2 ++
 tools/libxc/xc_dom_arm.c | 7 ++-
 tools/libxc/xc_dom_boot.c| 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ce47058..ca8bc23 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -216,6 +216,8 @@ struct xc_dom_image {
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
+
+xen_pfn_t vuart_pfn;
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index e7d4bd0..ad805d1 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -26,10 +26,11 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
-#define NR_MAGIC_PAGES 3
+#define NR_MAGIC_PAGES 4
 #define CONSOLE_PFN_OFFSET 0
 #define XENSTORE_PFN_OFFSET 1
 #define MEMACCESS_PFN_OFFSET 2
+#define VUART_PFN_OFFSET 3
 
 #define LPAE_SHIFT 9
 
@@ -85,16 +86,20 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 
 dom->console_pfn = base + CONSOLE_PFN_OFFSET;
 dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+dom->vuart_pfn = base + VUART_PFN_OFFSET;
 
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
+xc_clear_domain_page(dom->xch, dom->guest_domid, base + VUART_PFN_OFFSET);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
 dom->console_pfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
 dom->xenstore_pfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
+xc_domain_vuart_set_pfn(dom->xch, dom->guest_domid, base + 
VUART_PFN_OFFSET);
+
 /* allocated by toolstack */
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
 dom->console_evtchn);
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index c3b44dd..5e4b322 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -226,6 +226,8 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 return rc;
 if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
 return rc;
+if ( (rc = clear_page(dom, dom->vuart_pfn)) != 0 )
+return rc;
 
 /* start info page */
 if ( dom->arch_hooks->start_info )
-- 
2.7.4


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

[Xen-devel] [PATCH 02/10 v2] xen/arm: vpl011: Add new vuart domctl interface to setup pfn and evtchn

1. Add two new domctl API to:
- Allocate a new event channel for sending/receiving events to/from Xen.
- Map the PFN allocted by the toolstack to be used as IN/OUT ring buffers.

Xen will communicate with xenconsole over the ring buffer and the event
channel to transmit and receive pl011 data on guest domain's behalf.

Signed-off-by: Bhupinder Thakur 
---

Changes since v1:

- Replaced the hvm interface with domctl interface

 tools/libxc/include/xenctrl.h | 26 ++
 tools/libxc/xc_domain.c   | 39 +++
 xen/arch/arm/domctl.c | 20 
 xen/arch/x86/domctl.c |  4 
 xen/include/public/domctl.h   | 11 +++
 5 files changed, 100 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f41..bebfe7d 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -886,6 +886,32 @@ int xc_vcpu_getcontext(xc_interface *xch,
vcpu_guest_context_any_t *ctxt);
 
 /**
+ * This function returns information about the pfn and the event channel
+ * to be used for setting up a virtual uart console.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain to get information from
+ * @parm vuart_pfn the pfn to be used for the ring buffer
+ * @return 0 on success, negative error on failure
+ */
+int xc_domain_vuart_set_pfn(xc_interface *xch,
+uint32_t domid,
+uint32_t vuart_pfn);
+
+/**
+ * This function returns information about the pfn and the event channel
+ * to be used for setting up a virtual console.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain to get information from
+ * @parm vuart_evtchn the event channel to be used for console events
+ * @return 0 on success, negative error on failure
+ */
+int xc_domain_vuart_get_evtchn(xc_interface *xch,
+   uint32_t domid,
+   uint32_t *vuart_evtchn);
+
+/**
  * This function returns information about the XSAVE state of a particular
  * vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
  * the call is considered a query to retrieve them and the buffer is not
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 00909ad4..943f202 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -343,6 +343,45 @@ int xc_domain_get_guest_width(xc_interface *xch, uint32_t 
domid,
 return 0;
 }
 
+int xc_domain_vuart_set_pfn(xc_interface *xch,
+uint32_t domid,
+uint32_t vuart_pfn)
+{
+DECLARE_DOMCTL;
+int rc = 0;
+
+domctl.cmd = XEN_DOMCTL_vuart_op;
+domctl.domain = (domid_t)domid;
+domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_SET_PFN;
+domctl.u.vuart_op.pfn = vuart_pfn;
+
+if ( (rc = do_domctl(xch, )) < 0 )
+return rc;
+
+return rc;
+}
+
+int xc_domain_vuart_get_evtchn(xc_interface *xch,
+   uint32_t domid,
+   uint32_t *vuart_evtchn)
+{
+DECLARE_DOMCTL;
+int rc = 0;
+
+   *vuart_evtchn = -1;
+
+domctl.cmd = XEN_DOMCTL_vuart_op;
+domctl.domain = (domid_t)domid;
+domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_GET_EVTCHN;
+
+if ( (rc = do_domctl(xch, )) < 0 )
+return rc;
+
+*vuart_evtchn = domctl.u.vuart_op.evtchn;
+
+return rc;
+}
+
 int xc_domain_getinfo(xc_interface *xch,
   uint32_t first_domid,
   unsigned int max_doms,
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 971caec..e400f87 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -119,6 +120,25 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
domain *d,
 d->disable_migrate = domctl->u.disable_migrate.disable;
 return 0;
 
+case XEN_DOMCTL_vuart_op:
+{
+int rc;
+if ( d->arch.vpl011.initialized )
+{
+if ( domctl->u.vuart_op.cmd == XEN_DOMCTL_VUART_OP_SET_PFN )
+{
+rc = vpl011_map_guest_page(d, domctl->u.vuart_op.pfn);
+}
+else
+{
+domctl->u.vuart_op.evtchn = d->arch.vpl011.evtchn;
+rc = __copy_to_guest(u_domctl, domctl, 1);
+}
+return rc;
+}
+else
+return -EINVAL;
+}
 default:
 {
 int rc;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index e104be2..49e907d 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1465,6 +1465,10 @@ long arch_do_domctl(
 recalculate_cpuid_policy(d);
 break;
 
+case XEN_DOMCTL_vuart_op:
+ret = -EOPNOTSUPP;
+break;
+

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

On 04/28/2017 10:27 AM, Dr. David Alan Gilbert wrote:

 +# Enumeration of various causes for shutdown.
 +#
 +# @host-qmp: Reaction to a QMP command, such as 'quit'
 +# @host-signal: Reaction to a signal, such as SIGINT
 +# @host-ui: Reaction to a UI event, such as closing the window
 +# @host-replay: The host is replaying an earlier shutdown event
 +# @host-error: Qemu encountered an error that prevents further use of the 
 guest
 +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
 +#  other hardware-specific action
 +# @guest-reset: The guest requested a reset, and the command line
 +#   response to a reset is to instead trigger a shutdown
 +# @guest-panic: The guest panicked, and the command line response to
 +#   a panic is to trigger a shutdown
>>>

> At a higher level, using your tags, I'm not sure where a reset triggered
> by a fault detected by the hypervisor lives - e.g. an x86 triple fault
> where the guest screws up so badly that it just gets reset.  Is
> that a guest-reset or a guest-panic or what - neither case
> was actually asked for by the guest itself.

Wouldn't that be host-error (qemu detected an error that prevents
further execution of the guest without a reset - and a triple fault
seems to fall into the category of the guest getting itself wedged
rather than actually trying to reset)?  Except patch 3 only used
SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.

So if any x86 expert has an opinion on where triple-fault handling is
emulated, and what category should be used there, I'm welcome to
tweaking this series.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

[Xen-devel] [seabios test] 107891: regressions - FAIL

flight 107891 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107891/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   29 days
Testing same since   107663  2017-04-25 17:17:46 Z2 days   29 attempts


People who touched revisions under test:
  Julius Werner 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to

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

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

Regressions :-(

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

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

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

* Eric Blake (ebl...@redhat.com) wrote:
> On 04/28/2017 03:08 AM, Dr. David Alan Gilbert wrote:
> > * Eric Blake (ebl...@redhat.com) wrote:
> >> We want to track why a guest was shutdown; in particular, being able
> >> to tell the difference between a guest request (such as ACPI request)
> >> and host request (such as SIGINT) will prove useful to libvirt.
> >> Since all requests eventually end up changing shutdown_requested in
> >> vl.c, the logical change is to make that value track the reason,
> >> rather than its current 0/1 contents.
> >>
> 
> >>  ##
> >> +# @ShutdownCause:
> >> +#
> >> +# Enumeration of various causes for shutdown.
> >> +#
> >> +# @host-qmp: Reaction to a QMP command, such as 'quit'
> >> +# @host-signal: Reaction to a signal, such as SIGINT
> >> +# @host-ui: Reaction to a UI event, such as closing the window
> >> +# @host-replay: The host is replaying an earlier shutdown event
> >> +# @host-error: Qemu encountered an error that prevents further use of the 
> >> guest
> >> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
> >> +#  other hardware-specific action
> >> +# @guest-reset: The guest requested a reset, and the command line
> >> +#   response to a reset is to instead trigger a shutdown
> >> +# @guest-panic: The guest panicked, and the command line response to
> >> +#   a panic is to trigger a shutdown
> > 
> > It's a little coarse grained;  is there anyway to pass platform specific 
> > information
> > for debug?  I ask because I spent a while debugging a few bugs with 
> > unexpected
> > resets and had to figure out which of x86's many reset causes triggered it.
> 
> I'm open to any followup patches that add further enum values and
> adjusts the various callers (patch 3 shows how MANY callers use
> qemu_system_shutdown_request).  But I don't think it's necessarily in
> scope for this series - remember, my goal here was merely to distinguish
> between host- and guest-triggered resets (which libvirt and higher
> management tasks want to know)

Yep, that's fine.

> rather than which of multiple reset
> paths was taken (I agree that it is useful during a qemu debug session -
> but that's a different audience).  I also don't consider myself an
> expert in the many ways that x86 can reset - it was easy to blindly
> rewrite qemu_system_shutdown_request() into
> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN) based solely
> on directory, but it would be harder to distinguish which of the
> multiple files should have which finer-grained cause.

Yes, I'm also not an expert on x86 resets - but when I was debugging
I just added a tag in every place it called the reset code.

At a higher level, using your tags, I'm not sure where a reset triggered
by a fault detected by the hypervisor lives - e.g. an x86 triple fault
where the guest screws up so badly that it just gets reset.  Is
that a guest-reset or a guest-panic or what - neither case
was actually asked for by the guest itself.

Dave


> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 



--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

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

Re: [Xen-devel] [Qemu-devel] [PATCH v5 3/4] shutdown: Add source information to SHUTDOWN and RESET

Eric Blake  writes:

> Libvirt would like to be able to distinguish between a SHUTDOWN
> event triggered solely by guest request and one triggered by a
> SIGTERM or other action on the host.  While qemu_kill_report() is
> already able to tell whether a shutdown was triggered by a host
> signal (but NOT by a host UI event, such as clicking the X on
> the window), that information was then lost after being printed
> to stderr.  The previous patch prepped things to use an enum
> internally; now it's time to wire it up through all callers, and
> to extend the SHUTDOWN and RESET events to report the details.
>
> Enhance the shutdown request path to take a parameter of which
> way it is being triggered, and update ALL callers.  It would have
> been less churn to keep the common case with no arguments as
> meaning guest-triggered, and only modified the host-triggered
> code paths, via a wrapper function, but then we'd still have to
> audit that I didn't miss any host-triggered spots; changing the
> signature forces us to double-check that I correctly categorized
> all callers.
>
> Since command line options can change whether a guest reset request
> causes an actual reset vs. a shutdown, it's easy to also add the
> information to the RESET event, even though libvirt has not yet
> expressed a need to know that.
>
> For the moment, we keep the enum ShutdownCause for internal use
> only, and merely expose a single boolean of 'guest':true|false
> to the QMP client; this is because we don't yet have evidence that
> the further distinctions will be useful, or whether the addition
> of new enum members would cause problems to clients coded to an
> older version of the enum.
>
> Update expected iotest outputs to match the new data.
>
> Here is output from 'virsh qemu-monitor-event --loop' with the
> patch installed:
>
> event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
> event STOP at 1492639680.732116 for domain fedora_13: 
> event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}
>
> Note that libvirt runs qemu with -no-quit: the first SHUTDOWN event
> was triggered by an action I took directly in the guest (shutdown -h),
> at which point qemu stops the vcpus and waits for libvirt to do any
> final cleanups; the second SHUTDOWN event is the result of libvirt
> sending SIGTERM now that it has completed cleanup.
>
> The replay driver needs a followup patch if we want to be able to
> faithfully replay the difference between a host- and guest-initiated
> shutdown (for now, the replayed event is always attributed to host).

I'd prefer to get this right from the start, but that requires input
from replay guys.

Scandalously, replay/ is not covered by MAINTAINERS.
scripts/get_maintainers.pl blames it on Pavel Dovgalyuk (cc'ed), and git
shows recent activity.  Pavel, please post a suitable patch to
MAINTAINERS, and please help us figure out what to do about replaying
reset here.

> See also https://bugzilla.redhat.com/1384007
>
> Signed-off-by: Eric Blake 

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

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

On 04/28/2017 03:08 AM, Dr. David Alan Gilbert wrote:
> * Eric Blake (ebl...@redhat.com) wrote:
>> We want to track why a guest was shutdown; in particular, being able
>> to tell the difference between a guest request (such as ACPI request)
>> and host request (such as SIGINT) will prove useful to libvirt.
>> Since all requests eventually end up changing shutdown_requested in
>> vl.c, the logical change is to make that value track the reason,
>> rather than its current 0/1 contents.
>>

>>  ##
>> +# @ShutdownCause:
>> +#
>> +# Enumeration of various causes for shutdown.
>> +#
>> +# @host-qmp: Reaction to a QMP command, such as 'quit'
>> +# @host-signal: Reaction to a signal, such as SIGINT
>> +# @host-ui: Reaction to a UI event, such as closing the window
>> +# @host-replay: The host is replaying an earlier shutdown event
>> +# @host-error: Qemu encountered an error that prevents further use of the 
>> guest
>> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
>> +#  other hardware-specific action
>> +# @guest-reset: The guest requested a reset, and the command line
>> +#   response to a reset is to instead trigger a shutdown
>> +# @guest-panic: The guest panicked, and the command line response to
>> +#   a panic is to trigger a shutdown
> 
> It's a little coarse grained;  is there anyway to pass platform specific 
> information
> for debug?  I ask because I spent a while debugging a few bugs with unexpected
> resets and had to figure out which of x86's many reset causes triggered it.

I'm open to any followup patches that add further enum values and
adjusts the various callers (patch 3 shows how MANY callers use
qemu_system_shutdown_request).  But I don't think it's necessarily in
scope for this series - remember, my goal here was merely to distinguish
between host- and guest-triggered resets (which libvirt and higher
management tasks want to know), rather than which of multiple reset
paths was taken (I agree that it is useful during a qemu debug session -
but that's a different audience).  I also don't consider myself an
expert in the many ways that x86 can reset - it was easy to blindly
rewrite qemu_system_shutdown_request() into
qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN) based solely
on directory, but it would be harder to distinguish which of the
multiple files should have which finer-grained cause.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

Re: [Xen-devel] [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

"Dr. David Alan Gilbert"  writes:

> * Eric Blake (ebl...@redhat.com) wrote:
>> We want to track why a guest was shutdown; in particular, being able
>> to tell the difference between a guest request (such as ACPI request)
>> and host request (such as SIGINT) will prove useful to libvirt.
>> Since all requests eventually end up changing shutdown_requested in
>> vl.c, the logical change is to make that value track the reason,
>> rather than its current 0/1 contents.
>> 
>> Since command-line options control whether a reset request is turned
>> into a shutdown request instead, the same treatment is given to
>> reset_requested.
>> 
>> This patch adds a QAPI enum ShutdownCause that describes reasons
>> that a shutdown can be requested, and changes qemu_system_reset() to
>> pass the reason through, although for now it is not reported.  The
>> next patch will actually wire things up to modify events to report
>> data based on the reason, and to pass the correct enum value in from
>> various call-sites that can trigger a reset/shutdown.  Since QAPI
>> generates enums starting at 0, it's easier if we use a different
>> number as our sentinel that no request has happened yet.  Most of
>> the changes are in vl.c, but xen was using things externally.
>> 
>> Signed-off-by: Eric Blake 
>> 
>> ---
>> v4: s/ShutdownType/ShutdownCause/, no thanks to mingw header pollution
>> v3: new patch
>> ---
>>  qapi-schema.json| 23 +++
>>  include/sysemu/sysemu.h |  2 +-
>>  vl.c| 44 
>>  hw/i386/xen/xen-hvm.c   |  9 ++---
>>  migration/colo.c|  2 +-
>>  migration/savevm.c  |  2 +-
>>  6 files changed, 60 insertions(+), 22 deletions(-)
>> 
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 01b087f..a4ebdd1 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -2304,6 +2304,29 @@
>>  { 'command': 'system_powerdown' }
>> 
>>  ##
>> +# @ShutdownCause:
>> +#
>> +# Enumeration of various causes for shutdown.
>> +#
>> +# @host-qmp: Reaction to a QMP command, such as 'quit'
>> +# @host-signal: Reaction to a signal, such as SIGINT
>> +# @host-ui: Reaction to a UI event, such as closing the window
>> +# @host-replay: The host is replaying an earlier shutdown event
>> +# @host-error: Qemu encountered an error that prevents further use of the 
>> guest
>> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
>> +#  other hardware-specific action
>> +# @guest-reset: The guest requested a reset, and the command line
>> +#   response to a reset is to instead trigger a shutdown
>> +# @guest-panic: The guest panicked, and the command line response to
>> +#   a panic is to trigger a shutdown
>
> It's a little coarse grained;  is there anyway to pass platform specific 
> information
> for debug?  I ask because I spent a while debugging a few bugs with unexpected
> resets and had to figure out which of x86's many reset causes triggered it.

Asking for more help with debugging is fair, but I think the need is
better served by tracepoints than by exposing even more detail in QMP,
where compatibility promises apply.

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

Re: [Xen-devel] [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

Eric Blake  writes:

> We want to track why a guest was shutdown; in particular, being able
> to tell the difference between a guest request (such as ACPI request)
> and host request (such as SIGINT) will prove useful to libvirt.
> Since all requests eventually end up changing shutdown_requested in
> vl.c, the logical change is to make that value track the reason,
> rather than its current 0/1 contents.
>
> Since command-line options control whether a reset request is turned
> into a shutdown request instead, the same treatment is given to
> reset_requested.
>
> This patch adds a QAPI enum ShutdownCause that describes reasons
> that a shutdown can be requested, and changes qemu_system_reset() to
> pass the reason through, although for now it is not reported.  The
> next patch will actually wire things up to modify events to report
> data based on the reason, and to pass the correct enum value in from
> various call-sites that can trigger a reset/shutdown.  Since QAPI
> generates enums starting at 0, it's easier if we use a different
> number as our sentinel that no request has happened yet.  Most of
> the changes are in vl.c, but xen was using things externally.
>
> Signed-off-by: Eric Blake 
>
> ---
> v4: s/ShutdownType/ShutdownCause/, no thanks to mingw header pollution
> v3: new patch
> ---
>  qapi-schema.json| 23 +++
>  include/sysemu/sysemu.h |  2 +-
>  vl.c| 44 
>  hw/i386/xen/xen-hvm.c   |  9 ++---
>  migration/colo.c|  2 +-
>  migration/savevm.c  |  2 +-
>  6 files changed, 60 insertions(+), 22 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 01b087f..a4ebdd1 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2304,6 +2304,29 @@
>  { 'command': 'system_powerdown' }
>
>  ##
> +# @ShutdownCause:
> +#
> +# Enumeration of various causes for shutdown.
> +#
> +# @host-qmp: Reaction to a QMP command, such as 'quit'
> +# @host-signal: Reaction to a signal, such as SIGINT
> +# @host-ui: Reaction to a UI event, such as closing the window
> +# @host-replay: The host is replaying an earlier shutdown event
> +# @host-error: Qemu encountered an error that prevents further use of the 
> guest
> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
> +#  other hardware-specific action
> +# @guest-reset: The guest requested a reset, and the command line
> +#   response to a reset is to instead trigger a shutdown
> +# @guest-panic: The guest panicked, and the command line response to
> +#   a panic is to trigger a shutdown
> +#
> +# Since: 2.10
> +##
> +{ 'enum': 'ShutdownCause',
> +  'data': [ 'host-qmp', 'host-signal', 'host-ui', 'host-replay', 
> 'host-error',
> +'guest-shutdown', 'guest-reset', 'guest-panic' ] }
> +
> +##
>  # @cpu:
>  #
>  # This command is a nop that is only provided for the purposes of 
> compatibility.
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 16175f7..00a907f 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -65,7 +65,7 @@ bool qemu_vmstop_requested(RunState *r);
>  int qemu_shutdown_requested_get(void);
>  int qemu_reset_requested_get(void);
>  void qemu_system_killed(int signal, pid_t pid);
> -void qemu_system_reset(bool report);
> +void qemu_system_reset(bool report, int reason);
>  void qemu_system_guest_panicked(GuestPanicInformation *info);
>  size_t qemu_target_page_size(void);
>
> diff --git a/vl.c b/vl.c
> index 879786a..2b95b7f 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1597,8 +1597,8 @@ void vm_state_notify(int running, RunState state)
>  }
>  }
>
> -static int reset_requested;
> -static int shutdown_requested, shutdown_signal;
> +static int reset_requested = -1;
> +static int shutdown_requested = -1, shutdown_signal;

Peeking ahead, I see that shutdown_requested and reset_requested take
ShutdownCause values and -1.  The latter means "no shutdown requested".
What about adding 'none' to ShutdownCause, with value 0, und use that
instead of literal -1?  Would avoid the unusual "negative means false,
non-negative means true".

PATCH 4 exposes ShutdownCause in event SHUTDOWN, and 'none' must not
occur there.  However, if we ever add a query-shutdown to go with this
event, we will need 'none' there.

I'd be tempted to reshuffle declarations here, because shutdown_signal's
int is a different one than reset_requested's and shutdown_requested,
and the latter two's "negative means false, non-negative means true" is
unusual enough to justify a comment.

>  static pid_t shutdown_pid;
>  static int powerdown_requested;
>  static int debug_requested;
> @@ -1624,7 +1624,7 @@ int qemu_reset_requested_get(void)
>
>  static int qemu_shutdown_requested(void)
>  {
> -return atomic_xchg(_requested, 0);
> +return atomic_xchg(_requested, -1);
>  }

Hmm.  In case we stick to literal -1:

[Xen-devel] Xen 4.9.0 RC3

Xen 4.9.0 RC3 is now available.

You can check it out from xen.git:

  git://xenbits.xen.org/xen.git#4.9.0-rc3

For your convenience there is also a tarball and singautre at:
  https://downloads.xenproject.org/release/xen/4.9.0-rc3/xen-4.9.0-rc3.tar.gz  
  
https://downloads.xenproject.org/release/xen/4.9.0-rc3/xen-4.9.0-rc3.tar.gz.sig

Please send bug reports and test reports to
xen-de...@lists.xenproject.org. When sending bug reports, please CC
relevant maintainers, the Julien Grall the Release Manager
 and me (standing in for Julien this week).

We are aware of one build bug: the x86 instruction emulator fuzzer
utility is now built by default, but there is a problem where it fails
to build with older GCC versions (GCC 4.3 and 4.4, at least).  The
workaround would be to apply ba39e9b21083 from xen.git#staging
"x86emul: correct stub invocation constraints again", or to comment
out "SUBDIRS-y += x86_instruction_emulator" in tools/fuzz/Makefile.

Thanks,
Ian.

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

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

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 107791 pass 
in 107840
 test-armhf-armhf-xl  16 guest-start.2fail in 107791 pass in 107840
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 107791 
pass in 107840
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
107791
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
107791
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
107791

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 107791 like 107676
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail in 107791 like 107676
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail in 107791 like 107676
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107676
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107676
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107676
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107676
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 107676
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107676
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-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-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 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
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints again

Jan Beulich writes ("[PATCH] x86emul: correct stub invocation constraints 
again"):
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good enough to not
> re-introduce the original problem: Which of the addresses is actually
> used doesn't matter much as long as the compiler can't prove that the
> two pointers don't alias one another.
> 
> Reported-by: Boris Ostrovsky 
> Signed-off-by: Jan Beulich 

Release-acked-by: Ian Jackson 

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

[Xen-devel] [OSSTEST PATCH] ts-libvirt-build: Cope with keycodemapdb submodule

libvirt.git#02fb15f introduces this new submodule.

Submodules are awkward, and we need them to be explicitly listed.
So add keycodemapdb to the submodulemap in ts-libvirt-build.

Reported-by: Wei Liu 
Signed-off-by: Ian Jackson 
---
 ts-libvirt-build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-libvirt-build b/ts-libvirt-build
index 714402b..419f3ec 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -26,7 +26,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 builddirsprops();
 
-our %submodmap = qw(gnulib gnulib);
+our %submodmap = qw(gnulib gnulib
+keycodemapdb keycodemapdb);
 our $submodules;
 
 sub libvirtd_init ();
-- 
2.1.4


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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  02fb15fb60274a684497293fecba400e37687d95
  Bug not present: ab54d5f15239940d4e3d142c553d7e55ec0ff13b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107893/


  commit 02fb15fb60274a684497293fecba400e37687d95
  Author: Daniel P. Berrange 
  Date:   Thu Mar 2 10:46:53 2017 +
  
  util: switch over to use keycodemapdb GIT submodule
  
  A long time ago we imported the keymaps.csv file from GTK-VNC so we
  can do conversions between keycode sets. Meanwhile lots of bug fixes
  have gone into this CSV file and libvirt hasn't kept in sync. The
  keymaps.csv file and associated generator script has been pulled out
  of GTK-VNC into a dedicated GIT repo for use as a submodule. This
  allows GTK-VNC, SPICE-GTK, QEMU and libvirt to share the same master
  database and tools and pushing updates merely requires a submodule
  commit update as with gnulib.
  
  The test suite is updated to cover some extra boundary conditions.
  
  Signed-off-by: Daniel P. Berrange 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/107893.bisection-summary --basis-template=107640 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 107851 fail [host=godello0] / 107640 [host=godello1] 107613 [host=godello1] 
107594 [host=elbling1] 107577 [host=huxelrebe1] 107556 [host=godello1] 107536 
[host=godello1] 107442 ok.
Failure / basis pass flights: 107851 / 107442
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: libvirt_gnulib)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5ade0ff90581cddce71dd40840ca72f87825cb54 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
Basis pass 8e09663f7ff70b10a560746f17897d2c67c8460d 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
17cd6621688bce9972d924264fd7aba44c31
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#8e09663f7ff70b10a560746f17897d2c67c8460d-5ade0ff90581cddce71dd40840ca72f87825cb54
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7
 
git://xenbits.xen.org/xen.git#17cd6621688bce9972d924264fd7aba44c31-8829d12ac0f9e3f7b01f276cd966c5a39497da92
Loaded 2001 nodes in revision graph
Searching for test results:
 107442 pass 8e09663f7ff70b10a560746f17897d2c67c8460d 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
17cd6621688bce9972d924264fd7aba44c31
 107536 [host=godello1]
 107556 [host=godello1]
 107577 [host=huxelrebe1]
 107613 [host=godello1]
 107594 [host=elbling1]
 107696 fail irrelevant
 107640 [host=godello1]
 107755 fail 26d21e5de8743ab0d594d7dc46ecfc5524c08cd3 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107883 fail 5ade0ff90581cddce71dd40840ca72f87825cb54 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107868 pass 74face42b653f02e7e02866f296cf696731ea7fa 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107885 fail 02fb15fb60274a684497293fecba400e37687d95 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107870 pass 891d0a76b5ad34959c585660a62d13d51d1b8a96 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
 107856 pass 8e09663f7ff70b10a560746f17897d2c67c8460d 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
17cd6621688bce9972d924264fd7aba44c31
 107851 fail

Re: [Xen-devel] [PATCH for-next v3 09/12] x86/domain: move PV specific code to pv/domain.c

2017-04-28 Thread Wei Liu

On Fri, Apr 28, 2017 at 06:24:04AM -0600, Jan Beulich wrote:
> >>> On 28.04.17 at 12:54,  wrote:
> > Since this is the last unacked patch I'm only sending the updated
> > version here.
> 
> Sure,
> Reviewed-by: Jan Beulich 
> with one minor remaining thing I did overlook in v3:
> 
> > --- /dev/null
> > +++ b/xen/arch/x86/pv/domain.c
> > @@ -0,0 +1,235 @@
> > +/**
> > + * arch/x86/pv/domain.c
> > + *
> > + * PV domain handling
> > + */
> > +
> > +/*
> > + *  Copyright (C) 1995  Linus Torvalds
> > + *
> > + *  Pentium III FXSR, SSE support
> > + *  Gareth Hughes , May 2000
> > + */
> 
> There's still the question of the applicability of this copyright part.
> 

I don't think there is anything relevant left. I will just delete this
copyright notice.

For the record, I came to that conclusion by looking at commit
4676bbf96dc.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH] kexec: Provide user friendly option for memory limit

>>> On 28.04.17 at 13:01,  wrote:
> From 0f61898acaeb2b34ee8156ebd40bb82fef28ff5f Mon Sep 17 00:00:00 2001
> From: Simon Crowe 
> Date: Fri, 28 Apr 2017 10:46:43 +
> Subject: [PATCH] kexec: Provide user friendly option for memory limit
> 
> grub2 requires that the '<' character be escaped which is
> inconvienet for users, provide a more natural specifier.
> 
> Signed-off-by: Simon Crowe 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-next v3 09/12] x86/domain: move PV specific code to pv/domain.c

>>> On 28.04.17 at 12:54,  wrote:
> Since this is the last unacked patch I'm only sending the updated
> version here.

Sure,
Reviewed-by: Jan Beulich 
with one minor remaining thing I did overlook in v3:

> --- /dev/null
> +++ b/xen/arch/x86/pv/domain.c
> @@ -0,0 +1,235 @@
> +/**
> + * arch/x86/pv/domain.c
> + *
> + * PV domain handling
> + */
> +
> +/*
> + *  Copyright (C) 1995  Linus Torvalds
> + *
> + *  Pentium III FXSR, SSE support
> + *  Gareth Hughes , May 2000
> + */

There's still the question of the applicability of this copyright part.

Jan


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

[Xen-devel] [seabios test] 107880: regressions - FAIL

flight 107880 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107880/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   29 days
Testing same since   107663  2017-04-25 17:17:46 Z2 days   28 attempts


People who touched revisions under test:
  Julius Werner 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to

[Xen-devel] [PATCH] kexec: Provide user friendly option for memory limit

2017-04-28 Thread Simon Crowe

>From 0f61898acaeb2b34ee8156ebd40bb82fef28ff5f Mon Sep 17 00:00:00 2001
From: Simon Crowe 
Date: Fri, 28 Apr 2017 10:46:43 +
Subject: [PATCH] kexec: Provide user friendly option for memory limit

grub2 requires that the '<' character be escaped which is
inconvienet for users, provide a more natural specifier.

Signed-off-by: Simon Crowe 
---
 docs/misc/kexec_and_kdump.txt   |  8 +++-
 docs/misc/xen-command-line.markdown |  5 +
 xen/common/kexec.c  | 10 --
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/docs/misc/kexec_and_kdump.txt b/docs/misc/kexec_and_kdump.txt
index 2f93771..0842b3d 100644
--- a/docs/misc/kexec_and_kdump.txt
+++ b/docs/misc/kexec_and_kdump.txt
@@ -136,7 +136,13 @@ command line parameter to the Xen hypervisor. It has two 
forms:

   e.g. crashkernel=128M@256M

-   Regardless of which of the two forms of the crashkernel command line you
+  iii) crashkernel=size,below=offset
+
+  This allows us to place the crash kernel within the usuable address
+  space without having to worry about a specific phyiscal address.
+  The '<' and 'below' options are  synonymous
+
+   Regardless of which of the forms of the crashkernel command line you
use, the crash kernel region should appear in /proc/iomem on x86. If it
doesn't then either the crashkernel parameter is missing, or for some
reason the region couldn't be placed - for instance because it is too large.
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 450b222..9473245 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -474,6 +474,7 @@ combination with the `low_crashinfo` command line option.
 ### crashkernel
 > `= :[,...][{@,<}]`
 > `= [{@,<}]`
+> `= ,below=offset`

 Specify sizes and optionally placement of the crash kernel reservation
 area.  The `:` pairs indicate how much memory to
@@ -485,6 +486,10 @@ A trailing `@` specifies the exact address this 
area should be
 placed at, whereas `<` in place of `@` just specifies an upper bound of
 the address range the area should fall into.

+< and below are synonyomous, the latter being useful for grub2 systems
+which would otherwise require escaping of the < option
+
+
 ### credit2\_balance\_over
 > `= `

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index fbca8a6..a52c30b 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -88,7 +88,7 @@ static void *crash_heap_current = NULL, *crash_heap_end = 
NULL;
 /*
  * Parse command lines in the format
  *
- *   crashkernel=:[,...][{@,<}]
+ *   crashkernel=:[,...][{@,<,below=}]
  *
  * with  being of form
  *
@@ -97,6 +97,10 @@ static void *crash_heap_current = NULL, *crash_heap_end = 
NULL;
  * as well as the legacy ones in the format
  *
  *   crashkernel=[{@,<}]
+ *   crashkernel=,below=address
+ *
+ * < and below are synonyomous, the latter being useful for grub2 systems
+ * which would otherwise require escaping of the < option
  */
 static void __init parse_crashkernel(const char *str)
 {
@@ -111,7 +115,7 @@ static void __init parse_crashkernel(const char *str)
 {
 printk(XENLOG_WARNING "crashkernel: too many ranges\n");
 cur = NULL;
-str = strpbrk(str, "@<");
+str = strpbrk(str, "@,<");
 break;
 }

@@ -162,6 +166,8 @@ static void __init parse_crashkernel(const char *str)
 kexec_crash_area.start = parse_size_and_unit(cur = str + 1, );
 else if ( *str == '<' )
 kexec_crash_area_limit = parse_size_and_unit(cur = str + 1, );
+else if ( !strncmp(str, ",below=", 7) )
+kexec_crash_area_limit = parse_size_and_unit(cur = str + 7, );
 else
 printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);
 }
--
2.7.4

?

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

Re: [Xen-devel] [PATCH for-next v3 09/12] x86/domain: move PV specific code to pv/domain.c

2017-04-28 Thread Wei Liu

On Fri, Apr 28, 2017 at 02:47:30AM -0600, Jan Beulich wrote:
> >>> On 26.04.17 at 17:54,  wrote:
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -655,6 +655,9 @@ static inline void pv_inject_page_fault(int errcode, 
> > unsigned long cr2)
> >  pv_inject_event();
> >  }
> >  
> > +void paravirt_ctxt_switch_from(struct vcpu *v);
> > +void paravirt_ctxt_switch_to(struct vcpu *v);
> 
> I think these would better go ...
> 
> > --- /dev/null
> > +++ b/xen/include/asm-x86/pv/domain.h
> > @@ -0,0 +1,57 @@
> > +/*
> > + * pv/domain.h
> > + *
> > + * PV guest interface definitions
> > + *
> > + * Copyright (C) 2017 Wei Liu 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms and conditions of the GNU General Public
> > + * License, version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > + * License along with this program; If not, see 
> > .
> > + */
> > +
> > +#ifndef __X86_PV_DOMAIN_H__
> > +#define __X86_PV_DOMAIN_H__
> > +
> > +#ifdef CONFIG_PV
> > +
> > +void pv_vcpu_destroy(struct vcpu *v);
> > +int pv_vcpu_initialise(struct vcpu *v);
> > +void pv_domain_destroy(struct domain *d);
> > +int pv_domain_initialise(struct domain *d, unsigned int domcr_flags,
> > + struct xen_arch_domainconfig *config);
> > +
> > +#else  /* !CONFIG_PV */
> > +
> > +#include 
> > +
> > +static inline void pv_vcpu_destroy(struct vcpu *v) {}
> > +static inline int pv_vcpu_initialise(struct vcpu *v) { return -EOPNOTSUPP; 
> > }
> > +static inline void pv_domain_destroy(struct domain *d) {}
> > +static inline int pv_domain_initialise(struct domain *d,
> > +   unsigned int domcr_flags,
> > +   struct xen_arch_domainconfig 
> > *config);
> > +{
> > +return -EOPNOTSUPP;
> > +}
> > +#endif /* CONFIG_PV */
> 
> ... here. The idle domain is a PV one after all, just that we'll always
> need it even with CONFIG_PV off.
> 
> Also pv/domain.c needs to include this new header - as pointed
> out before, both producer and consumer(s) need to see the same
> declarations.
> 

Since this is the last unacked patch I'm only sending the updated
version here.

---8<---
From adac237d678544a1ecbbe3141d37fb31a9727b4c Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Mon, 24 Apr 2017 19:39:11 +0100
Subject: [PATCH] x86/domain: move PV specific code to pv/domain.c

Move all the PV specific code along with the supporting code to
pv/domain.c.

This in turn requires exporting a few functions in header files. Create
pv/domain.h for that.

No functional change.

Signed-off-by: Wei Liu 
---
v4:
1. move paravirt* declarations to pv/domain.h
2. include pv/domain.h in pv/domain.c

v3:
1. move paravirt_ctxt_switch_* declarations
2. use CONFIG_PV

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/domain.c   | 214 +---
 xen/arch/x86/pv/Makefile|   1 +
 xen/arch/x86/pv/domain.c| 235 
 xen/include/asm-x86/pv/domain.h |  60 ++
 4 files changed, 299 insertions(+), 211 deletions(-)
 create mode 100644 xen/arch/x86/pv/domain.c
 create mode 100644 xen/include/asm-x86/pv/domain.h

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index cb104c6730..80cda83279 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -63,6 +63,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -70,9 +71,6 @@ static void default_idle(void);
 void (*pm_idle) (void) __read_mostly = default_idle;
 void (*dead_idle) (void) __read_mostly = default_dead_idle;
 
-static void paravirt_ctxt_switch_from(struct vcpu *v);
-static void paravirt_ctxt_switch_to(struct vcpu *v);
-
 static void default_idle(void)
 {
 local_irq_disable();
@@ -145,13 +143,6 @@ static void noreturn continue_idle_domain(struct vcpu *v)
 reset_stack_and_jump(idle_loop);
 }
 
-static void noreturn continue_nonidle_domain(struct vcpu *v)
-{
-check_wakeup_from_wait();
-mark_regs_dirty(guest_cpu_user_regs());
-reset_stack_and_jump(ret_from_intr);
-}
-
 void dump_pageframe_info(struct domain *d)
 {
 struct page_info *page;
@@ -313,137 +304,6 @@ void free_vcpu_struct(struct vcpu *v)
 free_xenheap_page(v);
 }
 
-static int setup_compat_l4(struct vcpu *v)
-{
-struct page_info *pg;
-l4_pgentry_t *l4tab;
-
-pg =

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

>>> On 27.04.17 at 11:51,  wrote:
> At 03:23 -0600 on 27 Apr (1493263380), Jan Beulich wrote:
>> ... it wouldn't better be the other way around: We use the patch
>> in its current (or even v1) form, and try to do something about
>> performance only if we really find a case where it matters. To be
>> honest, I'm not even sure how I could meaningfully measure the
>> impact here: Simply counting how many extra flushes there would
>> end up being wouldn't seem all that useful, and whether there
>> would be any measurable difference in the overall execution time
>> of e.g. domain creation I would highly doubt (but if it's that what
>> you're after, I could certainly collect a few numbers).
> 
> I think that would be a good idea, just as a sanity-check.

As it turns out there is a measurable effect: xc_dom_boot_image()
for a 4Gb PV guest takes about 70% longer now. Otoh it is itself
responsible for less than 10% of the overall time libxl__build_dom()
takes, and that in turn is only a pretty small portion of the overall
"xl create".

Jan


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

Re: [Xen-devel] [xen-unstable test] 107791: regressions - FAIL

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 107791: regressions - 
FAIL"):
>  I don't suppose there is any memory sharing being set up for any
> tests in osstest,

Indeed, there isn't.

Ian.

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

Re: [Xen-devel] [RFC PATCH 2/9] iommu: Add ability to map/unmap the number of pages

2017-04-28 Thread Oleksandr Tyshchenko

On Fri, Apr 28, 2017 at 1:29 PM, Jan Beulich  wrote:
 On 28.04.17 at 12:16,  wrote:
>> On Fri, Apr 28, 2017 at 9:23 AM, Jan Beulich  wrote:
>>> >>> On 27.04.17 at 18:56,  wrote:
>>> > 2. xen/drivers/passthrough/vtd/x86/vtd.c:143:
>>> > ...
>>> > tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
>>> > for ( j = 0; j < tmp; j++ )
>>> > {
>>> > int ret = iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
>>> >  IOMMUF_readable|IOMMUF_writable);
>>> >
>>> > if ( !rc )
>>> >rc = ret;
>>> > }
>>> > ...
>>> >
>>> > Here we don't try to rollback mapping at all. Was the idea to do so? Or 
>>> > was
>>> > this place simply missed?
>>>
>>> Did you consider both the context this is in (establishing hwdom
>>> mappings) and the code's history? Both would tell you that yes,
>>> this is a best effort mapping attempt deliberately continuing
>>> despite errors (but reporting the first one). This behavior will
>>> need to be retained. Plus I'm sure you've noticed that this
>>> effectively is a single page mapping only anyway (due to
>>> PAGE_SHIFT == PAGE_SHIFT_4K); I have no idea why this
>>> "clever" code was used.
>> So, if I understand what your meant I don't even need to try to
>> optimize this code.
>> Despite the fact that this code would become much more simple:
>> ...
>> rc = iommu_map_pages(d, pfn, pfn, 1,
>>   IOMMUF_readable|IOMMUF_writable);
>> ...
>> Right?
>
> Well, the actual simplification is entirely independent of you patch;
> what you'd add is just the extra order argument (which ought to
> be zero, btw). I am, however, of the opinion that the simplification
> would be good to do, but independent of your patch, and only
> unless the VT-d maintainers actually think there is a reason for this
> "cleverness".
Clear enough.

>
>>> > I can introduce something like this:
>>> >
>>> > #define __iommu_map_pages(d,gfn,mfn,order,flags)
>>> > (iommu_map_pages(d,gfn,mfn,1U << (order),flags))
>>>
>>> I'd prefer if you didn't. In no case should this be an identifier
>>> starting with an underscore.
>> I got it. I proposed because I had seen analogy with
>> __map_domain_page/map_domain_page.
>
> Well, there are quite a few things in long standing code which
> we wouldn't allow in new instances of anymore, one of which
> being the non-standard-conforming use of leading underscores.
> Eventually old code would be nice to be cleaned up too, but
> that's tedious and time consuming, and most if not all of us
> have better uses for their time. So commonly we do such
> cleanup only when respective code needs touching anyway.
Clear enough.

>
> Jan
>

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH] kexec: Provide user friendly option for memory limit

2017-04-28 Thread Simon Crowe

Jan

Ok i will make the change and resubmit

Thanks again

Regards



On Fri, Apr 28, 2017 at 11:37 AM +0100, "Jan Beulich" 
> wrote:


>>> On 27.04.17 at 14:22,  wrote:
> @@ -162,6 +166,10 @@ static void __init parse_crashkernel(const char *str)
>  kexec_crash_area.start = parse_size_and_unit(cur = str + 1, 
> );
>  else if ( *str == '<' )
>  kexec_crash_area_limit = parse_size_and_unit(cur = str + 1, 
> );
> +else if ( !strncmp(str, ",below=", 7) )
> +{
> +kexec_crash_area_limit = parse_size_and_unit(cur = str + 7, 
> );
> +}
>  else
>  printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);

The braces you add are inconsistent with surrounding code. With
them dropped
Reviewed-by: Jan Beulich

You should also have Cc-ed the maintainer of the code.

Jan


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

Re: [Xen-devel] [PATCH] kexec: Provide user friendly option for memory limit

>>> On 27.04.17 at 14:22,  wrote:
> @@ -162,6 +166,10 @@ static void __init parse_crashkernel(const char *str)
>  kexec_crash_area.start = parse_size_and_unit(cur = str + 1, 
> );
>  else if ( *str == '<' )
>  kexec_crash_area_limit = parse_size_and_unit(cur = str + 1, 
> );
> +else if ( !strncmp(str, ",below=", 7) )
> +{
> +kexec_crash_area_limit = parse_size_and_unit(cur = str + 7, 
> );
> +}
>  else
>  printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);

The braces you add are inconsistent with surrounding code. With
them dropped
Reviewed-by: Jan Beulich 

You should also have Cc-ed the maintainer of the code.

Jan


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

Re: [Xen-devel] [RFC PATCH 2/9] iommu: Add ability to map/unmap the number of pages

>>> On 28.04.17 at 12:16,  wrote:
> On Fri, Apr 28, 2017 at 9:23 AM, Jan Beulich  wrote:
>> >>> On 27.04.17 at 18:56,  wrote:
>> > 2. xen/drivers/passthrough/vtd/x86/vtd.c:143:
>> > ...
>> > tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
>> > for ( j = 0; j < tmp; j++ )
>> > {
>> > int ret = iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
>> >  IOMMUF_readable|IOMMUF_writable);
>> >
>> > if ( !rc )
>> >rc = ret;
>> > }
>> > ...
>> >
>> > Here we don't try to rollback mapping at all. Was the idea to do so? Or was
>> > this place simply missed?
>>
>> Did you consider both the context this is in (establishing hwdom
>> mappings) and the code's history? Both would tell you that yes,
>> this is a best effort mapping attempt deliberately continuing
>> despite errors (but reporting the first one). This behavior will
>> need to be retained. Plus I'm sure you've noticed that this
>> effectively is a single page mapping only anyway (due to
>> PAGE_SHIFT == PAGE_SHIFT_4K); I have no idea why this
>> "clever" code was used.
> So, if I understand what your meant I don't even need to try to
> optimize this code.
> Despite the fact that this code would become much more simple:
> ...
> rc = iommu_map_pages(d, pfn, pfn, 1,
>   IOMMUF_readable|IOMMUF_writable);
> ...
> Right?

Well, the actual simplification is entirely independent of you patch;
what you'd add is just the extra order argument (which ought to
be zero, btw). I am, however, of the opinion that the simplification
would be good to do, but independent of your patch, and only
unless the VT-d maintainers actually think there is a reason for this
"cleverness".

>> > I can introduce something like this:
>> >
>> > #define __iommu_map_pages(d,gfn,mfn,order,flags)
>> > (iommu_map_pages(d,gfn,mfn,1U << (order),flags))
>>
>> I'd prefer if you didn't. In no case should this be an identifier
>> starting with an underscore.
> I got it. I proposed because I had seen analogy with
> __map_domain_page/map_domain_page.

Well, there are quite a few things in long standing code which
we wouldn't allow in new instances of anymore, one of which
being the non-standard-conforming use of leading underscores.
Eventually old code would be nice to be cleaned up too, but
that's tedious and time consuming, and most if not all of us
have better uses for their time. So commonly we do such
cleanup only when respective code needs touching anyway.

Jan

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

Re: [Xen-devel] [RFC PATCH 2/9] iommu: Add ability to map/unmap the number of pages

2017-04-28 Thread Oleksandr Tyshchenko

Hi, Jan.

Thank you for your reply.

On Fri, Apr 28, 2017 at 9:23 AM, Jan Beulich  wrote:
>
> >>> On 27.04.17 at 18:56,  wrote:
> > Now I am trying to replace single-page stuff with the multi-page one.
> > Currently, with the single-page API, if map fails we always try to unmap
> > already mapped pages.
> >
> > This is an example of generic code I am speaking about:
> > ...
> > for ( i = 0; i < (1 << order); i++ )
> > {
> > rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> > if ( unlikely(rc) )
> > {
> > while ( i-- )
> > /* If statement to satisfy __must_check. */
> > if ( iommu_unmap_page(p2m->domain, gfn + i) )
> > continue;
> >
> > break;
> > }
> > }
> > ...
> >
> > After modification the generic code will look like:
> > ...
> > rc = iommu_map_pages(d, gfn, mfn_x(mfn), 1 << order, iommu_flags);
> > ...
> > In case of an error we won't know how many pages have been already mapped
> > and
> > as the result we won't be able to unmap them in order to restore the
> > initial state.
> > Therefore I will move the rollback logic to the IOMMU drivers code. So, the
> > IOMMU drivers code
> > will take care of rollback mapping if something goes wrong. Am I right?
>
> Yes, it should be iommu_map_pages() (or its descendants) to clean
> up after itself upon error.
>
> > If all described above make sense, then there are several places I am
> > trying to optimize, but I am not familiar with)
> >
> > 1. xen/arch/x86/x86_64/mm.c:1443:
> > ...
> > if ( iommu_enabled && !iommu_passthrough && !need_iommu(hardware_domain) )
> > {
> > for ( i = spfn; i < epfn; i++ )
> > if ( iommu_map_page(hardware_domain, i, i,
> > IOMMUF_readable|IOMMUF_writable)
> > )
> > break;
> > if ( i != epfn )
> > {
> > while (i-- > old_max) // <--- [1]
> > /* If statement to satisfy __must_check. */
> > if ( iommu_unmap_page(hardware_domain, i) )
> > continue;
> >
> > goto destroy_m2p;
> > }
> > }
> > ...
> >
> > [1] Shouldn't we unmap already mapped pages only?  I mean to use "while
> > (i-- > spfn)" instead.
>
> Both should have the same effect, considering what old_max
> represents, at least as long as there's no MMIO in between. But
> yes, generally it would be more logical to unmap using spfn.
>
> > And if the use of "old_max" here has a special meaning, I think, that this
> > place of code won't be optimized
> > by passing the whole memory block (epfn - spfn) to the IOMMU. Just keep it
> > as is (handle one page at time).
>
> Right, that would have been my general advice: If in doubt, keep
> the code as is rather than trying to optimize it.
OK

>
>
> > 2. xen/drivers/passthrough/vtd/x86/vtd.c:143:
> > ...
> > tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
> > for ( j = 0; j < tmp; j++ )
> > {
> > int ret = iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
> >  IOMMUF_readable|IOMMUF_writable);
> >
> > if ( !rc )
> >rc = ret;
> > }
> > ...
> >
> > Here we don't try to rollback mapping at all. Was the idea to do so? Or was
> > this place simply missed?
>
> Did you consider both the context this is in (establishing hwdom
> mappings) and the code's history? Both would tell you that yes,
> this is a best effort mapping attempt deliberately continuing
> despite errors (but reporting the first one). This behavior will
> need to be retained. Plus I'm sure you've noticed that this
> effectively is a single page mapping only anyway (due to
> PAGE_SHIFT == PAGE_SHIFT_4K); I have no idea why this
> "clever" code was used.
So, if I understand what your meant I don't even need to try to
optimize this code.
Despite the fact that this code would become much more simple:
...
rc = iommu_map_pages(d, pfn, pfn, 1,
  IOMMUF_readable|IOMMUF_writable);
...
Right?

>
> And as a side note - the way you quote code (by line number and
> without naming the function it's in) makes it somewhat more
> complicated to answer your questions. In both cases, had I known
> the function the code is in, I wouldn't have had a need at all to go
> look up the context.
Sorry for that. Next time I will provide more detailed snippet.

>
> > P.S. As for using "order" parameter instead of page_count.
> > There are *few* places where "order" doesn't fit.
>
> Well, I'd prefer the "few places" to then break up their requests to
> fit the "order" parameter. Especially for the purpose of possibly
> using large pages, an order input is quite a bit more sensible.
OK

>
> > I can introduce something like this:
> >
> > #define __iommu_map_pages(d,gfn,mfn,order,flags)
> > (iommu_map_pages(d,gfn,mfn,1U << (order),flags))
>
> I'd prefer if you didn't. In no case should this be an identifier
> starting with an underscore.
I got it. I proposed because I had seen analogy with
__map_domain_page/map_domain_page.

>
> Jan

-- 
Regards,

Re: [Xen-devel] superpages lost after migration of HVM domU

2017-04-28 Thread Olaf Hering

On Wed, Apr 26, Andrew Cooper wrote:

> On 26/04/17 16:43, Olaf Hering wrote:
> > On Thu, Apr 20, Jan Beulich wrote:
> >
> > On 20.04.17 at 18:04,  wrote:
> >>> On Thu, Apr 20, Andrew Cooper wrote:
> >>>
>  As it currently stands, the sending side iterates from 0 to p2m_size,
>  and sends every frame on the first pass.  This means we get PAGE_DATA
>  records linearly, in batches of 1024, or two aligned 2M superpages.
> >>> Is there a way to preserve 1G pages? This 380G domU I'm looking at is
> >>> built with 4k:461390 2M:2341 1G:365 pages.
> >> I think we've hashed out a possible way to deal with this, by
> >> speculatively allocating 1G pages as long as the allocation cap for
> >> the domain allows, subsequently punching holes into those pages
> >> if we can't allocate any new pages anymore (due to otherwise
> >> overrunning the cap).
> > The result is not pretty. This HVM-only approach appears to work for a
> > domU with "memory=3024" and localhost migration.
> > It is required to punch holes as soon as possible to avoid errors in
> > xenforeignmemory_map due to "Over-allocation". Would be nice if the
> > receiver gets a memory map upfront to avoid all stunts...
> 
> Oh - I was about to start working on this.  This is a pleasant surprise. :)

Here is a variant that actually works for migration between two dom0s.

--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -107,6 +107,9 @@ struct xc_sr_save_ops
  */
 struct xc_sr_restore_ops
 {
+/* Allocate a MFN for the given PFN */
+int (*allocate_pfn)(struct xc_sr_context *ctx, xen_pfn_t pfn);
+
 /* Convert a PFN to GFN.  May return ~0UL for an invalid mapping. */
 xen_pfn_t (*pfn_to_gfn)(const struct xc_sr_context *ctx, xen_pfn_t pfn);
 
@@ -172,6 +175,52 @@ struct xc_sr_x86_pv_restore_vcpu
 size_t basicsz, extdsz, xsavesz, msrsz;
 };
 
+struct xc_sr_bitmap
+{
+void *p;
+unsigned long bits;
+};
+
+extern bool _xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned long bits);
+static inline bool xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned long 
bits)
+{
+if (bits > bm->bits)
+return _xc_sr_bitmap_resize(bm, bits);
+return true;
+}
+
+static inline void xc_sr_bitmap_free(struct xc_sr_bitmap *bm)
+{
+free(bm->p);
+}
+
+static inline bool xc_sr_set_bit(unsigned long bit, struct xc_sr_bitmap *bm)
+{
+if (!xc_sr_bitmap_resize(bm, bit))
+return false;
+
+set_bit(bit, bm->p);
+return true;
+}
+
+static inline bool xc_sr_test_bit(unsigned long bit, struct xc_sr_bitmap *bm)
+{
+if (bit > bm->bits)
+return false;
+return !!test_bit(bit, bm->p);
+}
+
+static inline int xc_sr_test_and_clear_bit(unsigned long bit, struct 
xc_sr_bitmap *bm)
+{
+return test_and_clear_bit(bit, bm->p);
+}
+
+static inline int xc_sr_test_and_set_bit(unsigned long bit, struct 
xc_sr_bitmap *bm)
+{
+return test_and_set_bit(bit, bm->p);
+}
+
+
 struct xc_sr_context
 {
 xc_interface *xch;
@@ -256,8 +305,7 @@ struct xc_sr_context
 domid_t  xenstore_domid,  console_domid;
 
 /* Bitmap of currently populated PFNs during restore. */
-unsigned long *populated_pfns;
-xen_pfn_t max_populated_pfn;
+struct xc_sr_bitmap populated_pfns;
 
 /* Sender has invoked verify mode on the stream. */
 bool verify;
@@ -332,6 +380,12 @@ struct xc_sr_context
 /* HVM context blob. */
 void *context;
 size_t contextsz;
+
+/* Bitmap of currently allocated PFNs during restore. */
+struct xc_sr_bitmap attempted_1g;
+struct xc_sr_bitmap attempted_2m;
+struct xc_sr_bitmap allocated_pfns;
+unsigned long alloc_cnt;
 } restore;
 };
 } x86_hvm;
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -71,11 +71,9 @@ static int read_headers(struct xc_sr_con
 /*
  * Is a pfn populated?
  */
-static bool pfn_is_populated(const struct xc_sr_context *ctx, xen_pfn_t pfn)
+static bool pfn_is_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
 {
-if ( pfn > ctx->restore.max_populated_pfn )
-return false;
-return test_bit(pfn, ctx->restore.populated_pfns);
+return xc_sr_test_bit(pfn, >restore.populated_pfns);
 }
 
 /*
@@ -87,42 +85,12 @@ static int pfn_set_populated(struct xc_s
 {
 xc_interface *xch = ctx->xch;
 
-if ( pfn > ctx->restore.max_populated_pfn )
+if ( !xc_sr_set_bit(pfn, >restore.populated_pfns) )
 {
-xen_pfn_t new_max;
-size_t old_sz, new_sz;
-unsigned long *p;
-
-/* Round up to the nearest power of two larger than pfn, less 1. */
-new_max = pfn;
-new_max |= new_max >> 1;
-new_max |= new_max >> 2;
-new_max |= new_max >> 4;
-new_max |= new_max >> 8;
-new_max |= new_max

Re: [Xen-devel] [PATCH for-4.9 v2] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

>>> On 28.04.17 at 11:09,  wrote:
> On Fri, Apr 28, 2017 at 02:36:11AM -0600, Jan Beulich wrote:
> On 27.04.17 at 04:47,  wrote:
>>> --- a/xen/include/asm-x86/hvm/vpt.h
>>> +++ b/xen/include/asm-x86/hvm/vpt.h
>>> @@ -46,6 +46,12 @@ struct periodic_time {
>>>  #define PTSRC_lapic  2 /* LAPIC time source */
>>>  u8 source;  /* PTSRC_ */
>>>  u8 irq;
>>> +/*
>>> + * Vector set in vIRR in one interrupt delivery. Using this value can
>>> + * avoid reading the IOAPIC RTE again. Valid only when its source is
>>> + * 'PTSRC_isa' and handled by vlapic.
>>> + */
>>> +int16_t latched_vector;
>>
>>Why is this PTSRC_isa specific? In the description you say
>>"for example, if a periodic timer interrupt is from PIT".
> 
> PTSRC_lapic means the pt is lapic interrupt timer. We can read 'irq'
> field directly from structure periodic_timer. For other cases, namely
> PTSRC_isa, we should get vector from vioapic or vpic.

Oh, I'm sorry - PTSRC_isa covers all of HPET, PIT, and RTC.
This aspect is fine then as is.

Jan


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

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

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

Regressions :-(

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

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-libvirt   5 libvirt-buildfail REGR. vs. 107640
 build-i386-libvirt5 libvirt-buildfail REGR. vs. 107640
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 107640
 build-armhf-libvirt   5 libvirt-buildfail REGR. vs. 107640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  5ade0ff90581cddce71dd40840ca72f87825cb54
baseline version:
 libvirt  5efa7f2a4bf2e316ca74b5baad053a18cffd00b9

Last test of basis   107640  2017-04-25 04:21:01 Z3 days
Failing since107696  2017-04-26 04:20:12 Z2 days3 attempts
Testing same since   107851  2017-04-28 04:20:05 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  CÃ©dric Bosdonnat 
  Daniel P. Berrange 
  Eric Farman 
  Erik Skultety 
  Jim Fehlig 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  JÃ¡n Tomko 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Wang King 
  Wim ten Have 
  ZhiPeng Lu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked

[Xen-devel] [PATCH] kexec: Provide user friendly option for memory limit

2017-04-28 Thread Simon Crowe


grub2 requires that the '<' character be escaped which is
inconvienet for users, provide a more natural specifier.

Signed-off-by: Simon Crowe 
---
 docs/misc/kexec_and_kdump.txt   |  8 +++-
 docs/misc/xen-command-line.markdown |  5 +
 xen/common/kexec.c  | 12 ++--
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/docs/misc/kexec_and_kdump.txt b/docs/misc/kexec_and_kdump.txt
index 2f93771..0842b3d 100644
--- a/docs/misc/kexec_and_kdump.txt
+++ b/docs/misc/kexec_and_kdump.txt
@@ -136,7 +136,13 @@ command line parameter to the Xen hypervisor. It has two 
forms:

   e.g. crashkernel=128M@256M

-   Regardless of which of the two forms of the crashkernel command line you
+  iii) crashkernel=size,below=offset
+
+  This allows us to place the crash kernel within the usuable address
+  space without having to worry about a specific phyiscal address.
+  The '<' and 'below' options are  synonymous
+
+   Regardless of which of the forms of the crashkernel command line you
use, the crash kernel region should appear in /proc/iomem on x86. If it
doesn't then either the crashkernel parameter is missing, or for some
reason the region couldn't be placed - for instance because it is too large.
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 450b222..59e51dc 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -474,6 +474,7 @@ combination with the `low_crashinfo` command line option.
 ### crashkernel
 > `= :[,...][{@,<}]`
 > `= [{@,<}]`
+> `= ,below=offset`

 Specify sizes and optionally placement of the crash kernel reservation
 area.  The `:` pairs indicate how much memory to
@@ -485,6 +486,10 @@ A trailing `@` specifies the exact address this 
area should be
 placed at, whereas `<` in place of `@` just specifies an upper bound of
 the address range the area should fall into.

+< and below are synonyomous, the latter being useful for grub2 systems
+which would otherwise require escaping of the < option
+
+
 ### credit2\_balance\_over
 > `= `

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index fbca8a6..3381070 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -88,7 +88,7 @@ static void *crash_heap_current = NULL, *crash_heap_end = 
NULL;
 /*
  * Parse command lines in the format
  *
- *   crashkernel=:[,...][{@,<}]
+ *   crashkernel=:[,...][{@,<,below=}]
  *
  * with  being of form
  *
@@ -97,6 +97,10 @@ static void *crash_heap_current = NULL, *crash_heap_end = 
NULL;
  * as well as the legacy ones in the format
  *
  *   crashkernel=[{@,<}]
+ *   crashkernel=,below=address
+ *
+ * < and below are synonyomous, the latter being useful for grub2 systems
+ * which would otherwise require escaping of the < option
  */
 static void __init parse_crashkernel(const char *str)
 {
@@ -111,7 +115,7 @@ static void __init parse_crashkernel(const char *str)
 {
 printk(XENLOG_WARNING "crashkernel: too many ranges\n");
 cur = NULL;
-str = strpbrk(str, "@<");
+str = strpbrk(str, "@,<");
 break;
 }

@@ -162,6 +166,10 @@ static void __init parse_crashkernel(const char *str)
 kexec_crash_area.start = parse_size_and_unit(cur = str + 1, );
 else if ( *str == '<' )
 kexec_crash_area_limit = parse_size_and_unit(cur = str + 1, );
+else if ( !strncmp(str, ",below=", 7) )
+{
+kexec_crash_area_limit = parse_size_and_unit(cur = str + 7, );
+}
 else
 printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);
 }
--
2.7.4

?

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

Re: [Xen-devel] [PATCH for-4.9 v2] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

2017-04-28 Thread Chao Gao

On Fri, Apr 28, 2017 at 02:36:11AM -0600, Jan Beulich wrote:
 On 27.04.17 at 04:47,  wrote:
>> When injecting periodic timer interrupt in vmx_intr_assist(),
>> multi-read operations are done during one event delivery. For
>> example, if a periodic timer interrupt is from PIT, when set the
>> corresponding bit in vIRR, the corresponding RTE is accessed in
>> pt_update_irq(). When this function returns, it accesses the RTE
>> again to get the vector it sets in vIRR.  Between the two
>> accesses, the content of RTE may have been changed by another CPU
>> for no protection method in use. This case can incur the
>> assertion failure in vmx_intr_assist().
>
>Btw., irrespective of this I'm not convinced this patch really is
>4.9 material: While analyzing possible causes for the ASSERT()
>to trigger, you've found a way no real OS would ever use. And
>we'll need to do something about that ASSERT() anyway before
>4.9 goes out.

Fine to me.

>> @@ -253,6 +263,7 @@ int pt_update_irq(struct vcpu *v)
>>  struct periodic_time *pt, *temp, *earliest_pt;
>>  uint64_t max_lag;
>>  int irq, is_lapic;
>> +bool handle_by_pic = false;
>
>What do you need this variable for? You can simply clear is_lapic
>instead. And if you needed it, please follow the naming of the
>other one (i.e. would want to be is_pic).

The interrupt source and interrupt controller is different here.
for interrupt source we have RTSRC_isa and RTSRC_lapic.
I think is_lapic is related to interrupt source.
and 'handle_by_pic' means that vpic relay this interrupt, which
is relevant to struct hvm_intsrc. Anyhow, it is not a big problem.

>
>> @@ -297,7 +308,15 @@ int pt_update_irq(struct vcpu *v)
>>  else
>>  {
>>  hvm_isa_irq_deassert(v->domain, irq);
>> -hvm_isa_irq_assert(v->domain, irq);
>> +spin_lock(>domain->arch.hvm_domain.irq_lock);
>> +hvm_isa_irq_assert_locked(v->domain, irq);
>> +if ( platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) &&
>> +(>domain->arch.hvm_domain)->vpic[irq >> 3].int_output )
>
>Please don't pointlessly complicate expressions: There's no need
>to take the address of v->domain->arch.hvm_domain here. (I
>notice that it has been this way originally, but as you're touching
>it, you should also clean this up.)

will do.

>
>> +{
>> +handle_by_pic = true;
>> +pt_set_latched_vector(earliest_pt, hvm_intsrc_lapic);
>
>I don't follow: If the interrupt is to be handled by the PIC, why
>do you need to latch the vector in that case at all, and even
>more so _only_ in that case? When delivered via PIC, the IO-APIC
>RTE won't have a valid vector field anyway (it's supposed to be
>in ExtINT mode; see __vlapic_accept_pic_intr()). Am I overlooking
>anything here?

Ok. I made a mistake here. Only need latching vector for the inverse case.

>
>> @@ -305,12 +324,7 @@ int pt_update_irq(struct vcpu *v)
>>   * IRR is returned and used to set eoi_exit_bitmap for virtual
>>   * interrupt delivery case. Otherwise return -1 to do nothing.  
>>   */ 
>> -if ( !is_lapic &&
>> - platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) &&
>> - (>domain->arch.hvm_domain)->vpic[irq >> 3].int_output )
>> -return -1;
>> -else 
>> -return pt_irq_vector(earliest_pt, hvm_intsrc_lapic);
>> +return handle_by_pic ? -1 : pt_irq_vector(earliest_pt, 
>> hvm_intsrc_lapic);
>
>Please either use unlikely() or invert the condition and swap the
>other two operands.

Agree.

>
>> --- a/xen/include/asm-x86/hvm/vpt.h
>> +++ b/xen/include/asm-x86/hvm/vpt.h
>> @@ -46,6 +46,12 @@ struct periodic_time {
>>  #define PTSRC_lapic  2 /* LAPIC time source */
>>  u8 source;  /* PTSRC_ */
>>  u8 irq;
>> +/*
>> + * Vector set in vIRR in one interrupt delivery. Using this value can
>> + * avoid reading the IOAPIC RTE again. Valid only when its source is
>> + * 'PTSRC_isa' and handled by vlapic.
>> + */
>> +int16_t latched_vector;
>
>Why is this PTSRC_isa specific? In the description you say
>"for example, if a periodic timer interrupt is from PIT".

PTSRC_lapic means the pt is lapic interrupt timer. We can read 'irq'
field directly from structure periodic_timer. For other cases, namely
PTSRC_isa, we should get vector from vioapic or vpic. For cases handle
by vpic, the vector is generated in hvm_vcpu_ack_pending_irq(). I can
latched here. So we have two restrictions. The first one is easy to
remove. The latter I think needs some changes to
hvm_vcpu_ack_pending_irq().

>
>And then, if there is a requirement for this to be handled by the
>LAPIC, you don't need a 16-bit field: You can easily use 0 to
>indicate the field is not valid, as vectors below 0x10 are all invalid
>in that case.

will do.

Thanks
Chao

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

Re: [Xen-devel] [PATCH for-next v3 12/12] x86/pv/domain: clean up switch_compat

>>> On 26.04.17 at 17:54,  wrote:
> Remove the redundant is_pv_domain check. Rearrange setup_compat calls.

Well, as said earlier, I don't really see the value of the latter, but
anyway ...

> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-next v3 11/12] x86/pv/domain: clean up setup_compat_l4

>>> On 26.04.17 at 17:54,  wrote:
> Move updating type_info after clearing the page. Add spaces.

Suggested-by: Andrew ... ?

> Signed-off-by: Wei Liu 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-next v3 09/12] x86/domain: move PV specific code to pv/domain.c

>>> On 26.04.17 at 17:54,  wrote:
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -655,6 +655,9 @@ static inline void pv_inject_page_fault(int errcode, 
> unsigned long cr2)
>  pv_inject_event();
>  }
>  
> +void paravirt_ctxt_switch_from(struct vcpu *v);
> +void paravirt_ctxt_switch_to(struct vcpu *v);

I think these would better go ...

> --- /dev/null
> +++ b/xen/include/asm-x86/pv/domain.h
> @@ -0,0 +1,57 @@
> +/*
> + * pv/domain.h
> + *
> + * PV guest interface definitions
> + *
> + * Copyright (C) 2017 Wei Liu 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#ifndef __X86_PV_DOMAIN_H__
> +#define __X86_PV_DOMAIN_H__
> +
> +#ifdef CONFIG_PV
> +
> +void pv_vcpu_destroy(struct vcpu *v);
> +int pv_vcpu_initialise(struct vcpu *v);
> +void pv_domain_destroy(struct domain *d);
> +int pv_domain_initialise(struct domain *d, unsigned int domcr_flags,
> + struct xen_arch_domainconfig *config);
> +
> +#else  /* !CONFIG_PV */
> +
> +#include 
> +
> +static inline void pv_vcpu_destroy(struct vcpu *v) {}
> +static inline int pv_vcpu_initialise(struct vcpu *v) { return -EOPNOTSUPP; }
> +static inline void pv_domain_destroy(struct domain *d) {}
> +static inline int pv_domain_initialise(struct domain *d,
> +   unsigned int domcr_flags,
> +   struct xen_arch_domainconfig *config);
> +{
> +return -EOPNOTSUPP;
> +}
> +#endif   /* CONFIG_PV */

... here. The idle domain is a PV one after all, just that we'll always
need it even with CONFIG_PV off.

Also pv/domain.c needs to include this new header - as pointed
out before, both producer and consumer(s) need to see the same
declarations.

Jan


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

[Xen-devel] [seabios test] 107867: regressions - FAIL

flight 107867 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107867/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   29 days
Testing same since   107663  2017-04-25 17:17:46 Z2 days   27 attempts


People who touched revisions under test:
  Julius Werner 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to

[Xen-devel] [distros-debian-jessie test] 71239: regressions - trouble: blocked/broken/fail/pass

2017-04-28 Thread Platform Team regression test user

flight 71239 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71239/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 14 guest-start/debian.repeat fail 
REGR. vs. 71214

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   71214

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH for-next v3 07/12] x86/domain: factor out pv_domain_destroy

>>> On 26.04.17 at 17:54,  wrote:
> Now this function also frees the perdomain mapping. It is safe to do so
> because destroy_perdomain_mapping is idempotent.
> 
> Move free_perdomain_mappings after pv_domain_destroy. It is safe to do
> so because both destroy_perdomain_mapping and free_perdomain_mappings
> are idempotent.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-next v3 05/12] x86/domain: factor out pv_vcpu_initialise

>>> On 26.04.17 at 17:54,  wrote:
> Move PV specific vcpu initialisation code to said function, but leave
> the only line needed by idle domain in vcpu_initialise.
> 
> Use pv_vcpu_destroy in error path to simplify code. It is safe to do so
> because the destruction function accepts partially initialised vcpu
> struct.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-next v3 02/12] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

>>> On 26.04.17 at 17:54,  wrote:
> This patch encapsulates the perdomain creation and destruction into
> helper functions and use them where appropriate.
> 
> Since destroy_perdomain_mapping is idempotent, it is safe to call the
> destruction function multiple times.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-4.9 v2] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

>>> On 27.04.17 at 04:47,  wrote:
> When injecting periodic timer interrupt in vmx_intr_assist(),
> multi-read operations are done during one event delivery. For
> example, if a periodic timer interrupt is from PIT, when set the
> corresponding bit in vIRR, the corresponding RTE is accessed in
> pt_update_irq(). When this function returns, it accesses the RTE
> again to get the vector it sets in vIRR.  Between the two
> accesses, the content of RTE may have been changed by another CPU
> for no protection method in use. This case can incur the
> assertion failure in vmx_intr_assist().

Btw., irrespective of this I'm not convinced this patch really is
4.9 material: While analyzing possible causes for the ASSERT()
to trigger, you've found a way no real OS would ever use. And
we'll need to do something about that ASSERT() anyway before
4.9 goes out.

> This patch introduces a new field 'latched_vector' to structure
> periodic_timer. The field is only valid between calling pt_update_irq()
> and calling pt_irq_posted() in vmx_intr_assist(). The new field is set
> to the vector we set in vIRR at the first access we describe above, is
> used in the following two accesses through calling pt_irq_vector() and
> finally cleared in pt_irq_posted() or updated in next calling
> vmx_intr_assist().

Please refer to the correct functions - there's no pt_irq_posted(), and
vmx_intr_assist() doesn't itself update the field.

> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -75,33 +75,43 @@ void hvm_set_guest_time(struct vcpu *v, u64 guest_time)
>  }
>  }
>  
> -static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src)
> +static void pt_set_latched_vector(struct periodic_time *pt, enum hvm_intsrc 
> src)
>  {
>  struct vcpu *v = pt->vcpu;
>  struct hvm_vioapic *vioapic;

Both should be const. Also you don't really need v anywhere below,
all uses are v->domain.

> -unsigned int gsi, isa_irq, pin;
> +unsigned int gsi, pin;
> +
> +ASSERT(pt->source == PTSRC_isa);
> +ASSERT(src == hvm_intsrc_lapic);
> +gsi = hvm_isa_irq_to_gsi(pt->irq);
> +vioapic = gsi_vioapic(v->domain, gsi, );
> +if ( !vioapic )
> +{
> +dprintk(XENLOG_WARNING, "d%u: invalid GSI (%u) for platform timer\n",
> +v->domain->domain_id, gsi);
> +domain_crash(v->domain);
> +return;
> +}
> +
> +pt->latched_vector = vioapic->redirtbl[pin].fields.vector;
> +}
> +
> +static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src)
> +{
> +struct vcpu *v = pt->vcpu;

There is not need for this local variable - it's used exactly once (and
then again only to get to the domain).

> +unsigned int isa_irq;
>  
>  if ( pt->source == PTSRC_lapic )
>  return pt->irq;
>  
>  isa_irq = pt->irq;
> -gsi = hvm_isa_irq_to_gsi(isa_irq);
>  
>  if ( src == hvm_intsrc_pic )
>  return (v->domain->arch.hvm_domain.vpic[isa_irq >> 3].irq_base
>  + (isa_irq & 7));
>  
>  ASSERT(src == hvm_intsrc_lapic);
> -vioapic = gsi_vioapic(v->domain, gsi, );
> -if ( !vioapic )
> -{
> -dprintk(XENLOG_WARNING, "d%u: invalid GSI (%u) for platform timer\n",
> -v->domain->domain_id, gsi);
> -domain_crash(v->domain);
> -return -1;
> -}
> -
> -return vioapic->redirtbl[pin].fields.vector;
> +return pt->latched_vector;
>  }



> @@ -253,6 +263,7 @@ int pt_update_irq(struct vcpu *v)
>  struct periodic_time *pt, *temp, *earliest_pt;
>  uint64_t max_lag;
>  int irq, is_lapic;
> +bool handle_by_pic = false;

What do you need this variable for? You can simply clear is_lapic
instead. And if you needed it, please follow the naming of the
other one (i.e. would want to be is_pic).

> @@ -297,7 +308,15 @@ int pt_update_irq(struct vcpu *v)
>  else
>  {
>  hvm_isa_irq_deassert(v->domain, irq);
> -hvm_isa_irq_assert(v->domain, irq);
> +spin_lock(>domain->arch.hvm_domain.irq_lock);
> +hvm_isa_irq_assert_locked(v->domain, irq);
> +if ( platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) &&
> +(>domain->arch.hvm_domain)->vpic[irq >> 3].int_output )

Please don't pointlessly complicate expressions: There's no need
to take the address of v->domain->arch.hvm_domain here. (I
notice that it has been this way originally, but as you're touching
it, you should also clean this up.)

> +{
> +handle_by_pic = true;
> +pt_set_latched_vector(earliest_pt, hvm_intsrc_lapic);

I don't follow: If the interrupt is to be handled by the PIC, why
do you need to latch the vector in that case at all, and even
more so _only_ in that case? When delivered via PIC, the IO-APIC
RTE won't have a valid vector field anyway (it's supposed to be
in ExtINT mode; see __vlapic_accept_pic_intr()). Am I overlooking
anything here?

> @@ -305,12 +324,7 @@ int pt_update_irq(struct vcpu *v)
>

Re: [Xen-devel] [Qemu-devel] [PATCH v5 06/10] qobject: Use simpler QDict/QList scalar insertion macros

Eric Blake  writes:

> We now have macros in place to make it less verbose to add a scalar
> to QDict and QList, so use them.  To make this patch smaller to
> review, a couple of subdirectories were done in earlier patches.

Scratch the last sentence.  Can do on commit.

> Patch created mechanically via:
>   spatch --sp-file scripts/coccinelle/qobject.cocci \
> --macro-file scripts/cocci-macro-file.h --dir . --in-place
> then touched up manually to fix a couple of '?:' back to original
> spacing, as well as avoiding a long line in monitor.c.
>
> Signed-off-by: Eric Blake 
> Reviewed-by: Markus Armbruster 
>
> ---
> v5: rebase to master (Coccinelle found a couple new spots), squash 3
> patches into 1, adjust R-b to only list Markus (while there were other
> reviews on the pre-squashed patches, Markus was the only one on all 3)

The block: part had

Acked-by: Richard W.M. Jones 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Alberto Garcia 

The tests and qobject parts had

Reviewed-by: Philippe Mathieu-Daudé 

Richard, Stefan, Alberto, Philippe, let me know if you'd like me to
convert your R-by of parts to an Acked-by of the combined patch.  Feel
free to review the combined patch, of course.

> v4: no change
> v3: new patch

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

[Xen-devel] [linux-4.9 test] 107829: regressions - trouble: broken/fail/pass

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken pass in 107776
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 107776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 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-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass

version targeted for testing:
 linuxa8c90ef62281db933118aa84489eb0e1e9cc347c
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   17 days
Failing since107396  2017-04-12 11:15:19 Z   15 days   28 attempts
Testing same since   107776  2017-04-27 09:07:29 Z0 days2 attempts


People who touched revisions under test:
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Alexandre Belloni 
  Amit Pundir 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Smetanin 
  Andy Gross 
  Andy Lutomirski

Re: [Xen-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

* Eric Blake (ebl...@redhat.com) wrote:
> We want to track why a guest was shutdown; in particular, being able
> to tell the difference between a guest request (such as ACPI request)
> and host request (such as SIGINT) will prove useful to libvirt.
> Since all requests eventually end up changing shutdown_requested in
> vl.c, the logical change is to make that value track the reason,
> rather than its current 0/1 contents.
> 
> Since command-line options control whether a reset request is turned
> into a shutdown request instead, the same treatment is given to
> reset_requested.
> 
> This patch adds a QAPI enum ShutdownCause that describes reasons
> that a shutdown can be requested, and changes qemu_system_reset() to
> pass the reason through, although for now it is not reported.  The
> next patch will actually wire things up to modify events to report
> data based on the reason, and to pass the correct enum value in from
> various call-sites that can trigger a reset/shutdown.  Since QAPI
> generates enums starting at 0, it's easier if we use a different
> number as our sentinel that no request has happened yet.  Most of
> the changes are in vl.c, but xen was using things externally.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v4: s/ShutdownType/ShutdownCause/, no thanks to mingw header pollution
> v3: new patch
> ---
>  qapi-schema.json| 23 +++
>  include/sysemu/sysemu.h |  2 +-
>  vl.c| 44 
>  hw/i386/xen/xen-hvm.c   |  9 ++---
>  migration/colo.c|  2 +-
>  migration/savevm.c  |  2 +-
>  6 files changed, 60 insertions(+), 22 deletions(-)
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 01b087f..a4ebdd1 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2304,6 +2304,29 @@
>  { 'command': 'system_powerdown' }
> 
>  ##
> +# @ShutdownCause:
> +#
> +# Enumeration of various causes for shutdown.
> +#
> +# @host-qmp: Reaction to a QMP command, such as 'quit'
> +# @host-signal: Reaction to a signal, such as SIGINT
> +# @host-ui: Reaction to a UI event, such as closing the window
> +# @host-replay: The host is replaying an earlier shutdown event
> +# @host-error: Qemu encountered an error that prevents further use of the 
> guest
> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
> +#  other hardware-specific action
> +# @guest-reset: The guest requested a reset, and the command line
> +#   response to a reset is to instead trigger a shutdown
> +# @guest-panic: The guest panicked, and the command line response to
> +#   a panic is to trigger a shutdown

It's a little coarse grained;  is there anyway to pass platform specific 
information
for debug?  I ask because I spent a while debugging a few bugs with unexpected
resets and had to figure out which of x86's many reset causes triggered it.

Dave

> +# Since: 2.10
> +##
> +{ 'enum': 'ShutdownCause',
> +  'data': [ 'host-qmp', 'host-signal', 'host-ui', 'host-replay', 
> 'host-error',
> +'guest-shutdown', 'guest-reset', 'guest-panic' ] }
> +
> +##
>  # @cpu:
>  #
>  # This command is a nop that is only provided for the purposes of 
> compatibility.
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 16175f7..00a907f 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -65,7 +65,7 @@ bool qemu_vmstop_requested(RunState *r);
>  int qemu_shutdown_requested_get(void);
>  int qemu_reset_requested_get(void);
>  void qemu_system_killed(int signal, pid_t pid);
> -void qemu_system_reset(bool report);
> +void qemu_system_reset(bool report, int reason);
>  void qemu_system_guest_panicked(GuestPanicInformation *info);
>  size_t qemu_target_page_size(void);
> 
> diff --git a/vl.c b/vl.c
> index 879786a..2b95b7f 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1597,8 +1597,8 @@ void vm_state_notify(int running, RunState state)
>  }
>  }
> 
> -static int reset_requested;
> -static int shutdown_requested, shutdown_signal;
> +static int reset_requested = -1;
> +static int shutdown_requested = -1, shutdown_signal;
>  static pid_t shutdown_pid;
>  static int powerdown_requested;
>  static int debug_requested;
> @@ -1624,7 +1624,7 @@ int qemu_reset_requested_get(void)
> 
>  static int qemu_shutdown_requested(void)
>  {
> -return atomic_xchg(_requested, 0);
> +return atomic_xchg(_requested, -1);
>  }
> 
>  static void qemu_kill_report(void)
> @@ -1650,11 +1650,11 @@ static void qemu_kill_report(void)
>  static int qemu_reset_requested(void)
>  {
>  int r = reset_requested;
> -if (r && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) {
> -reset_requested = 0;
> +if (r >= 0 && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) {
> +reset_requested = -1;
>  return r;
>  }
> -return false;
> +return -1;
>  }
> 
>  static int qemu_suspend_requested(void)
> @@ -1686,7 +1686,12 @@

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-multivcpu  6 xen-boot   fail baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 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-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  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-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux19ac4474203863a8141663d73d5976fe25464bfd
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  659 days
Failing since 59348  2015-07-10 04:24:05 Z  658 days  411 attempts
Testing same since   107819  2017-04-27 20:08:37 Z0 days1 attempts


8182 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  fail

Re: [Xen-devel] [PATCH v12 6/6] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

2017-04-28 Thread Zhang, Xiong Y

I found this patch couldn't work, the reason is inline.  And need propose to 
fix this.
> diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
> index 7e0da81..d72b7bd 100644
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -384,15 +384,50 @@ static int dm_op(domid_t domid,
> 
>  case XEN_DMOP_map_mem_type_to_ioreq_server:
>  {
> -const struct xen_dm_op_map_mem_type_to_ioreq_server *data =
> +struct xen_dm_op_map_mem_type_to_ioreq_server *data =
>  _mem_type_to_ioreq_server;
> +unsigned long first_gfn = data->opaque;
> +
> +const_op = false;
> 
>  rc = -EOPNOTSUPP;
>  if ( !hap_enabled(d) )
>  break;
> 
> -rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
> -  data->type, data->flags);
> +if ( first_gfn == 0 )
> +rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
> +  data->type,
> data->flags);
> +else
> +rc = 0;
> +
> +/*
> + * Iterate p2m table when an ioreq server unmaps from
> p2m_ioreq_server,
> + * and reset the remaining p2m_ioreq_server entries back to
> p2m_ram_rw.
> + */
> +if ( rc == 0 && data->flags == 0 )
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +while ( read_atomic(>ioreq.entry_count) &&
> +first_gfn <= p2m->max_mapped_pfn )
> +{
> +/* Iterate p2m table for 256 gfns each time. */
> +p2m_finish_type_change(d, _gfn(first_gfn), 256,
> +   p2m_ioreq_server,
> p2m_ram_rw);
> +
> +first_gfn += 256;
> +
> +/* Check for continuation if it's not the last iteration. */
> +if ( first_gfn <= p2m->max_mapped_pfn &&
> + hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +data->opaque = first_gfn;
> +break;
> +}
> +}
> +}
> +
>  break;
>  }
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 4169d18..1d57e5c 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1011,6 +1011,35 @@ void p2m_change_type_range(struct domain *d,
>  p2m_unlock(p2m);
>  }
> 
> +/* Synchronously modify the p2m type for a range of gfns from ot to nt. */
> +void p2m_finish_type_change(struct domain *d,
> +gfn_t first_gfn, unsigned long max_nr,
> +p2m_type_t ot, p2m_type_t nt)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +p2m_type_t t;
> +unsigned long gfn = gfn_x(first_gfn);
> +unsigned long last_gfn = gfn + max_nr - 1;
> +
> +ASSERT(ot != nt);
> +ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
> +
> +p2m_lock(p2m);
> +
> +last_gfn = min(last_gfn, p2m->max_mapped_pfn);
> +while ( gfn <= last_gfn )
> +{
> +get_gfn_query_unlocked(d, gfn, );
[Zhang, Xiong Y] As the previous patch "asynchronously reset outstanding 
p2m_ioreq_server_entries" call ept_chang_entry_type_global() which
set ept_entry.recalc=1 and ept_entry.emt=MTRR_NUM_TYPES. So 
get_gfn_query_unlocked(gfn) will recalc gfn mem_type and return
the new mem_type not the old mem_type.
For pfn is old p2m_ioreq_server mem_type, the returned  is p2m_raw_rw.
Then (t == ot) couldn't be true, and p2m_change_type_one() never be called.

This result a guest vm using this interface couldn't reboot.

thanks
> +
> +if ( t == ot )
> +p2m_change_type_one(d, gfn, t, nt);
> +
> +gfn++;
> +}
> +
> +p2m_unlock(p2m);
> +}
> +
>  /*
>   * Returns:
>   *0  for success
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index e7e390d..0e670af 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -611,6 +611,12 @@ void p2m_change_type_range(struct domain *d,
>  int p2m_change_type_one(struct domain *d, unsigned long gfn,
>  p2m_type_t ot, p2m_type_t nt);
> 
> +/* Synchronously change the p2m type for a range of gfns */
> +void p2m_finish_type_change(struct domain *d,
> +gfn_t first_gfn,
> +unsigned long max_nr,
> +p2m_type_t ot, p2m_type_t nt);
> +
>  /* Report a change affecting memory types. */
>  void p2m_memory_type_changed(struct domain *d);
> 
> --
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

>>> On 28.04.17 at 08:52,  wrote:
> btw regardless of clarification which I'm trying to get, I think we do
> need disallow such guest operation going to physical MSR. It's not
> good to have guest impact physical PMU interrupt behavior. Even
> when we want to support guest PC operation in the future, it needs
> be emulated as the comment given in KVM side. If others also 
> agree with this assumption, we could check-in this patch w/o
> mentioning any possible erratum...

Good point - it would nevertheless require an adjustment to the
patch description, though, along the lines of the above.

Jan


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

Re: [Xen-devel] [PATCH] x86/vm_event: fix race between vmx_vmexit_handler() and vm_event_resume()

>>> On 28.04.17 at 08:45,  wrote:
> On 04/28/2017 09:25 AM, Jan Beulich wrote:
> On 27.04.17 at 19:31,  wrote:
>>> On 27/04/17 09:52, Jan Beulich wrote:
>>> On 27.04.17 at 10:34,  wrote:
> On 27/04/2017 09:01, Jan Beulich wrote:
> On 27.04.17 at 09:22,  wrote:
>>> --- a/xen/common/vm_event.c
>>> +++ b/xen/common/vm_event.c
>>> @@ -357,6 +357,13 @@ void vm_event_resume(struct domain *d, struct 
> vm_event_domain *ved)
>>>  {
>>>  vm_event_response_t rsp;
>>>  
>>> +/*
>>> + * vm_event_resume() runs either from XEN_DOMCTL_VM_EVENT_OP_*, or
>>> + * EVTCHN_send from the introspection consumer.  Both contexts are
>>> + * guaranteed not to be the subject of vm_event responses.
>>> + */
>>> +ASSERT(d != current->domain);
>> What is this meant to guard against?
> Documentation, as much as anything else.  It took a long time to
> untangle the contexts involved here; I'm not convinced the logic is safe
> to run in context, and it certainly doesn't need to.
 Well, as said - I think it is too strict now: You only need the vCPU
 not be current afaict, and it really matters here which of the two
 "current"-s you actually mean (and it looks to me as if you mean
 the other one, guaranteeing register state to no longer be on the
 stack).
>>>
>>> We don't know the vcpu at this point; that information comes out of the
>>> replies on the ring.
>>>
>>> We also may process multiple replies in this one loop.  In the worse
>>> case, we process one reply for every vcpu in d.
>>>
>>> If the ASSERT() were to be deferred until the middle of the request
>>> loop, we could ASSERT(v != current) for every vcpu in d, but that is
>>> identical to this single assertion.
>> 
>> No, it isn't. It would only be if you iterated over all vCPU-s of that
>> domain (which as you say may or may not happen).
> 
> I will modify to the code to whatever you and Andrew decide is best, but
> just in case this helps decide, in my experience iterating over all
> VCPUs here will happen more often than not - even looking at
> xen-access.c today, it poll()s with a timeout, processes all collected
> events (which, if they are sync events - and they always are with our
> application - there can be several of them only if they correspond to
> different VCPUs), and only then signals the event channel.
> 
> But there are of course cases in which less than all the VCPUs have
> placed events in the ring buffer.

So just to clarify - I'm not entirely opposed to the ASSERT() staying
as is, but then the comment next to it should clarify that it is slightly
more strict than absolutely necessary.

Jan


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

Re: [Xen-devel] compile error in x86_emulate/x86_emulate.c

>>> On 28.04.17 at 08:33,  wrote:
> A compile error was introduced between 4.9.20170413T172409.e412c03be2
> and 4.9.20170426T155707.0a5370ee1f when gcc-4.3/4.5 is used:

See https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg03240.html

Jan


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

Re: [Xen-devel] [xen-unstable test] 107791: regressions - FAIL

>>> On 28.04.17 at 03:19,  wrote:
> flight 107791 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/107791/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. 
> vs. 107676

This may be indicative of a bug, I'm afraid:

(XEN) d0v4 Error pfn 804a8c: rd=32755 od=32756 caf= taf=
(XEN) d0v4 Error pfn 804a8c: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a8b: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a8b: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a8a: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a8a: rd=32755 od=32756 caf=180 
taf=0001
...
(XEN) d0v4 Error pfn 804a31: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a31: rd=32755 od=32756 caf=180 
taf=0001
(XEN) d0v4 Error pfn 804a30: rd=32755 od=32756 c(XEN) HVM12 save: CPU

rd is DOMID_COW and od is DOMID_INVALID (the latter indicating
an unowned page). I don't suppose there is any memory sharing
being set up for any tests in osstest, so I'm pretty confused. While
there is a respective get_page() in get_page_from_gfn_p2m(),
which  surely looks like it shouldn't trigger any log message, from
what I can tell this isn't the path we get here, or else an unowned
page would also trigger the same warning for the immediately
preceding get_page(page, d). Or wait, no, the warning is being
suppressed for paging_mode_refcounts() and dying domains, so
quite likely it is that path.

Therefore one possible code adjustment might be to do this
second get_page() only when p2m_is_shared(*t). We hold the
p2m lock, so the type is stable between when it was retrieved
and its possible use here. George, Tamas?

It also looks as if it should tell me something that the first page
on the first attempt has count_info and type_info zero, yet the
second attempt as well as all succeeding pages are
PGC_state_free (in which case type_info is meaningless and
rather indicates that the need_tlbflush flag is set). But for now
it doesn't; best I can think of is a race of domain cleanup with
something else still accessing the domain.

Does anyone else have any thoughts here?

Jan

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

[Xen-devel] [seabios test] 107858: regressions - FAIL