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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
baseline version:
 ovmf 7eb3bb6c552d59b28f07ce5787049b53da76d5cf

Last test of basis   100838  2016-09-09 06:38:37 Z1 days
Testing same since   100860  2016-09-09 22:15:25 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 
  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=acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
+ . ./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 
acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
+ branch=ovmf
+ revision=acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
+ . ./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.7-testing
+ '[' xacc3a3776dc3fb3dc900819b1ee94a6d4f9cf759 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/lin

[Xen-devel] [xen-4.6-testing baseline-only test] 67684: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

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

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

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

version targeted for testing:
 xen  26352b6344ce5d5a2ee78e56ae631e156fbdce7f
baseline version:
 xen  4627e5e5f10bf8cdebaf45b66a476c4adb104f6d

Last test of basis67667  2016-09-07 15:46:29 Z2 days
Testing same since67684  2016-09-09 21:16:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvop

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7eb3bb6c552d59b28f07ce5787049b53da76d5cf
baseline version:
 ovmf 27733778fc6a855e0dfde2071f011f3d7b394867

Last test of basis67681  2016-09-09 06:50:22 Z0 days
Testing same since67685  2016-09-09 21:46:28 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Ard Biesheuvel 
  Laszlo Ersek 

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 7eb3bb6c552d59b28f07ce5787049b53da76d5cf
Author: Laszlo Ersek 
Date:   Thu Sep 8 16:57:02 2016 +0200

ShellPkg/UefiHandleParsingLib: fix retval for empty child controller array

The ParseHandleDatabaseForChildControllers() function intends to work like
this:

(1) It allocates a "HandleBufferForReturn" local array that's guaranteed
to be big enough for all found handles,

(2) it collects the handles, both counting them in the (mandatory)
"MatchingHandleCount" output parameter, and saving them in the local
"HandleBufferForReturn" array,

(3) if the caller is not interested in the actual handles, then
"HandleBufferForReturn" is released,

(4) if the caller is interested in the handles, and we've found some, then
"HandleBufferForReturn" is passed out through the
"MatchingHandleBuffer" output parameter,

(5) if the caller is interested in the actual handles, but we've found
none, then the "MatchingHandleBuffer" output parameter is set to NULL.

The ASSERT() at the end of the function makes this clear, but the
implementation does not conform to (5). Fix it.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Tapan Shah 
Reported-by: Tapan Shah 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=112
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jaben Carsey 
Reviewed-by: Tapan Shah 

commit b6c54204617c37e305c4389ece4f7af116485f92
Author: Laszlo Ersek 
Date:   Thu Sep 8 17:10:47 2016 +0200

ShellPkg/UefiHandleParsingLib: fix IN/OUT notation in child ctrlr parsing

"MatchingHandleCount" is an output parameter of
ParseHandleDatabaseForChildControllers().

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Tapan Shah 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jaben Carsey 
Reviewed-by: Tapan Shah 

commit 1b3be4a12e7dd7504b502fb58929efec967b7fbf
Author: Abdul Lateef Attar 
Date:   Fri Sep 9 23:31:35 2016 -0700

ShellPkg: pci -i -_e to print next capability

According to PCI spec the next AER capability is relative to
the beginning of PCI configuration space. Hence substract the
base offset to get the next capability.

"-_e" option is changed from TypeFlag to TypeValue, so that
user can specify individual AER capability to print.
e.g. pci 00 00 01 -i -_e 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Abdul Lateef Attar 
Reviewed-by: Jaben Carsey 

commit e51a677dea1b4ec3536e32b590b165dbcd30a87d
Author: Ard Biesheuvel 
Date:   Mon Sep 5 15:12:01 2016 +0100

ArmPkg/ArmBaseLib: clean up directory structure

For historical reasons, the files under ArmLib are split up into 'common'
files under Common/, containing common C files as well as AArch64 and Arm
specific asm files, and ArmV7 and AArch64 files under ArmV7/ and AArch64/,
respectively. This presumably dates back to the time when ArmLib supported
different revisions of the 3

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot fail REGR. vs. 100825
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail REGR. vs. 100825
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
100825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100825
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100825
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100825

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

version targeted for testing:
 qemuu33e60e01988b02ac9baf4dc0f4a452b39fb5ce55
baseline version:
 qemuu59351d9b40b1de0fb77e1ff3e53faa04c995c707

Last test of basis   100825  2016-09-08 18:47:59 Z1 days
Testing same since   100845  2016-09-09 11:31:21 Z0 days1 attempts


People who touched revisions under test:
  Marc-André Lureau 
  Marcel Apfelbaum 
  Peter Maydell 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100773
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100773
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100773
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100773
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100773

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

version targeted for testing:
 xen  26ea2cce0d3d25974eea3c643ce2081adfa2a69c
baseline version:
 xen  343f84be135e6f9e681960a9e235296eae159fc8

Last test of basis   100773  2016-09-06 13:13:28 Z3 days
Failing since100789  2016-09-07 09:36:36 Z2 days4 attempts
Testing same since   100844  2016-09-09 10:50:44 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Olaf Hering 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
baseline version:
 xen  8a085e9d947609b4baf3ed57007a3aab481f0155

Last test of basis   100855  2016-09-09 18:02:41 Z0 days
Testing same since   100862  2016-09-10 00:01:51 Z0 days1 attempts


People who touched revisions under test:
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
+ . ./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 
a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
+ branch=xen-unstable-smoke
+ revision=a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
+ . ./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.7-testing
+ '[' xa3fe74e4345e66ddb7aa514395260a5e5f8b0cdc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.gi

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

[Stefano Stabellini]

On Fri, 9 Sep 2016, Tamas Lengyel wrote:
> On Fri, Sep 9, 2016 at 5:11 PM, Stefano Stabellini
>  wrote:
> > On Fri, 9 Sep 2016, Tamas K Lengyel wrote:
> >> When emulating instructions the emulator maintains a small i-cache fetched
> >> from the guest memory. Under certain scenarios this memory region may 
> >> contain
> >> instructions that a monitor subscriber would prefer to hide, namely INT3, 
> >> and
> >> instead would prefer to emulate a different instruction in-place.
> >>
> >> This patch extends the vm_event interface to allow returning this i-cache 
> >> via
> >> the vm_event response.
> >>
> >> Signed-off-by: Tamas K Lengyel 
> >>
> >> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> >> index 8398af7..161d149 100644
> >> --- a/xen/common/vm_event.c
> >> +++ b/xen/common/vm_event.c
> >> @@ -407,8 +407,11 @@ void vm_event_resume(struct domain *d, struct 
> >> vm_event_domain *ved)
> >>  vm_event_register_write_resume(v, &rsp);
> >>  break;
> >>
> >> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
> >> +vm_event_interrupt_emulate_check(v, &rsp);
> >> +break;
> >> +
> >>  #ifdef CONFIG_HAS_MEM_ACCESS
> >> -case VM_EVENT_REASON_MEM_ACCESS:
> >>  mem_access_resume(v, &rsp);
> >>  break;
> >>  #endif
> >> diff --git a/xen/include/asm-arm/vm_event.h 
> >> b/xen/include/asm-arm/vm_event.h
> >> index ccc4b60..e56bc78 100644
> >> --- a/xen/include/asm-arm/vm_event.h
> >> +++ b/xen/include/asm-arm/vm_event.h
> >> @@ -40,6 +40,12 @@ static inline void vm_event_toggle_singlestep(struct 
> >> domain *d, struct vcpu *v)
> >>  }
> >>
> >>  static inline
> >> +void vm_event_interrupt_emulate_check(struct vcpu *v, vm_event_response_t 
> >> *rsp)
> >> +{
> >> +/* Not supported on ARM. */
> >> +}
> >> +
> >> +static inline
> >>  void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t 
> >> *rsp)
> >>  {
> >>  /* Not supported on ARM. */
> >
> > Doesn't it make sense to return some sort of error?
> 
> Not really, there is no path for that error to reach the user who
> triggered this via the vm_event response. Usually if there is an error
> in the operation specified by the response flag we just print a
> message to the Xen console. But since these ops are not supported on
> ARM at all - there is no emulator - it would be kind-of be redundant.

All right then

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

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

[Tamas Lengyel]

On Fri, Sep 9, 2016 at 5:11 PM, Stefano Stabellini
 wrote:
> On Fri, 9 Sep 2016, Tamas K Lengyel wrote:
>> When emulating instructions the emulator maintains a small i-cache fetched
>> from the guest memory. Under certain scenarios this memory region may contain
>> instructions that a monitor subscriber would prefer to hide, namely INT3, and
>> instead would prefer to emulate a different instruction in-place.
>>
>> This patch extends the vm_event interface to allow returning this i-cache via
>> the vm_event response.
>>
>> Signed-off-by: Tamas K Lengyel 
>>
>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> index 8398af7..161d149 100644
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -407,8 +407,11 @@ void vm_event_resume(struct domain *d, struct 
>> vm_event_domain *ved)
>>  vm_event_register_write_resume(v, &rsp);
>>  break;
>>
>> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
>> +vm_event_interrupt_emulate_check(v, &rsp);
>> +break;
>> +
>>  #ifdef CONFIG_HAS_MEM_ACCESS
>> -case VM_EVENT_REASON_MEM_ACCESS:
>>  mem_access_resume(v, &rsp);
>>  break;
>>  #endif
>> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
>> index ccc4b60..e56bc78 100644
>> --- a/xen/include/asm-arm/vm_event.h
>> +++ b/xen/include/asm-arm/vm_event.h
>> @@ -40,6 +40,12 @@ static inline void vm_event_toggle_singlestep(struct 
>> domain *d, struct vcpu *v)
>>  }
>>
>>  static inline
>> +void vm_event_interrupt_emulate_check(struct vcpu *v, vm_event_response_t 
>> *rsp)
>> +{
>> +/* Not supported on ARM. */
>> +}
>> +
>> +static inline
>>  void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t 
>> *rsp)
>>  {
>>  /* Not supported on ARM. */
>
> Doesn't it make sense to return some sort of error?

Not really, there is no path for that error to reach the user who
triggered this via the vm_event response. Usually if there is an error
in the operation specified by the response flag we just print a
message to the Xen console. But since these ops are not supported on
ARM at all - there is no emulator - it would be kind-of be redundant.

Tamas

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

Re: [Xen-devel] [RFC 18/22] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

[Stefano Stabellini]

On Wed, 7 Sep 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/09/2016 19:51, Stefano Stabellini wrote:
> > On Tue, 6 Sep 2016, Julien Grall wrote:
> > > > I was asking myself the same question
> > > 
> > > It is not trivial. On ARMv7, there is no way to invalidate by IPA, so we
> > > still
> > > need to do a full flush.
> > > 
> > > In the case of ARMv8, it is possible to do a flush by IPA with the
> > > following
> > > sequence (see D4-1739 in ARM DDI 0487A.i):
> > >  tlbi ipa2e1, xt
> > >  dsb
> > >  tlbi vmalle1
> > > 
> > > So I was wondering if we could leave that for a future optimization.
> > 
> > We can leave it for now but I have an hunch that it is going to have a
> > pretty significant impact.
> 
> In theory, the current approach will have an impact on platform where the TLBs
> are caching separately stage-1 and stage-2 translation.
> 
> This will not be the case if the TLBs are caching stage-1 and stage-2 in a
> single entry.
> 
> However, on ARMv7 it will not be possible to minimize the impact.
> 
> But to be honest, most of the time, the p2m will be modified via
> guest_physmap_add_entry and guest_physmap_remove_page. Both are often called
> with order = 0 or order = 6 (for domain use 64KB page granularity).
> 
> Taken aside domains using 64KB page granularity, the number of TLB flushs will
> be either 1 or 2 depending whether you need to shatter a superpage. Which is
> the same as today.
> 
> In the case of 64KB domain, the number of TLB flush will be higher if the
> domain is replacing existing mapping (1 TLB flush per 4KB-entry).
> But this is already a programming issue given that in this case the underlying
> memory (if RAM) will not be freed until the domain is destroyed. In general a
> domain should remove a mapping before creating a new one at the same address.
> 
> I have done some testing and noticed that DOMU p2m will not be often modified.
> In the case of DOM0, this will mostly happen when a domain is created (you
> have to map the new domain memory). Although, the number of flushes should be
> the same given dom0 will use balloon page (i.e the stage-2 mapping does not
> exist).
> 
> I have some ideas on how to optimize a bit more the code, but they are heavy
> and will be hard to maintain. I would prefer to defer it until user come with
> use case where the performance hit is too much.

All right.


> > > > > +if ( !(mask & ((1UL << FIRST_ORDER) - 1)) )
> > > > > +order = FIRST_ORDER;
> > > > > +else if ( !(mask & ((1UL << SECOND_ORDER) - 1)) )
> > > > > +order = SECOND_ORDER;
> > > > > +else
> > > > > +order = THIRD_ORDER;
> > > > > +
> > > > > +rc = __p2m_set_entry(p2m, sgfn, order, smfn, t, a);
> > > > > +if ( rc )
> > > > > +break;
> > > > 
> > > > Shouldn't we be checking that "(1< > > > calling __p2m_set_entry? Otherwise we risk creating a mapping bigger
> > > > than requested.
> > > 
> > > The mask is defined as gfn_x(sgfn) | mfn_x(smfn) | todo
> > > 
> > > So we will never have the order exceeding "todo".
> > 
> > Ah, I see. But this way we are not able to do superpage mappings for
> > regions larger than 2MB but not multiple of 2MB (3MB for example). But I
> > don't think we were able to do it before either so it is not a
> > requirement for the patch.
> 
> From my understanding of is_mapping_aligned, the case you mentioned is
> handled.
> 
> The function p2m_set_entry is using the number of page because some caller
> (such as MMIO ones) are passing a number of page. However, the main callers
> are guest_physmap_remove_page and guest_physmap_add_entry. They take an order
> in parameter.
> 
> So it would be a nice feature to have, but I don't think this is strictly
> necessary.
 
I think it shouldn't take much to implement it, but it's up to you.

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

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

[Stefano Stabellini]

On Fri, 9 Sep 2016, Tamas K Lengyel wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. Under certain scenarios this memory region may contain
> instructions that a monitor subscriber would prefer to hide, namely INT3, and
> instead would prefer to emulate a different instruction in-place.
> 
> This patch extends the vm_event interface to allow returning this i-cache via
> the vm_event response.
> 
> Signed-off-by: Tamas K Lengyel 
>
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 8398af7..161d149 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -407,8 +407,11 @@ void vm_event_resume(struct domain *d, struct 
> vm_event_domain *ved)
>  vm_event_register_write_resume(v, &rsp);
>  break;
>  
> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
> +vm_event_interrupt_emulate_check(v, &rsp);
> +break;
> +
>  #ifdef CONFIG_HAS_MEM_ACCESS
> -case VM_EVENT_REASON_MEM_ACCESS:
>  mem_access_resume(v, &rsp);
>  break;
>  #endif
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index ccc4b60..e56bc78 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -40,6 +40,12 @@ static inline void vm_event_toggle_singlestep(struct 
> domain *d, struct vcpu *v)
>  }
>  
>  static inline
> +void vm_event_interrupt_emulate_check(struct vcpu *v, vm_event_response_t 
> *rsp)
> +{
> +/* Not supported on ARM. */
> +}
> +
> +static inline
>  void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
>  {
>  /* Not supported on ARM. */

Doesn't it make sense to return some sort of error?

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

[Xen-devel] [xen-4.5-testing baseline-only test] 67683: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 67663
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 67663
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67663
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 67663
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 67663
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10fail like 67663
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67663

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

version targeted for testing:
 xen  433ebca120e8750eb8085745ccac703e47358e6f
baseline version:
 xen  d50078b9f2d7df55157ca353d889b13a8f3f0bc6

Last test of basis67663  2016-09-06 22:19:08 Z2 days
Testing same since67683  2016-09-09 14:16:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-a

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7eb3bb6c552d59b28f07ce5787049b53da76d5cf
baseline version:
 ovmf 27733778fc6a855e0dfde2071f011f3d7b394867

Last test of basis   100821  2016-09-08 15:47:10 Z1 days
Testing same since   100838  2016-09-09 06:38:37 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Ard Biesheuvel 
  Laszlo Ersek 

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=7eb3bb6c552d59b28f07ce5787049b53da76d5cf
+ . ./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 
7eb3bb6c552d59b28f07ce5787049b53da76d5cf
+ branch=ovmf
+ revision=7eb3bb6c552d59b28f07ce5787049b53da76d5cf
+ . ./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.7-testing
+ '[' x7eb3bb6c552d59b28f07ce5787049b53da76d5cf = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : teste

[Xen-devel] [xen-4.6-testing test] 100835: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

flight 100835 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100835/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   3 host-install(3)  broken pass in 100816
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
100816 pass in 100835
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
in 100816 pass in 100835
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 100816

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100771
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100779
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100779
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100779
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100779

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

version targeted for testing:
 xen  26352b6344ce5d5a2ee78e56ae631e156fbdce7f
baseline version:
 xen  4627e5e5f10bf8cdebaf45b66a476c4adb104f6d

Last test of basis   100779  2016-09-07 02:17:59 Z2 days
Testing same since   100816  2016-09-08 12:44:48 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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

[Xen-devel] Outreachy Round 13

[Akanksha Srivastava]

This is to introduce myself to the Xen community.
My name is Akanksha and I would like to participate in the upcoming
outreachy round.
I went through this page [1] and found the available project on "Add Centos
Virt SIG Xen packages test to the CentOS CI loop".
I have a strong C foundation and I know shell scripting pretty well.
And I wish to start contributing to the orgainisation as soon as possible
for which I require some guidance.
Thanks
Akanksha

[1]
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Outreach_Program_Project_Ideas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 100802

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

version targeted for testing:
 libvirt  66278d4bc38aecff6661c91ce9cd3fff26e54a91
baseline version:
 libvirt  fe94ee5db5461970743f52a85fc295af023f50bf

Last test of basis   100802  2016-09-08 04:20:09 Z1 days
Testing same since   100837  2016-09-09 04:32:42 Z0 days1 attempts


People who touched revisions under test:
  Christophe Fergeau 
  Erik Skultety 
  Jiri Denemark 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Not pushing.


commit 66278d4bc38aecff6661c91ce9cd3fff26e54a91
Author: Jiri Denemark 
Date:   Thu Sep 8 15:22:28 2016 +0200

qemu: Remove stale transient def when migration fails

If a migration of a domain which is already defined on the destination
host failed early (before we tried to start QEMU), we would forget to
remove the incoming transient definition. Later on when someone starts
the domain on the destination host, we will use the stale incoming
definition and the persistent definition will just be ignored.

https://bugzilla.redhat.com/show_bug.cgi?id=1368774

Signed-off-by: Jiri Denemark 

commit 97a87333a0ac8b6b33bf4c45a7b1a526caa554cb
Author: Jiri Denema

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8a085e9d947609b4baf3ed57007a3aab481f0155
baseline version:
 xen  4c47c47938ea24c73d9459f9f0b6923513772b5d

Last test of basis   100852  2016-09-09 15:01:52 Z0 days
Testing same since   100855  2016-09-09 18:02:41 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Jan Beulich  [x86 part]
  Julien Grall 
  Konrad Rzeszutek Wilk 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=8a085e9d947609b4baf3ed57007a3aab481f0155
+ . ./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 
8a085e9d947609b4baf3ed57007a3aab481f0155
+ branch=xen-unstable-smoke
+ revision=8a085e9d947609b4baf3ed57007a3aab481f0155
+ . ./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.7-testing
+ '[' x8a085e9d947609b4baf3ed57007a3aab481f0155 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/

Re: [Xen-devel] [PATCH 01/17] x86emul: split instruction decoding from execution

[Andrew Cooper]

On 08/09/16 14:04, Jan Beulich wrote:
> This is only the mechanical part, a subsequent patch will make non-
> mechanical adjustments to actually do all decoding in this new
> function.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -48,7 +48,9 @@
>  /* All operands are implicit in the opcode. */
>  #define ImplicitOps (DstImplicit|SrcImplicit)
>  
> -static uint8_t opcode_table[256] = {
> +typedef uint8_t opcode_desc_t;
> +
> +static const opcode_desc_t opcode_table[256] = {
>  /* 0x00 - 0x07 */
>  ByteOp|DstMem|SrcReg|ModRM, DstMem|SrcReg|ModRM,
>  ByteOp|DstReg|SrcMem|ModRM, DstReg|SrcMem|ModRM,
> @@ -178,7 +180,7 @@ static uint8_t opcode_table[256] = {
>  ImplicitOps, ImplicitOps, ByteOp|DstMem|SrcNone|ModRM, 
> DstMem|SrcNone|ModRM
>  };
>  
> -static uint8_t twobyte_table[256] = {
> +static const opcode_desc_t twobyte_table[256] = {
>  /* 0x00 - 0x07 */
>  SrcMem16|ModRM, ImplicitOps|ModRM, 0, 0, 0, ImplicitOps, ImplicitOps, 0,
>  /* 0x08 - 0x0F */
> @@ -607,7 +609,7 @@ do{ asm volatile (
>  })
>  #define truncate_ea(ea) truncate_word((ea), ad_bytes)
>  
> -#define mode_64bit() (def_ad_bytes == 8)
> +#define mode_64bit() (ctxt->addr_size == 64)
>  
>  #define fail_if(p)  \
>  do {\
> @@ -1558,32 +1560,63 @@ int x86emul_unhandleable_rw(
>  return X86EMUL_UNHANDLEABLE;
>  }
>  
> -int
> -x86_emulate(
> -struct x86_emulate_ctxt *ctxt,
> -const struct x86_emulate_ops  *ops)
> -{
> -/* Shadow copy of register state. Committed on successful emulation. */
> -struct cpu_user_regs _regs = *ctxt->regs;
> +struct x86_emulate_state {
> +unsigned int op_bytes, ad_bytes;
> +
> +enum { ext_none, ext_0f, ext_0f38 } ext;
> +uint8_t opcode;
> +uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
> +uint8_t rex_prefix;
> +bool lock_prefix;
> +opcode_desc_t desc;
> +union vex vex;
> +int override_seg;
>  
> -uint8_t b, d, sib, sib_index, sib_base, rex_prefix = 0;
> -uint8_t modrm = 0, modrm_mod = 0, modrm_reg = 0, modrm_rm = 0;
> -enum { ext_none, ext_0f, ext_0f38 } ext = ext_none;
> -union vex vex = {};
> -unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
> -bool_t lock_prefix = 0;
> -int override_seg = -1, rc = X86EMUL_OKAY;
> -struct operand src = { .reg = REG_POISON };
> -struct operand dst = { .reg = REG_POISON };
> -enum x86_swint_type swint_type;
> -struct x86_emulate_stub stub = {};
> -DECLARE_ALIGNED(mmval_t, mmval);
>  /*
>   * Data operand effective address (usually computed from ModRM).
>   * Default is a memory operand relative to segment DS.
>   */
> -struct operand ea = { .type = OP_MEM, .reg = REG_POISON };
> -ea.mem.seg = x86_seg_ds; /* gcc may reject anon union initializer */
> +struct operand ea;
> +
> +/* Immediate operand values, if any. Use otherwise unused fields. */
> +#define imm1 ea.val
> +#define imm2 ea.orig_val

Some instructions (e.g. bextr) have both immediate and memory operands. 
Reusing ea like this is unsafe.

Immediate data was previously stashed in src, separately from ea.  In
the light of the XSA-123 problems, I think it would be better to just
have "uint64_t imm1, imm2;" here.

> +
> +/* Shadow copy of register state. Committed on successful emulation. */
> +struct cpu_user_regs regs;
> +};
> +
> +/* Helper definitions. */
> +#define op_bytes (state->op_bytes)
> +#define ad_bytes (state->ad_bytes)
> +#define ext (state->ext)
> +#define modrm (state->modrm)
> +#define modrm_mod (state->modrm_mod)
> +#define modrm_reg (state->modrm_reg)
> +#define modrm_rm (state->modrm_rm)
> +#define rex_prefix (state->rex_prefix)
> +#define lock_prefix (state->lock_prefix)
> +#define vex (state->vex)
> +#define override_seg (state->override_seg)
> +#define ea (state->ea)
> +#define _regs (state->regs)
> +
> +static int
> +x86_decode(
> +struct x86_emulate_state *state,
> +struct x86_emulate_ctxt *ctxt,
> +const struct x86_emulate_ops  *ops)
> +{
> +uint8_t b, d, sib, sib_index, sib_base;
> +unsigned int def_op_bytes, def_ad_bytes;
> +int rc = X86EMUL_OKAY;
> +
> +memset(state, 0, sizeof(*state));
> +override_seg = -1;
> +ea.type = OP_MEM;
> +ea.mem.seg = x86_seg_ds;
> +ea.reg = REG_POISON;
> +_regs = *ctxt->regs;

The helper definitions are fine for the transition period, but I would
like to see them eventually removed to help reduce the quantity of
information hiding in this area.  Please don't introduce new uses.

>  
>  ctxt->retire.byte = 0;
>  
> @@ -1800,7 +1833,7 @@ x86_emulate(
>  d = (d & ~(DstMask | SrcMask)) | DstMem | SrcReg | Mov;
>  break;
>  default: /* Until it is worth making this table based ... */
> -goto cannot_emulate;
>

[Xen-devel] [qemu-mainline baseline-only test] 67682: trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67682 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67682/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  3 host-install(3)   broken REGR. vs. 67676

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67676
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67676
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67676

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

version targeted for testing:
 qemuu59351d9b40b1de0fb77e1ff3e53faa04c995c707
baseline version:
 qemuu7faae0b36e51ffdb17d4716ddc40dcfa682d93d9

Last test of basis67676  2016-09-08 18:46:25 Z0 days
Testing same since67682  2016-09-09 11:43:56 Z0 days1 attempts


People who touched revisions under test:
  Aneesh Kumar K.V 
  Benjamin Herrenschmidt 
  Cédric Le Goater 
  David Gibson 
  Greg Kurz 
  Laurent Vivier 
  Nikunj A Dadhania 
  Peter Maydell 
  Sandipan Das 
  Swapnil Bokade 
  Thomas Huth 
  Vivek Andrew Sha 

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

Re: [Xen-devel] [PATCH v3 16/38] arm/p2m: Add HVMOP_altp2m_set_domain_state

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

+static int altp2m_init_helper(struct domain *d, unsigned int idx)
+{
+int rc;
+struct p2m_domain *p2m = d->arch.altp2m_p2m[idx];
+
+ASSERT(p2m == NULL);
+
+/* Allocate a new, zeroed altp2m view. */
+p2m = xzalloc(struct p2m_domain);
+if ( p2m == NULL)
+{
+rc = -ENOMEM;
+goto err;
+}


This could be simplified with just return -ENOMEM.


+
+p2m->p2m_class = p2m_alternate;
+
+/* Initialize the new altp2m view. */
+rc = p2m_init_one(d, p2m);
+if ( rc )
+goto err;
+
+p2m->access_required = false;
+_atomic_set(&p2m->active_vcpus, 0);


the p2m is initialized to 0, so both access_required and active_vcpus 
initialization is not necessary.



+
+d->arch.altp2m_p2m[idx] = p2m;
+
+return rc;
+
+err:
+if ( p2m )
+xfree(p2m);


xfree is able to handle NULL pointer.


+
+d->arch.altp2m_p2m[idx] = NULL;
+
+return rc;
+}
+
+int altp2m_init_by_id(struct domain *d, unsigned int idx)
+{
+int rc = -EINVAL;
+
+if ( idx >= MAX_ALTP2M )
+return rc;
+
+altp2m_lock(d);
+
+if ( d->arch.altp2m_p2m[idx] == NULL )
+rc = altp2m_init_helper(d, idx);
+
+altp2m_unlock(d);
+
+return rc;
+}
+


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 15/38] arm/p2m: Add altp2m table flushing routine

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

The current implementation differentiates between flushing and
destroying altp2m views. This commit adds the function altp2m_flush,
which allows to release all of the alternate p2m views.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Pages in p2m->pages are not cleared in p2m_flush_table anymore.
VMID is freed in p2m_free_one.
Cosmetic fixes.

v3: Changed the locking mechanism to "p2m_write_lock" inside the
function "altp2m_flush".

Do not flush but rather teardown the altp2m in the function
"altp2m_flush".

Exchanged the check "altp2m_vttbr[idx] == INVALID_VTTBR" for
"altp2m_p2m[idx] == NULL" in "altp2m_flush".
---
 xen/arch/arm/altp2m.c| 31 +++
 xen/include/asm-arm/altp2m.h |  3 +++
 2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
index 66a373a..02cffd7 100644
--- a/xen/arch/arm/altp2m.c
+++ b/xen/arch/arm/altp2m.c
@@ -34,6 +34,37 @@ int altp2m_init(struct domain *d)
 return 0;
 }

+void altp2m_flush(struct domain *d)
+{
+unsigned int i;
+struct p2m_domain *p2m;
+
+/*
+ * If altp2m is active, we are not allowed to flush altp2m[0]. This special
+ * view is considered as the hostp2m as long as altp2m is active.
+ */
+ASSERT(!altp2m_active(d));
+
+altp2m_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_p2m[i] == NULL )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+
+p2m_write_lock(p2m);


Why do you take the lock here? The p2m should not be used by anyone at 
that time.



+p2m_teardown_one(p2m);


You may want to add an ASSERT(!atomic_read(p2m->active_vcpus)) somewhere.


+p2m_write_unlock(p2m);
+
+xfree(p2m);
+d->arch.altp2m_p2m[i] = NULL;
+}
+
+altp2m_unlock(d);
+}
+
 void altp2m_teardown(struct domain *d)
 {
 unsigned int i;
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index a156109..4c15b75 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -42,4 +42,7 @@ static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)
 int altp2m_init(struct domain *d);
 void altp2m_teardown(struct domain *d);

+/* Flush all the alternate p2m's for a domain. */
+void altp2m_flush(struct domain *d);
+
 #endif /* __ASM_ARM_ALTP2M_H */



Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  4c47c47938ea24c73d9459f9f0b6923513772b5d
baseline version:
 xen  26ea2cce0d3d25974eea3c643ce2081adfa2a69c

Last test of basis   100840  2016-09-09 08:02:30 Z0 days
Testing same since   100852  2016-09-09 15:01:52 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=4c47c47938ea24c73d9459f9f0b6923513772b5d
+ . ./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 
4c47c47938ea24c73d9459f9f0b6923513772b5d
+ branch=xen-unstable-smoke
+ revision=4c47c47938ea24c73d9459f9f0b6923513772b5d
+ . ./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.7-testing
+ '[' x4c47c47938ea24c73d9459f9f0b6923513772b5d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.gi

Re: [Xen-devel] [PATCH v3 14/38] arm/p2m: Add altp2m init/teardown routines

[Julien Grall]

Hello Sergej

On 16/08/16 23:16, Sergej Proskurin wrote:

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 23aaf52..4a7f660 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -5,6 +5,7 @@ subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi

 obj-$(CONFIG_ALTERNATIVE) += alternative.o
+obj-y += altp2m.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpuerrata.o
diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
new file mode 100644
index 000..66a373a
--- /dev/null
+++ b/xen/arch/arm/altp2m.c
@@ -0,0 +1,61 @@
+/*
+ * arch/arm/altp2m.c
+ *
+ * Alternate p2m
+ * Copyright (c) 2016 Sergej Proskurin 
+ *
+ * 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 
+
+int altp2m_init(struct domain *d)
+{
+unsigned int i;
+
+spin_lock_init(&d->arch.altp2m_lock);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+d->arch.altp2m_p2m[i] = NULL;


The structure domain is already initialized to 0, so this loop is pointless.


+
+d->arch.altp2m_active = false;
+
+return 0;
+}
+


[...]


diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index 0711796..a156109 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -22,6 +22,9 @@

 #include 

+#define altp2m_lock(d)spin_lock(&(d)->arch.altp2m_lock)
+#define altp2m_unlock(d)  spin_unlock(&(d)->arch.altp2m_lock)
+
 /* Alternate p2m on/off per domain */
 static inline bool_t altp2m_active(const struct domain *d)
 {
@@ -36,4 +39,7 @@ static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)
 return 0;
 }

+int altp2m_init(struct domain *d);
+void altp2m_teardown(struct domain *d);
+
 #endif /* __ASM_ARM_ALTP2M_H */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index cc4bda0..a4e4762 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -127,8 +127,14 @@ struct arch_domain
 paddr_t efi_acpi_len;
 #endif

+/*
+ * Lock that protects access to altp2m related fields in both struct
+ * arch_domain and struct p2m_domain.


This comment looks wrong. struct p2m_domain is protected by its own 
lock. altp2m lock should not protect it.



+ */
+spinlock_t altp2m_lock;
 /* altp2m: allow multiple copies of host p2m */
 bool_t altp2m_active;
+struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
 }  __cacheline_aligned;

 struct arch_vcpu
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 1a004ed..de0c90a 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -9,6 +9,8 @@
 #include 
 #include 

+#define MAX_ALTP2M 10   /* ARM might contain an arbitrary number of
+   altp2m views. */


This should belong to altp2m.h and not p2m.h


 #define paddr_bits PADDR_BITS

 #define INVALID_VTTBR (0UL)



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 11/38] arm/p2m: Cosmetic fix - function prototype of p2m_alloc_table

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

The function "p2m_alloc_table" should be able to allocate 2nd stage
translation tables not only for the host's p2m but also for alternate
p2m's.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Removed altp2m table initialization from "p2m_table_init".

v3: Removed initialization of the field d->arch.altp2m_active in
"p2m_table_init" to avoid altp2m initialization throughout different
files.

Merged the function "p2m_alloc_table" and "p2m_table_init".
---
 xen/arch/arm/p2m.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9ef19d4..dd5d700 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1162,9 +1162,8 @@ void guest_physmap_remove_page(struct domain *d,
 p2m_remove_mapping(d, gfn, (1 << page_order), mfn);
 }

-static int p2m_alloc_table(struct domain *d)
+static int p2m_alloc_table(struct p2m_domain *p2m)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct page_info *page;
 unsigned int i;

@@ -1322,7 +1321,7 @@ int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
 p2m->clean_pte = iommu_enabled &&
 !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

-return p2m_alloc_table(d);
+return p2m_alloc_table(p2m);
 }

 static void p2m_teardown_hostp2m(struct domain *d)



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

[Julien Grall]

Hello Sergej,

On 05/09/16 11:23, Sergej Proskurin wrote:

On 09/02/2016 12:51 PM, Julien Grall wrote:

On 02/09/16 10:09, Sergej Proskurin wrote:

On 09/01/2016 07:36 PM, Julien Grall wrote:

On 16/08/16 23:16, Sergej Proskurin wrote:
Clearing live page table like that is not safe. Each entry (64-bit)
should be written atomically to avoid breaking coherency (e.g if the
MMU
is walking the page table at the same time). However you don't know the
implementation of clear_and_clean_page.


The function p2m_flush_table gets called by the altp2m subsystem
indrectly through the function p2m_teardown_one when the associated view
gets destroyed. In this case we should not worry about crashing the
domain, as the altp2m views are not active anyway.

The function altp2m_reset calls the function p2m_flush_table directly
(with active altp2m views), however, locks the p2m before flushing the
table. I did not find any locks on page-granularity, so please provide
me with further information about the solution you had in mind.


I never mentioned any locking problem. As said in my previous mail,
the altp2m may still be in use by another vCPU. So the MMU (i.e the
hardware) may want do a table walk whilst you modify the entry.

The MMU is reading the entry (64-bit) at once so it also expects the
entry to be modified atomically. However, you don't know the
implementation of clean_and_clean_page. The function might write
32-bit at the time, which means that the MMU will see bogus entry. At
best it will lead to a crash, at worst open a security issue.



I see your point. Not sure how to fix this, though. I believe that the
described issue would remain if we would use free_domheap_pages.
Instead, maybe we should manually set the value in the translation tables?


This is the right way to go.



Or, what if we flush the TLBs immediately before unmapping the root
pages? This would cause the system to load the mappings from memory and
delay a MMU table walk so that it would potentially resolve the
atomicity issue.


I am not sure to fully understand this suggestion. Anyway, the first 
suggestion (i.e invalidating the entry one by one is the right way to go).






 radix_tree_destroy(&p2m->mem_access_settings, NULL);
 }

-int p2m_init(struct domain *d)
+int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc = 0;

 rwlock_init(&p2m->lock);
@@ -1278,11 +1304,14 @@ int p2m_init(struct domain *d)
 return rc;

 p2m->max_mapped_gfn = _gfn(0);
-p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
+p2m->lowest_mapped_gfn = INVALID_GFN;


Why this change?



Since we compare the gfn's with INVALID_GFN throughout the code it makes
sense to use the macro instead of a hardcoded value.


Please don't do unnecessary change. This patch is complex enough to
review.


Ok.


If you want to do the change, then it should be done separately.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code when identifying cpuinfo

[Julien Grall]

Hello Peng,

On 02/09/16 10:41, Peng Fan wrote:

The current_cpu_data indicates the cpuinfo for the current cpu.
There is no need to fill the current_cpu_data from boot_cpu_data,
because the following call to identify_cpu will override it.

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


Acked-by: Julien Grall 

Regards,


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

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d56b91d..90ad1d0 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -288,7 +288,6 @@ void start_secondary(unsigned long boot_phys_offset,

 set_processor_id(cpuid);

-current_cpu_data = boot_cpu_data;
 identify_cpu(¤t_cpu_data);

 init_traps();



--
Julien Grall

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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Julien Grall]

Hello Razvan,

On 07/09/16 10:12, Razvan Cojocaru wrote:

Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for each call, and triggering a TLB flush per page set.

Signed-off-by: Razvan Cojocaru 
Acked-by: Wei Liu 

---
Changes since V3:
 - Fixed ARM compilation (replaced ENOTSUP with EOPNOTSUPP, which is
   #defined in the in-tree errno.h). The multi code remains
   unimplemented for ARM (it depends on " [RFC 21/22] xen/arm: p2m:
   Re-implement p2m_set_mem_access using p2m_{set, get}_entry", and
   Julien Grall has gracefully accepted to defer implementation
   until after both patches go in).


For the ARM bits:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/6] x86/time: streamline platform time init on plt_update()

[Joao Martins]

On 08/30/2016 01:31 PM, Jan Beulich wrote:
 On 30.08.16 at 14:10,  wrote:
>> What would be a preferred period - probably capping it to a 
>> day/hour/minutes? Or
>> keeping the current calculated value? Maximum right now in current platform 
>> timers
>> are few minutes depending on the HPET frequency.
> 
> Ideally I would see you just use the calculated value, unless that
> causes problems elsewhere. Depending on such possible problems
> would be what cap to alternatively use.

While sending v4 out, I spotted some issues with platform timer overflow
handling when we get close to u64 boundary. Specific to clocksource=tsc, and
setting up the plt_overflow, one would see at boot:

"Platform timer appears to have unexpectedly wrapped 10 or more times"

The counter doesn't wrap or stop at all.
But current overflowing checking goes like:

count = plt_src.read_counter();
plt_stamp64 += (count - plt_stamp) & plt_mask;

now = NOW();
plt_wrap = __read_platform_stime(plt_stamp64);
plt_stamp = count;

for (i=0;...)
{

plt_now = plt_wrap;
plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);

@@  if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
break; // didn't wrap around
// did wrap
plt_stamp64 += plt_mask + 1;

}

if (i!=0)
"Platform timer appears to have unexpectedly wrapped "

Effectively the calculation in @@ doesn't handle the fact that for
clocksource=tsc, "ABS(plt_wrap - now)" would be == to "ABS(plt_now -
now)". Not that is right to be so, but TSC is a 64-bit counter and "plt_mask +
1" overflows the u64, turning the above condition into a comparison of same
value. For <= 32-bit platform timers the current math works fine, but reaching
the 64-bit boundary not so much. And then handling the wraparound further below
with "plt_stamp64 += plt_mask + 1" is effectively adding zeroes, which is
assuming that plt_stamp64/plt_stamp is alone enough to not represent any
discontinuity.

I am not sure we shouldn't handle this way at least for clocksource=tsc: we only
see issues when the delta of the two stamps overflows a u64 (computed with:
plt_stamp64 + (read_counter() - plt_stamp)). Keeping those two stamps updated
more often and we won't see issues. When the wraparound happens (in lots lots of
years away) we could not only update plt_stamp64 and plt_stamp, but also
increment stime_platform_stamp and platform_timer_stamp. This lets us compensate
when the stamps wraparound since for stime_platform_stamp (in ns) that would
only happen after STIME_MAX. Or as a simpler alternative, keeping this patch and
update plt_stamp64 (zeroing this one out) plus plt_stamp on
platform_time_calibration() as additional change.

Would that sound reasonable - am I overlooking something? To some extent this
might also applicable to the general case, although platform timer is now only
used for initial seeding so probably a non-visible issue.

Joao

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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Tamas K Lengyel]

On Mon, Sep 5, 2016 at 1:45 PM, Stefano Stabellini
 wrote:
> On Fri, 2 Sep 2016, Julien Grall wrote:
>> On 02/09/2016 18:45, Andrew Cooper wrote:
>> > On 02/09/16 18:37, Tamas K Lengyel wrote:
>> > > On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>> > >  wrote:
>> > > > On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>> > > > > Add support for getting/setting registers through vm_event on ARM.
>> > > > > Only
>> > > > > TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC 
>> > > > > is
>> > > > > set
>> > > > > as part of a response. The set of registers can be expanded in the
>> > > > > future to
>> > > > > include other registers as well if necessary.
>> > > > >
>> > > > > Signed-off-by: Tamas K Lengyel 
>> > > > > Reviewed-by: Andrew Cooper 
>> > > > Acked-by: Razvan Cojocaru 
>> > > Patch ping.
>> >
>> > Requires an ARM ack.
>>
>> I don't think it requires an ack from Stefano and I, it touches only the
>> vm_event subsystem.
>>
>> If you still want an ARM ack, then I will defer to Stefano.
>
> Acked-by: Stefano Stabellini 

Thanks! I think this is ready for merging.

Tamas

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

[Xen-devel] XenProject/XenServer QEMU working group minutes, 30th August 2016

[Jennifer Herbert]

QEMU XenServer/XenProject Working group meeting 30th August 2016


Attendance
--

Andrew Cooper
Ian Jackson
Paul Durrant
David Vrabel
Jennifer Herbert

Introduction


Introduced Paul Durrant to the working group.

Started by recapping our purpose: A way to make it possible for qemu
to be able to make hypercalls without too much privilege, in a way
which is up streamable.Dom0 guest must not be able abuse interface
to compromise dom0 kernel.

QEMU Hypercalls – DM op
---

Has been much discussion on XenDevel -  a problem identified is when
you have operations with references to  other user memory objects,
such as with Track dirty VRAM (As used with the VGA buffer)  At the
moment, apparently there is only that one, but others may emerge.

Most obvious solution would involve the guest kernel validating the
virtual address passed, however that would would rely on the guest
kernel knowing where to objects where.   This is to be avoided.

Ian recounts how there where variose proposals, on XenDevel involving,
essentially, informing the hypervisor, or some way providing the
information about which virtual addresses where being talked about by
the hypercall to the hypervisor.  Many of these involved this
information being transmitted via a different channel.

Ian suggest the idea provide a way for the kernel to tell the
hypervisor is user virtual rages, dm op allowed memory. And there
would be a flag, in the dm op, in a fixed location, that would tell
the hypervisor, this only talks about special dm pre-approved memory.


A scheme of pre-nominating an area in QEMU, maybe using hypercall
buffers is briefly discussed,as well as a few other ideas, but
concludes that doesn’t really address the problem of future DM ops –
of which there could easily be.  Even if we can avoid the problem by
special cases for our current set-up, we still need a story for how to
add future interfaces with handles, without the need to change the
kernel interface.  Once we come up with story, we wouldn't necessarily
have to implement it.


The concept of using physical addressed hypercall buffers was
discussed.  Privcmd could allocate you a place, and mmap it into user
ram, and this is the only memory that would be used with the
hypercalls.  A hypercall would tell you the buffer range. Each qemu
would need to be associated with the correct set of physical buffers.

A recent AMD proposal was discussed, which would use only physical
addresses, no virtual address.  The upshot being we should come up
with a solution that is not incompatible this.

Ideas further discussed: User code could just put stuff in mmaped
memory, and only refer to offset within that buffer.  The privcmd
driver would fill in physical details. All dm ops would have 3
arguments:  dm op, pointer to to struct, and optional pointer to
restriction array – the last of which is filled in my privcmd driver.
It is discussed how privcmd driver must not look at the dm op number,
in particular, to know how to validate addresses, as it must be
independent from the API.

A scheme where qemu calls an ioctl before it drops privileges, to set
up restrictions ahead of time, is discussed.  One scheme may work by
setting up a rang for a given domain or VCPU.

The assumption is that all device model, running in the same domain,
have the same virtual address layout.  Then there would be a flag, in
the stable bit of the api, if to apply that restriction  - any kernel
dm op would not apply that restriction.

The idea can be extended – to have more one address range, or can have
range explicitly provided in the hypercall.  This latter suggestion is
preferred, however each platform would have different valid address
ranges, and privcmd is platform independent.  Its discussed how a
function could be created to return valid rages for your given
platform, but this is not considered a element solution. The third
parameter of the dm op could be array of ranges, where common case for
virtual addresses may be 0-3GB, but for physical addresses, it might
be quite fragmented.


A further ideas is proposed to extend the dm op, to have a fixed part,
to have an array of guest handles, the kernel can audit. The
arguments would be:

Arg1: Dom ID:
Arg2: Guests handle array of tuples(address, size)
Arg3: Number guest handles.

The first element of the array could be the DM op structure itself,
containing the DM Op code, and othe argument to the perticular op.
The Privcmd driver would only pass though what is provided by the
user.  Any extra elements would be ignored by the hypercall, and if
there where insufficient, the hypercall code would see a NULL, and be
able to gracefully fail.

The initial block (of dm arguments) passed in the array would be
copied into pre-zeroed memory of max op size, having checked the size
is not greater then this.  No need to check minimum, buffer
initialised to zero, so zero length 

[Xen-devel] [xen-4.7-testing test] 100830: tolerable FAIL - PUSHED

[osstest service owner]

flight 100830 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100830/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100777
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100777
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100777

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

Last test of basis   100777  2016-09-06 19:49:12 Z2 days
Testing same since   100813  2016-09-08 12:44:23 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass  

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Jan Beulich]

>>> On 09.09.16 at 18:05,  wrote:
> On 09/09/2016 11:20 AM, Jan Beulich wrote:
> On 09.09.16 at 15:56,  wrote:
>>> On 09/09/2016 09:29 AM, Jan Beulich wrote:
>>> On 09.09.16 at 15:07,  wrote:
> On 09/09/2016 04:03 AM, Jan Beulich wrote:
> On 08.09.16 at 20:51,  wrote:
>>> On 09/08/2016 10:15 AM, Jan Beulich wrote:
>>> On 07.09.16 at 20:59,  wrote:
>  vpath iasl $(PATH)
>  all: $(C_SRC) $(H_SRC)
> + rm -fr $(TDIR)
 And how is the temporary directory going to get cleaned up when
 interrupting make? I think you really should use a subdirectory
 underneath the build directory, which then can stay there until
 "make clean". And then you can also use mv instead of cp below,
 or even move-if-changed.
>>> The reason I am doing this in /tmp and use tmp_X as template is
>>> because I found that at least one old versions of iasl has a bug where
>>> it can't process path that has a '.' in it. It drops anything after the
>>> dot, presumably because it thinks it's file suffix.
>> That . is a leading one, as in ./path/file.ext? If so, why can't this be
>> made path/file.ext? The leading ./ shouldn't be necessary after all.
> No, not a leading one. Inside a name:
>
> Expected:
>
> [root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
> [root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
 Then my suggestion of using relative paths would still help?
>>> Apparently it doesn't like any dots:
>>>
>>> [root@ovs104 /]# mkdir -p /tmp/root/foo
>>> [root@ovs104 /]# mkdir -p /tmp/root/bar
>>> [root@ovs104 /]# cd /tmp/root/foo/
>>> [root@ovs104 foo]# ls -aR /tmp/root/
>>> /tmp/root/:
>>> .  ..  bar  foo
>>>
>>> /tmp/root/bar:
>>> .  ..
>>>
>>> /tmp/root/foo:
>>> .  ..
>>> [root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc
>> Why would you need to use ../ ?
> 
> 
> Didn't you ask to test with a relative path?

Yes, and I gave an example of what I meant: dir/name.ext; no
./ or ../ or alike.

Jan


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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/09/2016 11:20 AM, Jan Beulich wrote:
 On 09.09.16 at 15:56,  wrote:
>> On 09/09/2016 09:29 AM, Jan Beulich wrote:
>> On 09.09.16 at 15:07,  wrote:
 On 09/09/2016 04:03 AM, Jan Beulich wrote:
 On 08.09.16 at 20:51,  wrote:
>> On 09/08/2016 10:15 AM, Jan Beulich wrote:
>> On 07.09.16 at 20:59,  wrote:
  vpath iasl $(PATH)
  all: $(C_SRC) $(H_SRC)
 +  rm -fr $(TDIR)
>>> And how is the temporary directory going to get cleaned up when
>>> interrupting make? I think you really should use a subdirectory
>>> underneath the build directory, which then can stay there until
>>> "make clean". And then you can also use mv instead of cp below,
>>> or even move-if-changed.
>> The reason I am doing this in /tmp and use tmp_X as template is
>> because I found that at least one old versions of iasl has a bug where
>> it can't process path that has a '.' in it. It drops anything after the
>> dot, presumably because it thinks it's file suffix.
> That . is a leading one, as in ./path/file.ext? If so, why can't this be
> made path/file.ext? The leading ./ shouldn't be necessary after all.
 No, not a leading one. Inside a name:

 Expected:

 [root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
 [root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
>>> Then my suggestion of using relative paths would still help?
>> Apparently it doesn't like any dots:
>>
>> [root@ovs104 /]# mkdir -p /tmp/root/foo
>> [root@ovs104 /]# mkdir -p /tmp/root/bar
>> [root@ovs104 /]# cd /tmp/root/foo/
>> [root@ovs104 foo]# ls -aR /tmp/root/
>> /tmp/root/:
>> .  ..  bar  foo
>>
>> /tmp/root/bar:
>> .  ..
>>
>> /tmp/root/foo:
>> .  ..
>> [root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc
> Why would you need to use ../ ?


Didn't you ask to test with a relative path?

(Not this this is needed anymore, now that Ian suggested a solution).

-boris

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

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

[Razvan Cojocaru]

On 09/09/16 18:41, Tamas K Lengyel wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. Under certain scenarios this memory region may contain
> instructions that a monitor subscriber would prefer to hide, namely INT3, and
> instead would prefer to emulate a different instruction in-place.
> 
> This patch extends the vm_event interface to allow returning this i-cache via
> the vm_event response.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: George Dunlap 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
>  xen/arch/x86/hvm/emulate.c| 47 
> +--
>  xen/arch/x86/hvm/hvm.c|  2 +-
>  xen/arch/x86/hvm/vmx/vmx.c|  1 +
>  xen/arch/x86/mm/p2m.c |  7 --
>  xen/arch/x86/vm_event.c   | 10 +
>  xen/common/vm_event.c |  5 -
>  xen/include/asm-arm/vm_event.h|  6 +
>  xen/include/asm-x86/hvm/emulate.h |  6 +++--
>  xen/include/asm-x86/vm_event.h|  4 +++-
>  xen/include/public/vm_event.h | 11 +++--
>  10 files changed, 73 insertions(+), 26 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index c55ad7b..968fb7b 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -76,9 +76,12 @@ static int set_context_data(void *buffer, unsigned int 
> size)
>  if ( curr->arch.vm_event )
>  {
>  unsigned int safe_size =
> -min(size, curr->arch.vm_event->emul_read_data.size);
> +min(size, curr->arch.vm_event->emul_data.size);
>  
> -memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
> +gdprintk(XENLOG_WARNING, "Got buffer of size: %u. Request is for %u. 
> Safe size: %u\n",
> + curr->arch.vm_event->emul_data.size, size, safe_size);
> +
> +memcpy(buffer, curr->arch.vm_event->emul_data.data, safe_size);
>  memset(buffer + safe_size, 0, size - safe_size);
>  return X86EMUL_OKAY;
>  }
> @@ -825,7 +828,7 @@ static int hvmemul_read(
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>  
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return set_context_data(p_data, bytes);
>  
>  return __hvmemul_read(
> @@ -1027,7 +1030,7 @@ static int hvmemul_cmpxchg(
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>  
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  {
>  int rc = set_context_data(p_new, bytes);
>  
> @@ -1120,7 +1123,7 @@ static int hvmemul_rep_outs(
>  p2m_type_t p2mt;
>  int rc;
>  
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
>  bytes_per_rep, reps, ctxt);
>  
> @@ -1262,7 +1265,7 @@ static int hvmemul_rep_movs(
>  if ( buf == NULL )
>  return X86EMUL_UNHANDLEABLE;
>  
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  {
>  rc = set_context_data(buf, bytes);
>  
> @@ -1460,7 +1463,7 @@ static int hvmemul_read_io(
>  
>  *val = 0;
>  
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return set_context_data(val, bytes);
>  
>  return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
> @@ -1783,7 +1786,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
> *hvmemul_ctxt,
>  pfec |= PFEC_user_mode;
>  
>  hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_context_insn) )
> +{
> +memcpy(hvmemul_ctxt->insn_buf, curr->arch.vm_event->emul_data.data,
> +   curr->arch.vm_event->emul_data.size);
> +hvmemul_ctxt->insn_buf_bytes = curr->arch.vm_event->emul_data.size;
> +}

All these places where we're working with curr->arch.vm_event should
check that it's not NULL. Other than that, I like the concept.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Tim Deegan]

At 11:56 + on 09 Sep (1473422177), Lars Kurth wrote:
> Community Decisions with Funding and Legal Implications
> (#funding-and-legal)
> ---
> 
> In some cases sub-project local and global decisions **may require
> input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
> (#roles-lf). For example, if a proposal by a project leadership team or
> a global project decision requires that the project hires a staff member
> or 
> contractor (e.g. a PR consultant, marketing manager) or requires the
> funding 
> of new infrastructure (e.g. additional test hardware or services) to
> implement 
> said proposal, then funding would need to be secured from the Advisory
> Board or 
> from other sources.
> 
> If for example, a community proposal required the Linux Foundation to sign
> a legal agreement with a 3rd party on behalf of the project/sub-project,
> then 
> of course a review of such an agreement and a signature by the Linux
> Foundation 
> would be required. 
> 
> In such cases, the impacted project leadership team(s) will contact the
> Community Manager and/or Advisory Board to resolve possible issues.
> 
> 
> -

FWIW, LGTM.

Cheers,

Tim.


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

[Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

[Tamas K Lengyel]

When emulating instructions the emulator maintains a small i-cache fetched
from the guest memory. Under certain scenarios this memory region may contain
instructions that a monitor subscriber would prefer to hide, namely INT3, and
instead would prefer to emulate a different instruction in-place.

This patch extends the vm_event interface to allow returning this i-cache via
the vm_event response.

Signed-off-by: Tamas K Lengyel 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/x86/hvm/emulate.c| 47 +--
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c|  1 +
 xen/arch/x86/mm/p2m.c |  7 --
 xen/arch/x86/vm_event.c   | 10 +
 xen/common/vm_event.c |  5 -
 xen/include/asm-arm/vm_event.h|  6 +
 xen/include/asm-x86/hvm/emulate.h |  6 +++--
 xen/include/asm-x86/vm_event.h|  4 +++-
 xen/include/public/vm_event.h | 11 +++--
 10 files changed, 73 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c55ad7b..968fb7b 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -76,9 +76,12 @@ static int set_context_data(void *buffer, unsigned int size)
 if ( curr->arch.vm_event )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event->emul_data.size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+gdprintk(XENLOG_WARNING, "Got buffer of size: %u. Request is for %u. 
Safe size: %u\n",
+ curr->arch.vm_event->emul_data.size, size, safe_size);
+
+memcpy(buffer, curr->arch.vm_event->emul_data.data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
@@ -825,7 +828,7 @@ static int hvmemul_read(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(p_data, bytes);
 
 return __hvmemul_read(
@@ -1027,7 +1030,7 @@ static int hvmemul_cmpxchg(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 int rc = set_context_data(p_new, bytes);
 
@@ -1120,7 +1123,7 @@ static int hvmemul_rep_outs(
 p2m_type_t p2mt;
 int rc;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
 bytes_per_rep, reps, ctxt);
 
@@ -1262,7 +1265,7 @@ static int hvmemul_rep_movs(
 if ( buf == NULL )
 return X86EMUL_UNHANDLEABLE;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 rc = set_context_data(buf, bytes);
 
@@ -1460,7 +1463,7 @@ static int hvmemul_read_io(
 
 *val = 0;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(val, bytes);
 
 return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
@@ -1783,7 +1786,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 pfec |= PFEC_user_mode;
 
 hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+
+if ( unlikely(hvmemul_ctxt->set_context_insn) )
+{
+memcpy(hvmemul_ctxt->insn_buf, curr->arch.vm_event->emul_data.data,
+   curr->arch.vm_event->emul_data.size);
+hvmemul_ctxt->insn_buf_bytes = curr->arch.vm_event->emul_data.size;
+}
+else if ( !vio->mmio_insn_bytes )
 {
 hvmemul_ctxt->insn_buf_bytes =
 hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
@@ -1927,17 +1937,19 @@ void hvm_mem_access_emulate_one(enum emul_kind kind, 
unsigned int trapnr,
 struct hvm_emulate_ctxt ctx = {{ 0 }};
 int rc;
 
+gdprintk(XENLOG_WARNING, "memaccess emulate one called\n");
+
 hvm_emulate_prepare(&ctx, guest_cpu_user_regs());
 
-switch ( kind )
-{
-case EMUL_KIND_NOWRITE:
+if ( kind == EMUL_KIND_NOWRITE )
 rc = hvm_emulate_one_no_write(&ctx);
-break;
-case EMUL_KIND_SET_CONTEXT:
-ctx.set_context = 1;
-/* Intentional fall-through. */
-default:
+else
+{
+ if ( kind == EMUL_KIND_SET_CONTEXT_DATA )
+ctx.set_context_data = 1;
+ else if ( kind == EMUL_KIND_SET_CONTEXT_INSN )
+ctx.set_context_insn = 1;
+
 rc = hvm

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[David Vrabel]

On 09/09/16 16:16, Jennifer Herbert wrote:
> On 01/08/16 12:32, Ian Jackson wrote:
>> I think we need to introduce a new hypercall (which I will call DMOP
>> for now) which may augment or replace some of HVMCTL.  Let me explain:
>>
> 
> I believe the new 'DMOP' hypercall is a good idea,  but following on
> from discussions, I propose a revised design, which I present below.
> Please let me know what you think.
> 
> Thanks,
> Jenny.
> 
> 
> DMOP  (multi-buffer variant)
> 
[...]
> Advantages of this system, over previouse DMOP proposals:
> 
> 
> *  The validation of address ranges is easily done by the privcmd driver,
>using standard kernel mechanisms.  No need to get Xen thinking about
>guest memory layout, which it should be independent of, and potentially
>adding confusion.

+1.

The user address limit in Linux is a per-thread property, so trying to
pass this information to the hypervisor would require passing this
information in every dm_op, or switching the information on every task
switch.  The user address limit is also architecture specific, and would
require every arch to expose this via some new API.

David

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

Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted

[Jan Beulich]

>>> On 09.09.16 at 15:50,  wrote:
> On Fri, Sep 09, 2016 at 02:33:18PM +0100, Ross Lagerwall wrote:
>> On 08/24/2016 03:22 AM, Konrad Rzeszutek Wilk wrote:
>> > So that when we apply the patch again the .bss is cleared.
>> > Otherwise we may find some variables containing old values.
>> > 
>> > The payloads may contain various .bss - especially if -fdata-sections
>> > is used which can create .bss. sections.
>> > 
>> 
>> After having thought about this again, I'm not sure it makes much sense. Any
>> data sections in the payload are not reset to their initial values, so
>> resetting the bss only may result in an unexpected combination of new & old
>> data/bss.
> 
> Regardless of that I think clearing the .bss upon applying the livepatch is
> still the right thing to do.
> 
> Regarding of the .data - we could have a copy of the .data the first time
> we load - and then during application copy over it from the original one?.
> 
>> 
>> Perhaps it just needs to be documented that a payload's bss/data is
>> untouched across revert/apply?
> 
> It really cuts down on bugs if we clear the .bss. It is kind of ingrained in 
> every
> developer that the .bss is zero-ed out at startup.

I don't think Ross meant to suggest to not clear it at all: Clearing it
at load time is the equivalent of loading actual data into initialized
sections.

Jan


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

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-libvirt-vhd

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-vhd
testid debian-di-install

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  3f0ae679f2704ca5671eef5be59ec30982fbf08a
  Bug not present: b0c0e695e05dc52212b8fdbf8d973be353af7b6a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/100850/


  commit 3f0ae679f2704ca5671eef5be59ec30982fbf08a
  Author: Wei Liu 
  Date:   Mon Aug 15 11:32:56 2016 +0100
  
  tools: remove blktap2 related code and documentation
  
  Blktap2 is effectively dead code for a few years.
  
  Notable changes in this patch:
  
  0. Unhook blktap2 from build system
  1. Now libxl no longer supports TAP disk backend, appropriate assertions
 are added and some code paths now return ERROR_FAIL
  2. Tap is no longer a supported backend in doc
  3. Remove relevant entries in MAINTAINERS
  
  A patch to actually remove blktap2 directory will come later.
  
  Signed-off-by: Wei Liu 
  Acked-by: George Dunlap 
  Acked-by: Ian Jackson 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-libvirt-vhd.debian-di-install
 --summary-out=tmp/100850.bisection-summary --basis-template=100773 
--blessings=real,real-bisect xen-unstable test-amd64-amd64-libvirt-vhd 
debian-di-install
Searching for failure / basis pass:
 100819 fail [host=fiano1] / 100773 [host=italia0] 100766 [host=merlot1] 100751 
[host=godello0] 100738 [host=pinot0] 100734 [host=baroque0] 100712 
[host=baroque1] 100706 [host=nocera1] 100690 [host=nocera0] 100684 
[host=italia1] 100681 [host=fiano0] 100674 [host=elbling1] 100667 
[host=godello1] 100663 ok.
Failure / basis pass flights: 100819 / 100663
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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 fe94ee5db5461970743f52a85fc295af023f50bf 
a2a39436b65f329630df4a93ec4e30aeae403c54 
a38ae26d5b7a39deb83b53e7940acc217428622d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6e20809727261599e8527c456eb078c0e89139a1 
570117996772b762e9654e58e708943a4db68b4f 
3d20a6f4faf1c6a18b51b80d99d23daa7762dda2
Basis pass 61148074773ba180f17020b0b11c155b154726fd 
a2a39436b65f329630df4a93ec4e30aeae403c54 
bb28cae901ddf2a4c708dbd03e9e304536c966dc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6e20809727261599e8527c456eb078c0e89139a1 
d145386f52950c0c5d4587dbb6c3b9cdf3a58309 
9daed8321b44c3ca82e412eb130f84e6b6c17dc5
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#61148074773ba180f17020b0b11c155b154726fd-fe94ee5db5461970743f52a85fc295af023f50bf
 
git://git.sv.gnu.org/gnulib.git#a2a39436b65f329630df4a93ec4e30aeae403c54-a2a39436b65f329630df4a93ec4e30aeae403c54
 
git://xenbits.xen.org/linux-pvops.git#bb28cae901ddf2a4c708dbd03e9e304536c966dc-a38ae26d5b7a39deb83b53e7940acc217428622d
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#6e20809727261599e8527c456eb078c0e89139a1-6e20809727261599e8527c456eb078c0e89139a1
 
git://xenbits.xen.org/qemu-xen.git#d145386f52950c0c5d4587dbb6c3b9cdf3a58309-570117996772b762e9654e58e708943a4db68b4f
 
git://xenbits.xen.org/xen.git#9daed8321b44c3ca82e412eb130f84e6b6c17dc5-3d20a6f4faf1c6a18b51b80d99d23daa7762dda2
Loaded 15476 nodes in revision graph
Searching for test results:
 100663 pass 61148074773ba180f17020b0b11c155b154726fd 
a2a39436b65f329630df4a93ec4e30aeae403c54 
bb28cae901ddf2a4c708dbd03e9e304536c966dc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6e20809727261599e8527c456eb078c0e89139a1 
d145386f52950c0c5d4587dbb6c3b9cdf3a58309 
9daed8321b44c3ca82e412eb130f84e6b6c17dc5
 100667 [host=godello1]
 100674 [host=elbling1]
 100690 [host=nocera0]
 100681 [host=fiano0]
 100706 [host=nocera1]
 100684 [host=italia1]
 100734 [host=baroque0]
 100712 [host=baroque1]
 100738 [host=pi

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Jennifer Herbert]

On 01/08/16 12:32, Ian Jackson wrote:

I think we need to introduce a new hypercall (which I will call DMOP
for now) which may augment or replace some of HVMCTL.  Let me explain:



I believe the new 'DMOP' hypercall is a good idea,  but following on
from discussions, I propose a revised design, which I present below.
Please let me know what you think.

Thanks,
Jenny.


DMOP  (multi-buffer variant)



Introduction


A previous proposal for a 'DMOP' was put forward by Ian Jackson on the 1st
of August. This proposal seem very promising, however a problem was
identified with it, that this proposal addresses.

The aim of DMOP, as before, is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)

The previous proposal adds a DMOP hypercall, for use by the device models,
which places the domain ID in a fixed place, within the calling args,
such that the priv driver can always find it, and not need to know any
further details about the particular DMOP in order to validate it against
previously set (vie ioctl) domain.

The problem occurs when you have a DMOP with references to other user memory
objects, such as with Track dirty VRAM (As used with the VGA buffer).
Is this case, the address of this other user object needs to be vetted,
to ensure it is not within a restricted address ranges, such as kernel
memory. The real problem comes down to how you would vet this address -
the idea place to do this is within the privcmd driver, since it would have
knowledge of the address space involved. However, with a principal goal
of DMOP to allow privcmd to be free from any knowledge of DMOP's sub ops,
it would have no way to identify any user buffer  addresses that need
checking.  The alternative of allowing the hypervisor to vet the address
is also problematic, since it has no knowledge of the guest memory layout.


The Design
--

As with the previous design, we provide a new restriction ioctl, which
takes a domid parameter.  After that restriction ioctl is called, the
privcmd driver will permit only DMOP hypercalls, and only with the
specified target domid.

In the previous design, a DMOP consisted of one buffer, containing all of
the DMOP parameters, which may include further explicit references to
more buffers.  In this design, an array of buffers with length is presented,
with the first one containing the DMOP parameters, which could implicitly
reference to further buffers from within in the array. Here, the only
user buffers passed, are that found with the array, and so all can be 
audited

from privcmd.  With the passing of the length of the buffers array, privcmd
does not need to know which DMOP it is to audit them.

If the hypervisor ends up with the wrong number of buffers, it can reject
the DMOP at that point.

The following code illustrates this idea:

typedef struct dm_op_buffer {
XEN_GUEST_HANDLE(void) h;
size_t len;
} dm_op_buffer_t;

int
HYPERVISOR_device_model_op(
domid_t domid,
unsigned int nr_buffers,
XEN_GUEST_HANDLE_PARAM(dm_op_buffer_t) buffers)

@domid: the domain the hypercall operates on.
@nr_buffers; the number of buffers in the @buffers array.

@buffers: an array of buffers.  @buffers[0] contains device_model_op - the
structure describing the sub-op and its parameters. @buffers[1], @buffers[2]
etc. may be used by a sub-op for passing additional buffers.

struct device_model_op {
uint32_t op;
union {
 struct op_1 op1;
 struct op_2 op2;
 /* etc... */
} u;
};

It is forbidden for the above struct (device_model_op) to contain any
guest handles - if they are needed, they should instead be in
HYPERVISOR_device_model_op->buffers.

Validation by privcmd driver
--

If the privcmd driver has been restricted to specific domain (using a
 new ioctl), when it received an op, it will:

1. Check hypercall is DMOP.

2. Check domid == restricted domid.

3. For each @nr_buffers in @buffers: Check @h and @len give a buffer
   wholey in the user space part of the virtual address space. (e.g.,
   on Linux use access_ok()).


Xen Implementation
--

Since a DMOP sub of may need to copy or return a buffer from the guest,
as well as the DMOP itself to git the initial buffer, functions for doing
this would be written as below.  Note that care is taken to prevent
damage from buffer under or over run situations.  If the DMOP is called
with insufficient buffers, zeros will be read, while extra is ignored.


int copy_dm_buffer_from_guest(
void *dst,/* Kernel destination buffer  */
size_t max_len,   /* Size of destination buffer */
XEN_GUEST_HANDLE_PARAM(dm_op_buffer_t) buffers,
  /* dm_op_buffers passed into DMOP */
unsigned int nr_buffers,  /* total number of dm_op_buffers  */
  

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Doug Goldstein]

On 9/8/16 11:21 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
>> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
>> typo-ed the source file name of the EFI map file install command.
> 
>  I really need Fedora to start building ld with PE support.

So locally we've got a script called "containerize.sh" that uses Docker
and fetches down a container and then runs whatever commands you want in
that environment. This allows us to use whatever distro we want on our
desktop/laptops but have 1 toolchain setup that is the blessed
toolchain. Would something like this be useful to commit upstream? Not
that we'd want to bless one toolchain but it would be an environment
where all the dependencies are installed and its in a known good state.
This also allows me to develop for Linux based projects when I'm on
travel and only have my Mac with me.

-- 
Doug Goldstein



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 v3 13/19] acpi: Makefile should better tolerate interrupts

[Jan Beulich]

>>> On 09.09.16 at 15:56,  wrote:
> On 09/09/2016 09:29 AM, Jan Beulich wrote:
> On 09.09.16 at 15:07,  wrote:
>>> On 09/09/2016 04:03 AM, Jan Beulich wrote:
>>> On 08.09.16 at 20:51,  wrote:
> On 09/08/2016 10:15 AM, Jan Beulich wrote:
> On 07.09.16 at 20:59,  wrote:
>>>  vpath iasl $(PATH)
>>>  all: $(C_SRC) $(H_SRC)
>>> +   rm -fr $(TDIR)
>> And how is the temporary directory going to get cleaned up when
>> interrupting make? I think you really should use a subdirectory
>> underneath the build directory, which then can stay there until
>> "make clean". And then you can also use mv instead of cp below,
>> or even move-if-changed.
> The reason I am doing this in /tmp and use tmp_X as template is
> because I found that at least one old versions of iasl has a bug where
> it can't process path that has a '.' in it. It drops anything after the
> dot, presumably because it thinks it's file suffix.
 That . is a leading one, as in ./path/file.ext? If so, why can't this be
 made path/file.ext? The leading ./ shouldn't be necessary after all.
>>> No, not a leading one. Inside a name:
>>>
>>> Expected:
>>>
>>> [root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
>>> [root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
>> Then my suggestion of using relative paths would still help?
> 
> Apparently it doesn't like any dots:
> 
> [root@ovs104 /]# mkdir -p /tmp/root/foo
> [root@ovs104 /]# mkdir -p /tmp/root/bar
> [root@ovs104 /]# cd /tmp/root/foo/
> [root@ovs104 foo]# ls -aR /tmp/root/
> /tmp/root/:
> .  ..  bar  foo
> 
> /tmp/root/bar:
> .  ..
> 
> /tmp/root/foo:
> .  ..
> [root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc

Why would you need to use ../ ?

Jan


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

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[Juergen Gross]

On 09/09/16 16:20, Boris Ostrovsky wrote:
> On 09/09/2016 02:14 AM, Juergen Gross wrote:
>> On 08/09/16 16:10, Boris Ostrovsky wrote:
>>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
 Support the driver_override scheme introduced with commit 782a985d7af2
 ("PCI: Introduce new device binding path using pci_dev.driver_override")

 As pcistub_probe() is called for all devices (it has to check for a
 match based on the slot address rather than device type) it has to
 check for driver_override set to "pciback" itself.

 Signed-off-by: Juergen Gross 
 ---
 V2: removed now unused label
 ---
  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

 diff --git a/drivers/xen/xen-pciback/pci_stub.c 
 b/drivers/xen/xen-pciback/pci_stub.c
 index 258b7c3..85c28f7 100644
 --- a/drivers/xen/xen-pciback/pci_stub.c
 +++ b/drivers/xen/xen-pciback/pci_stub.c
 @@ -25,6 +25,8 @@
  #include "conf_space.h"
  #include "conf_space_quirks.h"
  
 +#define PCISTUB_DRIVER_NAME "pciback"
 +
  static char *pci_devs_to_hide;
  wait_queue_head_t xen_pcibk_aer_wait_queue;
  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
 @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
 struct pci_device_id *id)
"don't have a normal (0) or bridge (1) "
"header type!\n");
err = -ENODEV;
 -  goto out;
}
  
 +  } else if (!dev->driver_override ||
 + strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
 +  /* Didn't find the device */
 +  err = -ENODEV;
 +
 +  if (!err) {
dev_info(&dev->dev, "seizing device\n");
err = pcistub_seize(dev);
 -  } else
 -  /* Didn't find the device */
 -  err = -ENODEV;
 +  }
>>> Should devices with pciback override be displayed in
>>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>>> either added to pcistub_device_ids or kept on some other list.
>> No, I don't think so. The patch is just needed to _avoid_ having to use
>> the slots stuff: without the patch you need something like:
>>
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> while with the patch you can use the same mechanism as for similar
>> drivers like pci-stub and vfio-pci:
>>
>> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> So e.g. libvirt doesn't need special handling for pciback. The slot list
>> is necessary for assigning devices to pciback on boot, but I think the
>> override mechanism is better for runtime assignment.
> 
> I am not arguing against override mechanism.
> 
> My point is that people/tools may rely on the fact devices are always
> listed in slots file. For example, libxl_pci.c parses at this file (I
> haven't look at this code in details so perhaps it's only when checking
> for devices assigned at boot time).

Looking at libxl_pci.c I'm even more convinced we should _not_ add a
device added via the override mechanism to the list of slots: the
parsing of the file is done in case a device is to be added via xl
to pciback. This happens via the new_slot mechanism, while libvirt
wants to use the override mechanism. This is just one more case where
using both libvirt and xl for the same thing is a bad idea.

In case someone wants to remove a pci device which was added with
libvirt by means of xl it is still possible to add the device to slots
by echoing its pci address to new_slot.

>>> Also, do you think checking override might better be done first, before
>>> testing for ID match?
>> Why? I don't think this really matters.
> 
> It may provide (probably very slight) performance improvement when you
> have lots of assigned devices.

Really? A system where the override is being used should have only
those pci devices in the ID list which have been assigned at boot time
to pciback. How many are those? Even on a really huge machine less
than 1000. This would save us a few microseconds.

OTOH I don't mind changing the sequence. I've just realized that I've
missed the PCI_HEADER_TYPE test in the override path, so I should
send a V2 in any case.


Juergen


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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/09/2016 10:33 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v3 13/19] acpi: Makefile should better 
> tolerate interrupts"):
>> In fact, I can just append a dot to the name:
> I think it would be less weird to append a dot and then an actual
> extension with some letters or something.  I'm not sure what the
> extension ought to be but just a dot is going to be weird and
> confusing.

Yes, I will append some sort of a suffix and add a comment explaining
why it is needed.

-boris

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v3 13/19] acpi: Makefile should better 
tolerate interrupts"):
> In fact, I can just append a dot to the name:

I think it would be less weird to append a dot and then an actual
extension with some letters or something.  I'm not sure what the
extension ought to be but just a dot is going to be weird and
confusing.

Ian.

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/09/2016 10:13 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v3 13/19] acpi: Makefile should better 
> tolerate interrupts"):
>> On 09/09/2016 09:29 AM, Jan Beulich wrote:
>>> Then my suggestion of using relative paths would still help?
>> Apparently it doesn't like any dots:
> ...
>> [root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc
>> /tmp/dsdt_anycpu.asl &>/dev/null
>> [root@ovs104 foo]# ls -aR /tmp/root/
>> /tmp/root/:
>> .  ..  bar  foo
>>
>> /tmp/root/bar:
>> .  ..
>>
>> /tmp/root/foo:
>> .  ..  ..aml  ..hex
>> [root@ovs104 foo]#
> This seems to suggest that it looks for the last dot, not the first
> one.
>
> If you provide a filename which has an "extension", as it seems to
> expect, does it DTRT ?

Indeed!

In fact, I can just append a dot to the name:

[root@ovs104 tmp]# mkdir -p /tmp/root/xen.git
[root@ovs104 tmp]# ~/iasl.f12 -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
/tmp/dsdt_anycpu.asl &>/dev/null
[root@ovs104 tmp]# ls -aR /tmp/root/
/tmp/root/:
.  ..  xen.aml  xen.git  xen.hex

/tmp/root/xen.git:
.  ..
[root@ovs104 tmp]# ~/iasl.f12 -vs -p /tmp/root/xen.git/dsdt_anycpu. -tc
/tmp/dsdt_anycpu.asl &>/dev/null
[root@ovs104 tmp]# ls -aR /tmp/root/
/tmp/root/:
.  ..  xen.aml  xen.git  xen.hex

/tmp/root/xen.git:
.  ..  dsdt_anycpu.aml  dsdt_anycpu.hex
[root@ovs104 tmp]#


With that I can go back to my original version where I don't need to
have a temp directory at all.

Thanks Ian.

-boris

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

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[Juergen Gross]

On 09/09/16 16:27, David Vrabel wrote:
> On 09/09/16 07:14, Juergen Gross wrote:
>> On 08/09/16 16:10, Boris Ostrovsky wrote:
>>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
 Support the driver_override scheme introduced with commit 782a985d7af2
 ("PCI: Introduce new device binding path using pci_dev.driver_override")

 As pcistub_probe() is called for all devices (it has to check for a
 match based on the slot address rather than device type) it has to
 check for driver_override set to "pciback" itself.

 Signed-off-by: Juergen Gross 
 ---
 V2: removed now unused label
 ---
  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

 diff --git a/drivers/xen/xen-pciback/pci_stub.c 
 b/drivers/xen/xen-pciback/pci_stub.c
 index 258b7c3..85c28f7 100644
 --- a/drivers/xen/xen-pciback/pci_stub.c
 +++ b/drivers/xen/xen-pciback/pci_stub.c
 @@ -25,6 +25,8 @@
  #include "conf_space.h"
  #include "conf_space_quirks.h"
  
 +#define PCISTUB_DRIVER_NAME "pciback"
 +
  static char *pci_devs_to_hide;
  wait_queue_head_t xen_pcibk_aer_wait_queue;
  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
 @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
 struct pci_device_id *id)
"don't have a normal (0) or bridge (1) "
"header type!\n");
err = -ENODEV;
 -  goto out;
}
  
 +  } else if (!dev->driver_override ||
 + strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
 +  /* Didn't find the device */
 +  err = -ENODEV;
 +
 +  if (!err) {
dev_info(&dev->dev, "seizing device\n");
err = pcistub_seize(dev);
 -  } else
 -  /* Didn't find the device */
 -  err = -ENODEV;
 +  }
>>>
>>> Should devices with pciback override be displayed in
>>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>>> either added to pcistub_device_ids or kept on some other list.
>>
>> No, I don't think so. The patch is just needed to _avoid_ having to use
>> the slots stuff: without the patch you need something like:
>>
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> while with the patch you can use the same mechanism as for similar
>> drivers like pci-stub and vfio-pci:
>>
>> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> So e.g. libvirt doesn't need special handling for pciback. The slot list
>> is necessary for assigning devices to pciback on boot, but I think the
>> override mechanism is better for runtime assignment.
> 
> Can you include something like this in the commit message?

Okay.


Juergen

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

Re: [Xen-devel] [PATCH v4 6/9] livepatch: Add parsing for the symbol+0x

[Ross Lagerwall]

On 09/08/2016 10:22 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Sep 07, 2016 at 02:10:43AM -0600, Jan Beulich wrote:

On 06.09.16 at 21:56,  wrote:

On Wed, Aug 24, 2016 at 03:08:01AM -0600, Jan Beulich wrote:

On 24.08.16 at 04:22,  wrote:

--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -237,13 +237,34 @@ static const char *livepatch_symbols_lookup(unsigned long 
addr,
 static int resolve_old_address(struct livepatch_func *f,
const struct livepatch_elf *elf)
 {
+const char *s;
+char *plus = NULL;


Pointless initializer.


We need that otherwise this part (which is at the bottom of this function):

if ( plus )
{
*plus = '+';
f->old_addr += offset;
}


May be invoked for symbols that that don't have the '+' in them.


I don't see how it would. This

plus = strchr(f->name, '+');

comes ahead of any paths leading to the code you quote.


Ah. Stale information - the earlier patch had 'slash' and 'plus' variables
to look for - and that was why I needed it.

But with the code you are quoting - it is not needed.



+/* + */
+plus = strchr(f->name, '+');


And I think you should prefer using the local variable here.






Furthermore you're losing const here - does f->name really point
to memory that doesn't get mapped r/o?


Yes.

The 'struct livepatch_func' contains the the ->opaque array of 31 bytes
(from which we use 5 bytes) which the hypervisor uses to stash the original
instructions.


How does the patch name end up in (5 bytes of) the opaque field?


I was (ineptly) saying that the struct livepatch_func has fields that are
modified, hence it ends up in .data section.

Wait a minute. The f->name should have a relocation to point to .rodata
instead of .data! And that should have crashed when I modified it.



livepatch-build-tools puts the function names in a read only section 
(.livepatch.strings), so the approach of fiddling with f->name probably 
needs to change.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[David Vrabel]

On 09/09/16 07:14, Juergen Gross wrote:
> On 08/09/16 16:10, Boris Ostrovsky wrote:
>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
>>> Support the driver_override scheme introduced with commit 782a985d7af2
>>> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>>>
>>> As pcistub_probe() is called for all devices (it has to check for a
>>> match based on the slot address rather than device type) it has to
>>> check for driver_override set to "pciback" itself.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> V2: removed now unused label
>>> ---
>>>  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
>>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>>> b/drivers/xen/xen-pciback/pci_stub.c
>>> index 258b7c3..85c28f7 100644
>>> --- a/drivers/xen/xen-pciback/pci_stub.c
>>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>>> @@ -25,6 +25,8 @@
>>>  #include "conf_space.h"
>>>  #include "conf_space_quirks.h"
>>>  
>>> +#define PCISTUB_DRIVER_NAME "pciback"
>>> +
>>>  static char *pci_devs_to_hide;
>>>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>>>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
>>> @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
>>> struct pci_device_id *id)
>>> "don't have a normal (0) or bridge (1) "
>>> "header type!\n");
>>> err = -ENODEV;
>>> -   goto out;
>>> }
>>>  
>>> +   } else if (!dev->driver_override ||
>>> +  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
>>> +   /* Didn't find the device */
>>> +   err = -ENODEV;
>>> +
>>> +   if (!err) {
>>> dev_info(&dev->dev, "seizing device\n");
>>> err = pcistub_seize(dev);
>>> -   } else
>>> -   /* Didn't find the device */
>>> -   err = -ENODEV;
>>> +   }
>>
>> Should devices with pciback override be displayed in
>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>> either added to pcistub_device_ids or kept on some other list.
> 
> No, I don't think so. The patch is just needed to _avoid_ having to use
> the slots stuff: without the patch you need something like:
> 
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> while with the patch you can use the same mechanism as for similar
> drivers like pci-stub and vfio-pci:
> 
> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> So e.g. libvirt doesn't need special handling for pciback. The slot list
> is necessary for assigning devices to pciback on boot, but I think the
> override mechanism is better for runtime assignment.

Can you include something like this in the commit message?

David

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

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[Boris Ostrovsky]

On 09/09/2016 02:14 AM, Juergen Gross wrote:
> On 08/09/16 16:10, Boris Ostrovsky wrote:
>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
>>> Support the driver_override scheme introduced with commit 782a985d7af2
>>> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>>>
>>> As pcistub_probe() is called for all devices (it has to check for a
>>> match based on the slot address rather than device type) it has to
>>> check for driver_override set to "pciback" itself.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> V2: removed now unused label
>>> ---
>>>  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
>>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>>> b/drivers/xen/xen-pciback/pci_stub.c
>>> index 258b7c3..85c28f7 100644
>>> --- a/drivers/xen/xen-pciback/pci_stub.c
>>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>>> @@ -25,6 +25,8 @@
>>>  #include "conf_space.h"
>>>  #include "conf_space_quirks.h"
>>>  
>>> +#define PCISTUB_DRIVER_NAME "pciback"
>>> +
>>>  static char *pci_devs_to_hide;
>>>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>>>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
>>> @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
>>> struct pci_device_id *id)
>>> "don't have a normal (0) or bridge (1) "
>>> "header type!\n");
>>> err = -ENODEV;
>>> -   goto out;
>>> }
>>>  
>>> +   } else if (!dev->driver_override ||
>>> +  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
>>> +   /* Didn't find the device */
>>> +   err = -ENODEV;
>>> +
>>> +   if (!err) {
>>> dev_info(&dev->dev, "seizing device\n");
>>> err = pcistub_seize(dev);
>>> -   } else
>>> -   /* Didn't find the device */
>>> -   err = -ENODEV;
>>> +   }
>> Should devices with pciback override be displayed in
>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>> either added to pcistub_device_ids or kept on some other list.
> No, I don't think so. The patch is just needed to _avoid_ having to use
> the slots stuff: without the patch you need something like:
>
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo :07:10.0 > /sys/bus/pci/drivers_probe
>
> while with the patch you can use the same mechanism as for similar
> drivers like pci-stub and vfio-pci:
>
> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers_probe
>
> So e.g. libvirt doesn't need special handling for pciback. The slot list
> is necessary for assigning devices to pciback on boot, but I think the
> override mechanism is better for runtime assignment.

I am not arguing against override mechanism.

My point is that people/tools may rely on the fact devices are always
listed in slots file. For example, libxl_pci.c parses at this file (I
haven't look at this code in details so perhaps it's only when checking
for devices assigned at boot time).


>
>> Also, do you think checking override might better be done first, before
>> testing for ID match?
> Why? I don't think this really matters.

It may provide (probably very slight) performance improvement when you
have lots of assigned devices.

-boris



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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v3 13/19] acpi: Makefile should better 
tolerate interrupts"):
> On 09/09/2016 09:29 AM, Jan Beulich wrote:
> > Then my suggestion of using relative paths would still help?
> 
> Apparently it doesn't like any dots:
...
> [root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc
> /tmp/dsdt_anycpu.asl &>/dev/null
> [root@ovs104 foo]# ls -aR /tmp/root/
> /tmp/root/:
> .  ..  bar  foo
> 
> /tmp/root/bar:
> .  ..
> 
> /tmp/root/foo:
> .  ..  ..aml  ..hex
> [root@ovs104 foo]#

This seems to suggest that it looks for the last dot, not the first
one.

If you provide a filename which has an "extension", as it seems to
expect, does it DTRT ?

Ian.

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

Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted

[Ross Lagerwall]

On 09/09/2016 02:50 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 09, 2016 at 02:33:18PM +0100, Ross Lagerwall wrote:

On 08/24/2016 03:22 AM, Konrad Rzeszutek Wilk wrote:

So that when we apply the patch again the .bss is cleared.
Otherwise we may find some variables containing old values.

The payloads may contain various .bss - especially if -fdata-sections
is used which can create .bss. sections.



After having thought about this again, I'm not sure it makes much sense. Any
data sections in the payload are not reset to their initial values, so
resetting the bss only may result in an unexpected combination of new & old
data/bss.


Regardless of that I think clearing the .bss upon applying the livepatch is
still the right thing to do.

Regarding of the .data - we could have a copy of the .data the first time
we load - and then during application copy over it from the original one?.



Perhaps it just needs to be documented that a payload's bss/data is
untouched across revert/apply?


It really cuts down on bugs if we clear the .bss. It is kind of ingrained in 
every
developer that the .bss is zero-ed out at startup.




Sure.

IMO clearing one but not resetting the other is even more unexpected. 
However, if we agree that it is desirable to do both, then this patch is 
acceptable as a step in the right direction.


--
Ross Lagerwall

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

[Xen-devel] [xen-4.5-testing test] 100828: tolerable FAIL - PUSHED

[osstest service owner]

flight 100828 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100828/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  11 guest-start  fail in 100814 pass in 100828
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
100814 pass in 100828
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 100814

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 100769
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 100769
 test-armhf-armhf-xl-rtds 11 guest-start fail in 100814 like 100769
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 100769
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100769
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100769
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  433ebca120e8750eb8085745ccac703e47358e6f
baseline version:
 xen  d50078b9f2d7df55157ca353d889b13a8f3f0bc6

Last test of basis   100769  2016-09-06 13:09:38 Z3 days
Testing same since   100814  2016-09-08 12:43:18 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fa

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/09/2016 09:50 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v3 18/19] libxl/acpi: Build ACPI tables 
> for HVMlite guests"):
>> On 09/09/2016 04:05 AM, Jan Beulich wrote:
>>> struct libxl_acpi_ctxt {
>>> struct acpi_ctxt ctxt;
>>> ...
>>> };
>>>
>>> though, together with whatever equivalent to container_of() exists
>>> in libxl.
>> Yes, this is better. I don't see it defined in libxl but I can define
>> one myself.
> It's called CONTAINER_OF.  See tools/libxl/CODING_STYLE, and/or the
> output of something like `git grep -i contain tools/libxl'.

Ah, thanks. I haven't thought of running git grep.

-boris

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/09/2016 09:29 AM, Jan Beulich wrote:
 On 09.09.16 at 15:07,  wrote:
>> On 09/09/2016 04:03 AM, Jan Beulich wrote:
>> On 08.09.16 at 20:51,  wrote:
 On 09/08/2016 10:15 AM, Jan Beulich wrote:
 On 07.09.16 at 20:59,  wrote:
>>  vpath iasl $(PATH)
>>  all: $(C_SRC) $(H_SRC)
>> +rm -fr $(TDIR)
> And how is the temporary directory going to get cleaned up when
> interrupting make? I think you really should use a subdirectory
> underneath the build directory, which then can stay there until
> "make clean". And then you can also use mv instead of cp below,
> or even move-if-changed.
 The reason I am doing this in /tmp and use tmp_X as template is
 because I found that at least one old versions of iasl has a bug where
 it can't process path that has a '.' in it. It drops anything after the
 dot, presumably because it thinks it's file suffix.
>>> That . is a leading one, as in ./path/file.ext? If so, why can't this be
>>> made path/file.ext? The leading ./ shouldn't be necessary after all.
>> No, not a leading one. Inside a name:
>>
>> Expected:
>>
>> [root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
>> [root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
> Then my suggestion of using relative paths would still help?

Apparently it doesn't like any dots:

[root@ovs104 /]# mkdir -p /tmp/root/foo
[root@ovs104 /]# mkdir -p /tmp/root/bar
[root@ovs104 /]# cd /tmp/root/foo/
[root@ovs104 foo]# ls -aR /tmp/root/
/tmp/root/:
.  ..  bar  foo

/tmp/root/bar:
.  ..

/tmp/root/foo:
.  ..
[root@ovs104 foo]# ~/iasl.f12 -vs -p "../bar/dsdt_anycpu" -tc
/tmp/dsdt_anycpu.asl &>/dev/null
[root@ovs104 foo]# ls -aR /tmp/root/
/tmp/root/:
.  ..  bar  foo

/tmp/root/bar:
.  ..

/tmp/root/foo:
.  ..  ..aml  ..hex
[root@ovs104 foo]#


-boris

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

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v3 18/19] libxl/acpi: Build ACPI tables for 
HVMlite guests"):
> On 09/09/2016 04:05 AM, Jan Beulich wrote:
> > struct libxl_acpi_ctxt {
> > struct acpi_ctxt ctxt;
> > ...
> > };
> >
> > though, together with whatever equivalent to container_of() exists
> > in libxl.
> 
> Yes, this is better. I don't see it defined in libxl but I can define
> one myself.

It's called CONTAINER_OF.  See tools/libxl/CODING_STYLE, and/or the
output of something like `git grep -i contain tools/libxl'.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted

[Konrad Rzeszutek Wilk]

On Fri, Sep 09, 2016 at 02:33:18PM +0100, Ross Lagerwall wrote:
> On 08/24/2016 03:22 AM, Konrad Rzeszutek Wilk wrote:
> > So that when we apply the patch again the .bss is cleared.
> > Otherwise we may find some variables containing old values.
> > 
> > The payloads may contain various .bss - especially if -fdata-sections
> > is used which can create .bss. sections.
> > 
> 
> After having thought about this again, I'm not sure it makes much sense. Any
> data sections in the payload are not reset to their initial values, so
> resetting the bss only may result in an unexpected combination of new & old
> data/bss.

Regardless of that I think clearing the .bss upon applying the livepatch is
still the right thing to do.

Regarding of the .data - we could have a copy of the .data the first time
we load - and then during application copy over it from the original one?.

> 
> Perhaps it just needs to be documented that a payload's bss/data is
> untouched across revert/apply?

It really cuts down on bugs if we clear the .bss. It is kind of ingrained in 
every
developer that the .bss is zero-ed out at startup.
> 
> -- 
> Ross Lagerwall

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

Re: [Xen-devel] [PATCH v4 8/9] symbols: Generate an xen-sym.map

[Ross Lagerwall]

On 08/24/2016 03:22 AM, Konrad Rzeszutek Wilk wrote:

You could construct _most_ of the names of the functions
by doing 'nm --defined' but unfortunatly you do not get the
 prefix that is added on in Xen . For example:

$ cat xen-syms.symbols |grep do_domain_pause
0x82d080104920 t domain.c#do_domain_pause
$ nm --defined xen-syms|grep do_domain_pause
82d080104920 t do_domain_pause

This is normally not an issue, but if one is doing livepatching and
wants during build-time verify that the symbols the livepatch payloads
will patch do correspond to the one the hypervisor has built - this helps a lot.

Note that during runtime one can do:
[root@localhost xen]# cat /proc/xen/xensyms |grep do_domain_pause
82d080104920 t domain.c#do_domain_pause

But one may not want to build and verify a livepatch on the same host.

Signed-off-by: Konrad Rzeszutek Wilk 
---


Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> Small packet loss is reported on complex multi host network configurations
> including tunnels, NAT, ... My investigation led me to the following check
> in netback which drops packets:
> 
> if (unlikely(txreq.size < ETH_HLEN)) {
> netdev_err(queue->vif->dev,
>"Bad packet size: %d\n", txreq.size);
> xenvif_tx_err(queue, &txreq, extra_count, idx);
> break;
> }
> 
> But this check itself is legitimate. SKBs consist of a linear part (which
> has to have the ethernet header) and (optionally) a number of frags.
> Netfront transmits the head of the linear part up to the page boundary
> as the first request and all the rest becomes frags so when we're
> reconstructing the SKB in netback we can't distinguish between original
> frags and the 'tail' of the linear part. The first SKB needs to be at
> least ETH_HLEN size. So in case we have an SKB with its linear part
> starting too close to the page boundary the packet is lost.
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.
> - Avoid transmitting SKBs with linear parts starting too close to the page
>   boundary. That seems preferable short-term and shouldn't bring
>   significant performance degradation as such packets are rare. That's what
>   this patch is trying to achieve with skb_copy().
> 
> Signed-off-by: Vitaly Kuznetsov 

We should probably fix the backend to handle this (by grant copying a
minimum amount in the linear area, but since netfront needs to work with
older netback.

Acked-by: David Vrabel 

David

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

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[Vitaly Kuznetsov]

Vitaly Kuznetsov  writes:

> Vitaly Kuznetsov  writes:
>
>> David Vrabel  writes:
>>
>>> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
 
 I see two ways to fix the issue:
 - Change the 'wire' protocol between netfront and netback to start keeping
   the original SKB structure. We'll have to add a flag indicating the fact
   that the particular request is a part of the original linear part and not
   a frag. We'll need to know the length of the linear part to pre-allocate
   memory.
>>>
>>> I don't think there needs to be a protocol change.  I think the check in
>>> netback is bogus -- it's the total packet length that must be >
>>> HLEN_ETH.  The upper layers will pull any headers from the frags as
>>> needed
>>
>> I'm afraid this is not always true, just removing the check leads us to
>> the following:
>>
>> [  495.442186] kernel BUG at ./include/linux/skbuff.h:1927! 
>> [  495.468789] invalid opcode:  [#1] SMP 
>
> What I wanted to say here is that this test makes me think the
> description of the patch I suggested is correct: an SKB can't have its
> linear part shorter than ETH_HLEN as the header is being pointed directly,
> upper network layers don't assemble it from frags, the check in netback
> is valid.
>
> So, how can we proceed here?

Sorry for the second ping but I'd really like to see this moving
forward...

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH v4 4/9] version: Print build-id at bootup.

[Ross Lagerwall]

On 09/06/2016 05:57 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Aug 24, 2016 at 02:58:48AM -0600, Jan Beulich wrote:

On 24.08.16 at 04:22,  wrote:

Livepatch expected at some point to be able to print the
build-id during bootup, which it did not.  The reason is
that xen_build_init and livepatch_init are both __initcall
type routines. This meant that when livepatch_init called
xen_build_id, it would return -ENODATA as build_id_len was
not setup yet (b/c xen_build_init would be called later).

The original patch fixed this by calling xen_build_init in
livepatch_init which allows us to print the build-id of
the hypervisor.

However the x86 maintainers pointed out that build-id
is independent of Livepatch and in fact should print
regardless whether Livepatch is enabled or not.

Therefore this patch moves the logic of printing the build-id
to version.c.

Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Jan Beulich 


Thank you.

I had a slight change due to rebasing on "x86/EFI: use less crude a way of 
generating the build"
which was quite simple to fix so I retained your Reviewed-by tag.

The final patch looks as so:

From 927c9accac9a49b586f616060e5567d7b03e3e77 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 6 Sep 2016 12:18:10 -0400
Subject: [PATCH] version: Print build-id at bootup.

Livepatch expected at some point to be able to print the
build-id during bootup, which it did not.  The reason is
that xen_build_init and livepatch_init are both __initcall
type routines. This meant that when livepatch_init called
xen_build_id, it would return -ENODATA as build_id_len was
not setup yet (b/c xen_build_init would be called later).

The original patch fixed this by calling xen_build_init in
livepatch_init which allows us to print the build-id of
the hypervisor.

However the x86 maintainers pointed out that build-id
is independent of Livepatch and in fact should print
regardless whether Livepatch is enabled or not.

Therefore this patch moves the logic of printing the build-id
to version.c.

Reviewed-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 



Reviewed-by: Ross Lagerwall 

--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted

[Ross Lagerwall]

On 08/24/2016 03:22 AM, Konrad Rzeszutek Wilk wrote:

So that when we apply the patch again the .bss is cleared.
Otherwise we may find some variables containing old values.

The payloads may contain various .bss - especially if -fdata-sections
is used which can create .bss. sections.



After having thought about this again, I'm not sure it makes much sense. 
Any data sections in the payload are not reset to their initial values, 
so resetting the bss only may result in an unexpected combination of new 
& old data/bss.


Perhaps it just needs to be documented that a payload's bss/data is 
untouched across revert/apply?


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Jan Beulich]

>>> On 09.09.16 at 15:07,  wrote:
> On 09/09/2016 04:03 AM, Jan Beulich wrote:
> On 08.09.16 at 20:51,  wrote:
>>> On 09/08/2016 10:15 AM, Jan Beulich wrote:
>>> On 07.09.16 at 20:59,  wrote:
>  vpath iasl $(PATH)
>  all: $(C_SRC) $(H_SRC)
> + rm -fr $(TDIR)
 And how is the temporary directory going to get cleaned up when
 interrupting make? I think you really should use a subdirectory
 underneath the build directory, which then can stay there until
 "make clean". And then you can also use mv instead of cp below,
 or even move-if-changed.
>>> The reason I am doing this in /tmp and use tmp_X as template is
>>> because I found that at least one old versions of iasl has a bug where
>>> it can't process path that has a '.' in it. It drops anything after the
>>> dot, presumably because it thinks it's file suffix.
>> That . is a leading one, as in ./path/file.ext? If so, why can't this be
>> made path/file.ext? The leading ./ shouldn't be necessary after all.
> 
> No, not a leading one. Inside a name:
> 
> Expected:
> 
> [root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
> [root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc

Then my suggestion of using relative paths would still help?

>>  (And btw., thinking about it again I don't see the need for a
>> subdirectory. We have ample room to name the intermediate files
>> suitably without causing any name collision.)
> 
> That, in fact, is what I initially had --- I just added an extra temp
> suffix to intermediate files during a build. And right before sending
> the series I figured I'd give it a spin on our build server. Big mistake!

Big mistake? You leave me curious, but unable guess.

Jan


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

Re: [Xen-devel] [PATCH V2] xen/arm: arm64: Update the Image header

[Julien Grall]

Hello Peng,

On 01/09/16 02:38, Peng Fan wrote:

This patch is mainly modified from Linux kernel:
[1] commit a2c1d73b94ed: arm64: Update the Image header
[2] commit 6ad1fe5d9077: arm64: avoid R_AARCH64_ABS64 relocations for Image 
header fields

From [1]:
"
This patch adds an effective image size to the kernel header which
describes the amount of memory from the start of the kernel Image binary
which the kernel expects to use before detecting memory and handling any
memory reservations. This can be used by bootloaders to choose suitable
locations to load the kernel and/or other binaries such that the kernel
will not clobber any memory unexpectedly. As before, memory reservations
are required to prevent the kernel from clobbering these locations
later.

Both the image load offset and the effective image size are forced to be
little-endian regardless of the native endianness of the kernel to
enable bootloaders to load a kernel of arbitrary endianness. Bootloaders
which wish to make use of the load offset can inspect the effective
image size field for a non-zero value to determine if the offset is of a
known endianness. To enable software to determine the endinanness of the
kernel as may be required for certain use-cases, a new flags field (also
little-endian) is added to the kernel header to export this information.
"

In this patch, XEN_VIRT_START is used as the text offset. Then, bootloader,
such as U-Boot, will load the xen image to "dram_base + text_offset".
Not choose 0 as the text offset, because we may have spin table at dram_base.
Loading xen to dram_base will override the spin table.


XEN_VIRT_START is *not* the text offset. It is the virtual address mark 
the start of Xen region when paging is enabled.


Furthermore, your description here does not match the behavior of this 
patch. The kernel physical displacement is set to 1, this means the 
kernel will be loaded anywhere in the memory.


It is the job of the bootloader to find an unused place to load Xen into 
the memory.




Introduce image.h and macros.h in this patch, just as Linux kernel.

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

V2: Addressing Julien's comments to follow linux kernel patch:
a2c1d73b94ed49 "arm64: Update the Image header"


Whilst I suggested to update all the header fields (image load offset, 
effective size, flags...), I don't think we should import a "verbatim" 
of the Linux header image.h. It is really complex for a questionable 
benefit.




 xen/arch/arm/arm64/head.S  |  7 +++--
 xen/arch/arm/xen.lds.S |  5 +++
 xen/include/asm-arm/arm64/image.h  | 62 ++
 xen/include/asm-arm/arm64/macros.h | 15 +
 xen/include/asm-arm/macros.h   |  2 +-
 5 files changed, 87 insertions(+), 4 deletions(-)
 create mode 100644 xen/include/asm-arm/arm64/image.h
 create mode 100644 xen/include/asm-arm/arm64/macros.h

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 91e2817..0226463 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -21,6 +21,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,9 +115,9 @@ efi_head:
  */
 add x13, x18, #0x16
 b   real_start   /* branch to kernel start */
-.quad   0/* Image load offset from start of RAM */
-.quad   0/* reserved */
-.quad   0/* reserved */
+le64sym _xen_offset_le   /* Image load offset from start of RAM, 
little-endian */
+le64sym _xen_size_le /* Effective size of kernel image, 
little-endian */
+le64sym _xen_flags_le/* Informative flags, little-endian */
 .quad   0/* reserved */
 .quad   0/* reserved */
 .quad   0/* reserved */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index b24e93b..854c243 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 


Please don't include arm64 specific header in common code.


 #undef ENTRY
 #undef ALIGN

@@ -196,6 +197,10 @@ SECTIONS
   .dtb : { *(.dtb) } :text
 #endif

+#if defined(__aarch64__)
+  HEAD_SYMBOLS
+#endif
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/include/asm-arm/arm64/image.h 
b/xen/include/asm-arm/arm64/image.h
new file mode 100644
index 000..54751ca
--- /dev/null
+++ b/xen/include/asm-arm/arm64/image.h
@@ -0,0 +1,62 @@
+/*
+ * Copied and modified from Linux
+ * "commit 29b4817d4018df78086157ea3a55c1d9424a7cfc"
+ *
+ * Linker script macros to generate Image header fields.
+ *
+ * Copyright (C) 2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Founda

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/09/2016 04:05 AM, Jan Beulich wrote:
 On 08.09.16 at 20:53,  wrote:
>> On 09/08/2016 10:20 AM, Jan Beulich wrote:
 --- a/tools/libacpi/libacpi.h
 +++ b/tools/libacpi/libacpi.h
 @@ -48,6 +48,15 @@ struct acpi_ctxt {
  void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
  unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
  } mem_ops;
 +
 +unsigned int page_size;
 +unsigned int page_shift;
 +
 +/* Memory allocator */
 +unsigned long alloc_base_paddr;
 +unsigned long alloc_base_vaddr;
 +unsigned long alloc_currp;
 +unsigned long alloc_end;
  };
>>> There not being (or getting added) any users of these in libacpi/, I
>>> wonder how this is related to the subject of the patch. If this is
>>> data that only libxl needs for its own purposes, then surely this
>>> shouldn't get added to struct acpi_ctxt, but should be a libxl
>>> private extension of that structure.
>> struct acpi_ctxt {
>> ...
>>
>> void *private;
>> };
>>
>> ?
> That's one option; I'd prefer
>
> struct libxl_acpi_ctxt {
> struct acpi_ctxt ctxt;
> ...
> };
>
> though, together with whatever equivalent to container_of() exists
> in libxl.

Yes, this is better. I don't see it defined in libxl but I can define
one myself.

-boris


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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/09/2016 04:03 AM, Jan Beulich wrote:
 On 08.09.16 at 20:51,  wrote:
>> On 09/08/2016 10:15 AM, Jan Beulich wrote:
>> On 07.09.16 at 20:59,  wrote:
 --- a/tools/libacpi/Makefile
 +++ b/tools/libacpi/Makefile
 @@ -21,38 +21,45 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
>> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
>> ssdt_tpm.h)
  
 +ifeq ($(subst all,,$(MAKECMDGOALS)),)
 +TDIR := $(shell mktemp -d --tmpdir=$(TMPDIR) tmp_XX)
 +endif
>>> How is this (or really the rules using this directory) supposed to work
>>> when other than "all" gets built?
>>
>> I realize it's a somewhat weak argument but only 'all' and 'clean'
>> targets are supposed to be used. In fact I was thinking about explicitly
>> making a check for targets.
> Hmm, that would be quite limiting in case one wants to analyze a
> problem with just a single build step. (On the hypervisor side I,
> every once in a while, find it helpful to be able to compile individual
> files into .o, or even produce the intermediate .i or .s.)

Yes.

I tried to figure out a way for Makefile to always execute a rule when
before it exits but didn't find anything. You can do it as a *first*
rule (with "-include ") but not as a final one.

My only defense here (again, pretty weak) is that making libacpi 'all'
target is pretty fast.

>
  vpath iasl $(PATH)
  all: $(C_SRC) $(H_SRC)
 +  rm -fr $(TDIR)
>>> And how is the temporary directory going to get cleaned up when
>>> interrupting make? I think you really should use a subdirectory
>>> underneath the build directory, which then can stay there until
>>> "make clean". And then you can also use mv instead of cp below,
>>> or even move-if-changed.
>> The reason I am doing this in /tmp and use tmp_X as template is
>> because I found that at least one old versions of iasl has a bug where
>> it can't process path that has a '.' in it. It drops anything after the
>> dot, presumably because it thinks it's file suffix.
> That . is a leading one, as in ./path/file.ext? If so, why can't this be
> made path/file.ext? The leading ./ shouldn't be necessary after all.

No, not a leading one. Inside a name:

Expected:

[root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
[root@ovs104 libacpi]# iasl -vs -p /tmp/root/xen.git/dsdt_anycpu -tc
/tmp/dsdt_anycpu.asl &>/dev/null
[root@ovs104 libacpi]# ls -R /tmp/root/
/tmp/root/:
xen.git

/tmp/root/xen.git:
dsdt_anycpu.aml  dsdt_anycpu.hex
[root@ovs104 libacpi]#


Fedora 12:

[root@ovs104 libacpi]# mkdir -p /tmp/root/xen.git
[root@ovs104 libacpi]# ~/iasl.f12 -vs -p /tmp/root/xen.git/dsdt_anycpu
-tc /tmp/dsdt_anycpu.asl &>/dev/null
[root@ovs104 libacpi]# ls -R /tmp/root/
/tmp/root/:
xen.aml  xen.git  xen.hex

/tmp/root/xen.git:
[root@ovs104 libacpi]#

I tried escaping the dot, putting path in quotes, etc. but without any
success.

>
> Also this part of your answer doesn't address the cleanup aspect at
> all.

Again, not the greatest way to deal with this, but we will leave temp
directory in /tmp on interrupts. (And on error I could have added an
error handling target but decided not to do that so that it's easier to
debug the error).


>  (And btw., thinking about it again I don't see the need for a
> subdirectory. We have ample room to name the intermediate files
> suitably without causing any name collision.)

That, in fact, is what I initially had --- I just added an extra temp
suffix to intermediate files during a build. And right before sending
the series I figured I'd give it a spin on our build server. Big mistake!

So I agree that this is not the best solution but I haven't come up with
anything better.

-boris


>
>> This is true on fedora12 (2009), which is what we still use as build
>> environment. I know that fedora 18 doesn't have this problem but I don't
>> know at which point this got fixed. (Interestingly enough, I tried to
>> build from F12's sources for iasl and could not reproduce this. Now, i
>> built with new tools so perhaps the bug is not in iasl itself but in
>> something like yacc, which is used for the build).
>>
>> I don't think we have any requirement on supported iasl version so I am
>> not sure we can ignore this error.
> I agree.
>
> Jan
>



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

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Paulina Szubarczyk]

On 09/08/2016 12:00 AM, Paulina Szubarczyk wrote:


On 09/07/2016 10:56 PM, Stefano Stabellini wrote:

On Wed, 7 Sep 2016, Paulina Szubarczyk wrote:

Copy data operated on during request from/to local buffers to/from
the grant references.

Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.

A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.

Signed-off-by: Paulina Szubarczyk 
---
Changes since v5:
-added checking of every interface in the configure file. Based on
  the Roger's comment that xengnttab_map_grant_ref was added prior
  xengnttab_grant_copy, thus do not need to be check again here
  I dropped this check.



Thank you Paulina, the patch is good. Thanks for your work! Sorry for
coming in late in the review; I have a couple of minor suggestions
below.


It had not been possible without all the help I have got. I am very
grateful for it.


In addition to Anthony's ack, it would be also nice to have Roger's ack
on this patch.

Roger, will you need more time to take a look at the patch or may I send 
a new version with applied Stefano comments?





  configure   |  55 
  hw/block/xen_disk.c | 157
++--
  include/hw/xen/xen_common.h |  14 
  3 files changed, 221 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 4b808f9..3f44d38 100755
--- a/configure
+++ b/configure
@@ -1956,6 +1956,61 @@ EOF
  /*
   * If we have stable libs the we don't want the libxc compat
   * layers, regardless of what CFLAGS we may have been given.
+ *
+ * Also, check if xengnttab_grant_copy_segment_t is defined and
+ * grant copy operation is implemented.
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+  xen_domain_handle_t handle;
+  xengnttab_grant_copy_segment_t* seg = NULL;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC,
NULL);
+  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_grant_copy(xg, 0, seg);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+then
+xen_ctrl_version=480
+xen=yes
+  elif
+  cat > $TMPC <= 480


In general I prefer to avoid this kind of #ifdef in xen_disk.c, but I
see that Anthony suggested it for a good reason. The only alternartive I
can think of would be to introduce two static inline functions in
xen_common.h to set a xengnttab_grant_copy_segment_t seg. But this is
also OK.


The functions take as parameters pointers to struct ioreq defined in
xen_disk.c which members are used to fill the
xengnttab_grant_copy_segment_t. There would be some overhead to move the
functions to the header.



+static void free_buffers(struct ioreq *ioreq)


Please name this function ioreq_free_copy_buffers to make it clearer
that has to do with the same buffers initialized below.



+{
+int i;
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = NULL;
+}
+
+qemu_vfree(ioreq->pages);
+}
+
+static int ioreq_init_copy_buffers(struct ioreq *ioreq)
+{
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov *
XC_PAGE_SIZE);
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
+ioreq->v.iov[i].iov_base = ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_copy(struct ioreq *ioreq)


Please name this function in a way that makes it clear that it has
something to do with grant copies. Like for example ioreq_grant_copy.


I will change the names of both functions and remove the blank line
pointed below.



+{
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_grant_copy_segment_t
segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count, rc;
+int64_t file_blk = ioreq->blkdev->file_blk;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = iore

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth]

On 16/08/2016 06:32, "Tim Deegan"  wrote:

>Hi,
>
>At 14:55 + on 15 Aug (1471272946), Lars Kurth wrote:
>> But I see your point. The text should really have said something like...
>> -
>> In situations where the entire Xen Project community becomes paralysed,
>> the project leaderships team or project lead should work with the
>> community 
>> manager or advisory board to find a way forward.
>> -
>
>Sure.  I think that's good.
>
>> I think we have two options:
>> A) A delete this bullet entirely
>> B) Replace it with something clearer - even though, the location
>> for such a paragraph is wrong.
>> 
>> My gut feel is to just go for A.
>
>Sounds good to me.

Having looked at the text again (making edits for v2), I propose to add
the following
new section to the document.

-

-   [Community Decisions with Funding and Legal
implications](#funding-and-legal)

...


Community Decisions with Funding and Legal Implications
(#funding-and-legal)
---

In some cases sub-project local and global decisions **may require
input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
(#roles-lf). For example, if a proposal by a project leadership team or
a global project decision requires that the project hires a staff member
or 
contractor (e.g. a PR consultant, marketing manager) or requires the
funding 
of new infrastructure (e.g. additional test hardware or services) to
implement 
said proposal, then funding would need to be secured from the Advisory
Board or 
from other sources.

If for example, a community proposal required the Linux Foundation to sign
a legal agreement with a 3rd party on behalf of the project/sub-project,
then 
of course a review of such an agreement and a signature by the Linux
Foundation 
would be required. 

In such cases, the impacted project leadership team(s) will contact the
Community Manager and/or Advisory Board to resolve possible issues.


-

I don't think this is in fact a change in governance. It is just clarifying


what has happened in the past. I merely wanted to highlight that in some
cases there are dependencies. We have not had any global changes, where
this
was the case, but we had a few local ones.

E.g.
- Windows driver signing required buying a cert and an agreement between
the 
  LF and Microsoft to deliver signed windows drivers
- The way how we make hypervisor releases requires to operate OSSTEST
  (aka. COLO agreements, procurement of HW, technical support, ...) which
  also required the LF to sign contracts on behalf of the project.

I hope that is OK

Best Regards
Lars

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu59351d9b40b1de0fb77e1ff3e53faa04c995c707
baseline version:
 qemuu7faae0b36e51ffdb17d4716ddc40dcfa682d93d9

Last test of basis   100809  2016-09-08 10:13:09 Z1 days
Testing same since   100825  2016-09-08 18:47:59 Z0 days1 attempts


People who touched revisions under test:
  Aneesh Kumar K.V 
  Benjamin Herrenschmidt 
  Cédric Le Goater 
  David Gibson 
  Greg Kurz 
  Laurent Vivier 
  Nikunj A Dadhania 
  Peter Maydell 
  Sandipan Das 
  Swapnil Bokade 
  Thomas Huth 
  Vivek Andrew Sha 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 27733778fc6a855e0dfde2071f011f3d7b394867
baseline version:
 ovmf d74135cd0f8d00d2126df0b4db54938c96456db6

Last test of basis67675  2016-09-08 16:16:16 Z0 days
Testing same since67681  2016-09-09 06:50:22 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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



sg-report-flight on osstest.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 27733778fc6a855e0dfde2071f011f3d7b394867
Author: Jiewen Yao 
Date:   Wed Sep 7 09:19:45 2016 +0800

Maintainers.txt: Add Giri as IntelFsp2*Pkg, IntelSiliconPkg maintainer

Add Giri as 2nd maintainer to IntelFsp2*Pkg and IntelSiliconPkg.

Cc: Giri P Mudusuru 
Cc: Amy Chan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Giri P Mudusuru 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 100773
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 100773

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 100803 pass 
in 100819
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 100803

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-bootfail in 100803 like 100766
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100773
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100773
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100773
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100773
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100773

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

version targeted for testing:
 xen  3d20a6f4faf1c6a18b51b80d99d23daa7762dda2
baseline version:
 xen  343f84be135e6f9e681960a9e235296eae159fc8

Last test of basis   100773  2016-09-06 13:13:28 Z2 days
Failing since100789  2016-09-07 09:36:36 Z2 days3 attempts
Testing same since   100803  2016-09-08 05:36:29 Z1 days2 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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

Re: [Xen-devel] [PATCH] xen/x86: Fix build with clang following c/s 4fa0105

[George Dunlap]

On 08/09/16 19:21, Andrew Cooper wrote:
> https://travis-ci.org/xen-project/xen/jobs/158494027#L2344
> 
> Clang complains:
> 
>   emulate.c:2016:14: error: comparison of unsigned enum expression < 0
>   is always false [-Werror,-Wtautological-compare]
>   if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
>~~~ ^ ~
> 
> Clang is wrong to raise a warning like this.  The signed-ness of an enum is
> implementation defined in C, and robust code must not assume the choices made
> by the compiler.
> 
> In this case, dropping the < 0 check creates a latent bug which would result
> in an array underflow when compiled with a compiler which chooses a signed
> enum.
> 
> Work around the bug by explicitly pulling seg into an unsigned integer, and
> only perform the upper bounds check.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: George Dunlap 
> ---
>  xen/arch/x86/hvm/emulate.c  | 19 +++
>  xen/arch/x86/mm/shadow/common.c |  9 +
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index e3bfda5..cc25676 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1447,13 +1447,14 @@ static int hvmemul_write_segment(
>  {
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +unsigned int idx = seg;
>  
> -if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
> +if ( idx >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
>  return X86EMUL_UNHANDLEABLE;
>  
> -hvmemul_ctxt->seg_reg[seg] = *reg;
> -__set_bit(seg, &hvmemul_ctxt->seg_reg_accessed);
> -__set_bit(seg, &hvmemul_ctxt->seg_reg_dirty);
> +hvmemul_ctxt->seg_reg[idx] = *reg;
> +__set_bit(idx, &hvmemul_ctxt->seg_reg_accessed);
> +__set_bit(idx, &hvmemul_ctxt->seg_reg_dirty);
>  
>  return X86EMUL_OKAY;
>  }
> @@ -2012,12 +2013,14 @@ struct segment_register *hvmemul_get_seg_reg(
>  enum x86_segment seg,
>  struct hvm_emulate_ctxt *hvmemul_ctxt)
>  {
> -if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
> +unsigned int idx = seg;
> +
> +if ( idx >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
>  return ERR_PTR(-X86EMUL_UNHANDLEABLE);
>  
> -if ( !__test_and_set_bit(seg, &hvmemul_ctxt->seg_reg_accessed) )
> -hvm_get_segment_register(current, seg, &hvmemul_ctxt->seg_reg[seg]);
> -return &hvmemul_ctxt->seg_reg[seg];
> +if ( !__test_and_set_bit(idx, &hvmemul_ctxt->seg_reg_accessed) )
> +hvm_get_segment_register(current, idx, &hvmemul_ctxt->seg_reg[idx]);
> +return &hvmemul_ctxt->seg_reg[idx];
>  }
>  
>  static const char *guest_x86_mode_to_str(int mode)
> diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
> index 8d6661c..21607bf 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -130,14 +130,15 @@ __initcall(shadow_audit_key_init);
>  static struct segment_register *hvm_get_seg_reg(
>  enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
>  {
> +unsigned int idx = seg;
>  struct segment_register *seg_reg;
>  
> -if ( seg < 0 || seg >= ARRAY_SIZE(sh_ctxt->seg_reg) )
> +if ( idx >= ARRAY_SIZE(sh_ctxt->seg_reg) )
>  return ERR_PTR(-X86EMUL_UNHANDLEABLE);
>  
> -seg_reg = &sh_ctxt->seg_reg[seg];
> -if ( !__test_and_set_bit(seg, &sh_ctxt->valid_seg_regs) )
> -hvm_get_segment_register(current, seg, seg_reg);
> +seg_reg = &sh_ctxt->seg_reg[idx];
> +if ( !__test_and_set_bit(idx, &sh_ctxt->valid_seg_regs) )
> +hvm_get_segment_register(current, idx, seg_reg);
>  return seg_reg;
>  }
>  
> 


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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Juergen Gross]

On 09/09/16 12:00, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
>> Add HVM usb passthrough support to libxl by using qemu's capability
>> to emulate standard USB controllers.
>>
>> A USB controller is added via qmp command to the emulated hardware
>> when a usbctrl device of type DEVICEMODEL is requested. Depending on
>> the requested speed the appropriate hardware type is selected. A host
>> USB device can then be added to the emulated USB controller via qmp
>> command.
>>
>> Removing of the devices is done via qmp commands, too.
>>
>> Signed-off-by: Juergen Gross 
> [...]
>>  
>> @@ -75,9 +131,19 @@ static int libxl__device_from_usbctrl(libxl__gc *gc, 
>> uint32_t domid,
>>  {
>>  device->backend_devid   = usbctrl->devid;
>>  device->backend_domid   = usbctrl->backend_domid;
>> -device->backend_kind= (usbctrl->type == LIBXL_USBCTRL_TYPE_PV)
>> -  ? LIBXL__DEVICE_KIND_VUSB
>> -  : LIBXL__DEVICE_KIND_QUSB;
>> +switch (usbctrl->type) {
>> +case LIBXL_USBCTRL_TYPE_PV:
>> +device->backend_kind = LIBXL__DEVICE_KIND_VUSB;
>> +break;
>> +case LIBXL_USBCTRL_TYPE_QUSB:
>> +device->backend_kind = LIBXL__DEVICE_KIND_QUSB;
>> +break;
>> +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
>> +device->backend_kind = LIBXL__DEVICE_KIND_NONE;
> 
> I'm not quite sure if I follow this. Shouldn't we need a new kind of
> backend for this?

Depends on what do you call a backend.

I'd say a backend is something which corresponds to a frontend in the
guest. As long as you don't want to call a normal hardware driver a
"frontend" we don't need a backend.

At least the "backend" (qemu, requiring no update for this) won't use
Xenstore for detecting addition/removal of devices: all is done via
explicit qmp commands issued from libxl to qemu.


Juergen

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

[Xen-devel] [distros-debian-jessie test] 67680: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-startfail like 67625

Tests which did not succeed, but are not blocking:
 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   67625

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub fail
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 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 1/3] x86: refactor psr implementation in hypervisor.

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH 1/3] x86: refactor psr implementation in 
hypervisor."):
> On 09.09.16 at 10:09,  wrote:
> > Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good name?
> 
> According to my knowledge of English this would still need to be
> "check_exceeds_cos_max", and then the check ends up being quite
> redundant.

In the hope of helping to end this subthread: I'm a native speaker of
English and Jan is right.

Ian.

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

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

On 9/9/2016 6:09 PM, Jan Beulich wrote:

On 09.09.16 at 11:56,  wrote:

On 9/9/2016 5:44 PM, Jan Beulich wrote:

On 09.09.16 at 11:24,  wrote:

On 9/9/2016 4:20 PM, Jan Beulich wrote:

On 09.09.16 at 09:24,  wrote:

On 9/9/2016 1:26 PM, Yu Zhang wrote:

On 02.09.16 at 12:47,  wrote:

@@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
if ( is_epte_valid(ept_entry) )
{
if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_is_changeable(ept_entry->sa_p2mt) &&
+ (ept_entry->sa_p2mt != p2m_ioreq_server) )
*t = p2m_is_logdirty_range(p2m, gfn, gfn) ?

p2m_ram_logdirty

  : p2m_ram_rw;
else

Considering this (and at least one more similar adjustment further
down), is it really appropriate to include p2m_ioreq_server in the
set of "changeable" types?

Well, I agree p2m_ioreq_server do have different behaviors than the
p2m_log_dirty, but removing p2m_ioreq_server from changeable type
would need more specific code for the p2m_ioreq_server in routines like
resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
I've tried this approach and abandoned later. :)

I can see that the other option might require more adjustments, in
which case I guess this variant would be fine if you created another
helper (well named) inline function instead of open coding this in
several places. Of course such dissimilar handling in the various
places p2m_is_changeable() gets used right now will additionally
require good reasoning - after all that predicate exists to express
the similarities between different code paths.

Thanks Jan.
Well, for the logic of p2m type recalculation, similarities between
p2m_ioreq_server
and other changeable types exceeds their differences. As to the special
cases, how
about we use a macro, i.e. p2m_is_ioreq?

That'd be better than the open coded check, but would still result
in (taking the above example)

   p2m_is_changeable(ept_entry->sa_p2mt) &&
   !p2m_is_ioreq(ept_entry->sa_p2mt) )

? What I'd prefer is a predicate that can be applied here on its own,
without involving && or ||.


OK. I can think of 2 scenarios that p2m_ioreq_server needs special handling:

1> In ept_get_entry()/recal_type(), the p2m types are supposed to return
as it is, instead of
changing to p2m_log_dirty. So we can use a macro or a inline function
like p2m_check_changeable(),
which combines the

   p2m_is_changeable(ept_entry->sa_p2mt) &&
   !p2m_is_ioreq(ept_entry->sa_p2mt) )

together.

2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented. We
do not need this new inline function, because they are in a separate
if() statement.

Is this OK? :)

Sounds reasonable. But please give George and others a chance to
voice their opinions before you go that route.




Sure, thanks!

Yu

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

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job 
for 4.4 onwards"):
> On Thu, Sep 08, 2016 at 06:41:26PM +0100, Ian Jackson wrote:
> > What is the deployment situation ?  See my previous emails about
> > mg-branch-setup.
> 
> I'm not sure I know what INITIAL-TESTED-VERSION does. Let's have a
> conversation IRL and I will write down something where appropriate.

mg-branch-setup is the tool which sets up an instance of the push gate
machinery.

We are creating a new push gate for xtf.  That is, there will be both
a staging branch and an osstest-tested branch.  If the osstest-tested
branch were to be missing, the push gate runs will bomb out during
flight construction.

So mg-branch-setup helpfully reminds its user (via its usage message)
that something should perhaps be pushed there.  Ie, if one passes it
an INITIAL-TESTED-VERSION, which should usually be a git commit hash,
then that hash is pushed to the osstest-tested branch.

Ian.

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

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Jan Beulich]

>>> On 09.09.16 at 11:56,  wrote:

> 
> On 9/9/2016 5:44 PM, Jan Beulich wrote:
> On 09.09.16 at 11:24,  wrote:
>>> On 9/9/2016 4:20 PM, Jan Beulich wrote:
>>> On 09.09.16 at 09:24,  wrote:
> On 9/9/2016 1:26 PM, Yu Zhang wrote:
> On 02.09.16 at 12:47,  wrote:
>>> @@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
>>>if ( is_epte_valid(ept_entry) )
>>>{
>>>if ( (recalc || ept_entry->recalc) &&
>>> - p2m_is_changeable(ept_entry->sa_p2mt) )
>>> + p2m_is_changeable(ept_entry->sa_p2mt) &&
>>> + (ept_entry->sa_p2mt != p2m_ioreq_server) )
>>>*t = p2m_is_logdirty_range(p2m, gfn, gfn) ?
>> p2m_ram_logdirty
>>>  : p2m_ram_rw;
>>>else
>> Considering this (and at least one more similar adjustment further
>> down), is it really appropriate to include p2m_ioreq_server in the
>> set of "changeable" types?
> Well, I agree p2m_ioreq_server do have different behaviors than the
> p2m_log_dirty, but removing p2m_ioreq_server from changeable type
> would need more specific code for the p2m_ioreq_server in routines like
> resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
> I've tried this approach and abandoned later. :)
 I can see that the other option might require more adjustments, in
 which case I guess this variant would be fine if you created another
 helper (well named) inline function instead of open coding this in
 several places. Of course such dissimilar handling in the various
 places p2m_is_changeable() gets used right now will additionally
 require good reasoning - after all that predicate exists to express
 the similarities between different code paths.
>>> Thanks Jan.
>>> Well, for the logic of p2m type recalculation, similarities between
>>> p2m_ioreq_server
>>> and other changeable types exceeds their differences. As to the special
>>> cases, how
>>> about we use a macro, i.e. p2m_is_ioreq?
>> That'd be better than the open coded check, but would still result
>> in (taking the above example)
>>
>>   p2m_is_changeable(ept_entry->sa_p2mt) &&
>>   !p2m_is_ioreq(ept_entry->sa_p2mt) )
>>
>> ? What I'd prefer is a predicate that can be applied here on its own,
>> without involving && or ||.
>>
> 
> OK. I can think of 2 scenarios that p2m_ioreq_server needs special handling:
> 
> 1> In ept_get_entry()/recal_type(), the p2m types are supposed to return 
> as it is, instead of
> changing to p2m_log_dirty. So we can use a macro or a inline function 
> like p2m_check_changeable(),
> which combines the
> 
>   p2m_is_changeable(ept_entry->sa_p2mt) &&
>   !p2m_is_ioreq(ept_entry->sa_p2mt) )
> 
> together.
> 
> 2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented. We
> do not need this new inline function, because they are in a separate 
> if() statement.
> 
> Is this OK? :)

Sounds reasonable. But please give George and others a chance to
voice their opinions before you go that route.

Jan


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

Re: [Xen-devel] [PATCH v3] libxl: add "xl qemu-monitor-command"

[Wei Liu]

On Tue, Sep 06, 2016 at 02:16:30PM +0200, Dario Faggioli wrote:
> On Tue, 2016-09-06 at 12:51 +0200, Juergen Gross wrote:
> > Add a new xl command "qemu-monitor-command" to issue arbitrary
> > commands
> > to a domain's device model. Syntax is:
> > 
> > xl qemu-monitor-command  
> > 
> > The command is issued via qmp human-monitor-command command. Any
> > information returned by the command is printed to stdout.
> > 
> > Signed-off-by: Juergen Gross 
> > ---
> > V3: - add GC_FREE as requested by Dario Faggioli
> > - return with EXIT_FAILURE/SUCCESS as requested by Dario Faggioli
> >
> I think you missed one...
> 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 7540fb1..d1a2a14 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -9536,6 +9536,35 @@ int main_psr_hwinfo(int argc, char **argv)
> >  
> >  #endif
> >  
> > +int main_qemu_monitor_command(int argc, char **argv)
> > +{
> > +int opt;
> > +uint32_t domid;
> > +char *cmd;
> > +char *output;
> > +int ret;
> > +
> > +SWITCH_FOREACH_OPT(opt, "", NULL, "qemu-monitor-command", 2) {
> > +/* No options */
> > +}
> > +
> > +domid = find_domain(argv[optind]);
> > +cmd = argv[optind + 1];
> > +
> > +if (argc - optind > 2) {
> > +fprintf(stderr, "Invalid arguments.\n");
> > +return 1;
> >
> ...here.
> 
> Anyway, this is
> 
> Reviewed-by: Dario Faggioli 

Thanks for reviewing.

Acked-by: Wei Liu 

> 
> if possible, with the above 'return 1' converted to 'return
> EXIT_FAILURE' (either by resending or done upon commit).
> 

I can fix that up, no need to resend.

Wei.

> If a maintainer wants to ack and commit this as is, my R-b still
> stands. In fact, as I said, xl is still not yet 100% consistent wrt
> this, and although I think new code should comply with the rule, I
> won't stand in the way of a patch for something like this.
> 
> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



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

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"):
> On Thu, Sep 08, 2016 at 06:45:06PM +0100, Ian Jackson wrote:
> > I think it needs a hypervisor and kernel build too!  Here are the
> 
> It does have hypervisor and kernel build jobs, but they were somehow
> truncated in my mail, sorry.  Here is the complete output for xtf
> branch:

Oh!  OK, yes, that looks good.

Acked-by: Ian Jackson 

Thanks,
Ian.

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

[Xen-devel] [xen-4.4-testing baseline-only test] 67679: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 66864

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl  20 guest-start.2fail blocked in 66864
 test-amd64-i386-xl-qemuu-debianhvm-amd64 20 leak-check/check fail blocked in 
66864
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 66864
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 66864
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66864
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66864
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66864

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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 11 guest-start  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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  dfddbf35d9df666fa731dcaf35afd8cf24ac8ecf
baseline version:
 xen  0fe7d6961755812503694e9a4741b5f35a09d1f7

Last test of basis66864  2016-07-30 06:43:37 Z   41 days
Testing same since67679  2016-09-09 04:15:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  fail
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-am

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

On 9/9/2016 5:44 PM, Jan Beulich wrote:

On 09.09.16 at 11:24,  wrote:

On 9/9/2016 4:20 PM, Jan Beulich wrote:

On 09.09.16 at 09:24,  wrote:

On 9/9/2016 1:26 PM, Yu Zhang wrote:

On 02.09.16 at 12:47,  wrote:

@@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
   if ( is_epte_valid(ept_entry) )
   {
   if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_is_changeable(ept_entry->sa_p2mt) &&
+ (ept_entry->sa_p2mt != p2m_ioreq_server) )
   *t = p2m_is_logdirty_range(p2m, gfn, gfn) ?

p2m_ram_logdirty

 : p2m_ram_rw;
   else

Considering this (and at least one more similar adjustment further
down), is it really appropriate to include p2m_ioreq_server in the
set of "changeable" types?

Well, I agree p2m_ioreq_server do have different behaviors than the
p2m_log_dirty, but removing p2m_ioreq_server from changeable type
would need more specific code for the p2m_ioreq_server in routines like
resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
I've tried this approach and abandoned later. :)

I can see that the other option might require more adjustments, in
which case I guess this variant would be fine if you created another
helper (well named) inline function instead of open coding this in
several places. Of course such dissimilar handling in the various
places p2m_is_changeable() gets used right now will additionally
require good reasoning - after all that predicate exists to express
the similarities between different code paths.

Thanks Jan.
Well, for the logic of p2m type recalculation, similarities between
p2m_ioreq_server
and other changeable types exceeds their differences. As to the special
cases, how
about we use a macro, i.e. p2m_is_ioreq?

That'd be better than the open coded check, but would still result
in (taking the above example)

  p2m_is_changeable(ept_entry->sa_p2mt) &&
  !p2m_is_ioreq(ept_entry->sa_p2mt) )

? What I'd prefer is a predicate that can be applied here on its own,
without involving && or ||.



OK. I can think of 2 scenarios that p2m_ioreq_server needs special handling:

1> In ept_get_entry()/recal_type(), the p2m types are supposed to return 
as it is, instead of
changing to p2m_log_dirty. So we can use a macro or a inline function 
like p2m_check_changeable(),

which combines the

 p2m_is_changeable(ept_entry->sa_p2mt) &&
 !p2m_is_ioreq(ept_entry->sa_p2mt) )

together.

2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented. We
do not need this new inline function, because they are in a separate 
if() statement.


Is this OK? :)

Thanks
Yu



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

Re: [Xen-devel] [PATCH 1/6] libxl: rename libcl_pvusb.c to libxl_usb.c

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:21AM +0200, Juergen Gross wrote:
> Rename libcl_pvusb.c to libxl_usb.c in order to reflect future support
> of USB passthrough via qemu emulated USB controllers.
> 

Typo "libcl" in both subject line and commit message.

> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
>  tools/libxl/Makefile   | 2 +-
>  tools/libxl/{libxl_pvusb.c => libxl_usb.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename tools/libxl/{libxl_pvusb.c => libxl_usb.c} (100%)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 6994c58..f32169a 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -108,7 +108,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
> libxl_dm.o libxl_pci.o \
>   libxl_stream_read.o libxl_stream_write.o \
>   libxl_save_callout.o _libxl_save_msgs_callout.o \
>   libxl_qmp.o libxl_event.o libxl_fork.o \
> - libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \
> + libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
>   libxl_vtpm.o libxl_nic.o \
>  $(LIBXL_OBJS-y)
>  LIBXL_OBJS += libxl_genid.o
> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_usb.c
> similarity index 100%
> rename from tools/libxl/libxl_pvusb.c
> rename to tools/libxl/libxl_usb.c
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH 3/6] libxl: dont pass array size to libxl__xs_kvs_of_flexarray()

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:23AM +0200, Juergen Gross wrote:
> Instead of passing the array size as an argument when calling
> libxl__xs_kvs_of_flexarray() let the function get the size from the
> array instead.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
> Add HVM usb passthrough support to libxl by using qemu's capability
> to emulate standard USB controllers.
> 
> A USB controller is added via qmp command to the emulated hardware
> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> the requested speed the appropriate hardware type is selected. A host
> USB device can then be added to the emulated USB controller via qmp
> command.
> 
> Removing of the devices is done via qmp commands, too.
> 
> Signed-off-by: Juergen Gross 
[...]
>  
> @@ -75,9 +131,19 @@ static int libxl__device_from_usbctrl(libxl__gc *gc, 
> uint32_t domid,
>  {
>  device->backend_devid   = usbctrl->devid;
>  device->backend_domid   = usbctrl->backend_domid;
> -device->backend_kind= (usbctrl->type == LIBXL_USBCTRL_TYPE_PV)
> -  ? LIBXL__DEVICE_KIND_VUSB
> -  : LIBXL__DEVICE_KIND_QUSB;
> +switch (usbctrl->type) {
> +case LIBXL_USBCTRL_TYPE_PV:
> +device->backend_kind = LIBXL__DEVICE_KIND_VUSB;
> +break;
> +case LIBXL_USBCTRL_TYPE_QUSB:
> +device->backend_kind = LIBXL__DEVICE_KIND_QUSB;
> +break;
> +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> +device->backend_kind = LIBXL__DEVICE_KIND_NONE;

I'm not quite sure if I follow this. Shouldn't we need a new kind of
backend for this?

Wei.

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

Re: [Xen-devel] [PATCH 2/6] libxl: add libxl__qmp_run_command_flexarray() function

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:22AM +0200, Juergen Gross wrote:
> Add a function libxl__qmp_run_command_flexarray() to run a qmp command
> with an array of arguments. The arguments are name-value pairs stored
> in a flexarray.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
>  tools/libxl/libxl_internal.h |  3 +++
>  tools/libxl/libxl_qmp.c  | 16 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 3f29aa6..ecbfdad 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1753,6 +1753,9 @@ typedef struct libxl__qmp_handler libxl__qmp_handler;
>   */
>  _hidden libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
>uint32_t domid);
> +_hidden int libxl__qmp_run_command_flexarray(libxl__gc *gc, int domid,
> + const char *cmd,
> + flexarray_t *array);
>  /* ask to QEMU the serial port information and store it in xenstore. */
>  _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
>  _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci 
> *pcidev);
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 0d8d5f4..f8addf9 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -827,6 +827,22 @@ static int qmp_run_command(libxl__gc *gc, int domid,
>  return rc;
>  }
>  
> +int libxl__qmp_run_command_flexarray(libxl__gc *gc, int domid,
> + const char *cmd, flexarray_t *array)
> +{
> +libxl__json_object *args = NULL;
> +int i;
> +void *name, *value;
> +
> +for (i = 0; i < array->count; i += 2) {
> +flexarray_get(array, i, &name);
> +flexarray_get(array, i + 1, &value);
> +qmp_parameters_add_string(gc, &args, (char *)name, (char *)value);
> +}
> +
> +return qmp_run_command(gc, domid, cmd, args, NULL, NULL);
> +}
> +
>  int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
>  {
>  libxl__qmp_handler *qmp = NULL;
> -- 
> 2.6.6
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  26ea2cce0d3d25974eea3c643ce2081adfa2a69c
baseline version:
 xen  0831e99446121636045cf6f616a1991d6ef22071

Last test of basis   100822  2016-09-08 16:02:40 Z0 days
Testing same since   100840  2016-09-09 08:02:30 Z0 days1 attempts


People who touched revisions under test:
  Lars Kurth 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=26ea2cce0d3d25974eea3c643ce2081adfa2a69c
+ . ./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 
26ea2cce0d3d25974eea3c643ce2081adfa2a69c
+ branch=xen-unstable-smoke
+ revision=26ea2cce0d3d25974eea3c643ce2081adfa2a69c
+ . ./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.7-testing
+ '[' x26ea2cce0d3d25974eea3c643ce2081adfa2a69c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Andrew Cooper]

On 09/09/16 10:46, Jan Beulich wrote:
 On 09.09.16 at 11:34,  wrote:
>> On 09/09/16 08:56, Jan Beulich wrote:
>> On 09.09.16 at 07:37,  wrote:
>> Did you go through and check that there is nothing this information
>> can already get derived from? I can't immediately point you at
>> anything, but it feels like there should. 
>>
> Indeed. And if there isn't and we need to do add our own flagging,
> isn't there a better way and place where to put it (e.g., what Juergen
> and Andrew are hinting at)?
 I prefer that to derive whether guest boot finishes is neither limited to a
 specific domain type (pv, hvm, pvhvm or pvh) nor a specific arch (i386, 
 x86_64,
 arm32, arm64 or more in the future). Ideally, I would have one or a combo 
 of
 fields belong to "struct domain" but there isn't.
>>> Of course.
>>>
 Can we use the field in vcpu[0]?
>>> I don't think so: What if another vCPU was scheduled to run first?
>> Use the XEN_DOMCTL_unpausedomain hypercall.  It must be called by
>> toolstacks on all architectures to complete domain construction.
> I think we had settled on this one already. The question now being
> discussed is whether a new field in the domain structure is needed,
> or whether the information he's after can be derived from already
> existing fields.

If the information were derivable from other means, there would be no
need to alter XEN_DOMCTL_unpausedomain in the first place.

I can't think of any option other than to add something new.

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Jan Beulich]

>>> On 09.09.16 at 11:34,  wrote:
> On 09/09/16 08:56, Jan Beulich wrote:
> On 09.09.16 at 07:37,  wrote:
> Did you go through and check that there is nothing this information
> can already get derived from? I can't immediately point you at
> anything, but it feels like there should. 
>
 Indeed. And if there isn't and we need to do add our own flagging,
 isn't there a better way and place where to put it (e.g., what Juergen
 and Andrew are hinting at)?
>>> I prefer that to derive whether guest boot finishes is neither limited to a
>>> specific domain type (pv, hvm, pvhvm or pvh) nor a specific arch (i386, 
>>> x86_64,
>>> arm32, arm64 or more in the future). Ideally, I would have one or a combo of
>>> fields belong to "struct domain" but there isn't.
>> Of course.
>>
>>> Can we use the field in vcpu[0]?
>> I don't think so: What if another vCPU was scheduled to run first?
> 
> Use the XEN_DOMCTL_unpausedomain hypercall.  It must be called by
> toolstacks on all architectures to complete domain construction.

I think we had settled on this one already. The question now being
discussed is whether a new field in the domain structure is needed,
or whether the information he's after can be derived from already
existing fields.

Jan


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

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Lars Kurth]

On 09/09/2016 08:35, "Wei Liu"  wrote:

>> > Otherwise: Ping? Who else needs to ACK to check this in
>> > Lars
>> 
>> Given the lack of any objections, I declare that agreement via lazy
>> consensus.  I reckon it is fine to go in with its current review/ack
>>set.
>> 
>
>Acked + pushed.
>
>Removed all trailing whitespaces and added a new line to the end of
>CONTRIBUTING file while committing.
>
>Wei.

Thank you
Lars

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

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Jan Beulich]

>>> On 09.09.16 at 11:24,  wrote:

> 
> On 9/9/2016 4:20 PM, Jan Beulich wrote:
> On 09.09.16 at 09:24,  wrote:
>>> On 9/9/2016 1:26 PM, Yu Zhang wrote:
>>> On 02.09.16 at 12:47,  wrote:
> @@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
>   if ( is_epte_valid(ept_entry) )
>   {
>   if ( (recalc || ept_entry->recalc) &&
> - p2m_is_changeable(ept_entry->sa_p2mt) )
> + p2m_is_changeable(ept_entry->sa_p2mt) &&
> + (ept_entry->sa_p2mt != p2m_ioreq_server) )
>   *t = p2m_is_logdirty_range(p2m, gfn, gfn) ?
 p2m_ram_logdirty
> : p2m_ram_rw;
>   else
 Considering this (and at least one more similar adjustment further
 down), is it really appropriate to include p2m_ioreq_server in the
 set of "changeable" types?
>>> Well, I agree p2m_ioreq_server do have different behaviors than the
>>> p2m_log_dirty, but removing p2m_ioreq_server from changeable type
>>> would need more specific code for the p2m_ioreq_server in routines like
>>> resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
>>> I've tried this approach and abandoned later. :)
>> I can see that the other option might require more adjustments, in
>> which case I guess this variant would be fine if you created another
>> helper (well named) inline function instead of open coding this in
>> several places. Of course such dissimilar handling in the various
>> places p2m_is_changeable() gets used right now will additionally
>> require good reasoning - after all that predicate exists to express
>> the similarities between different code paths.
> 
> Thanks Jan.
> Well, for the logic of p2m type recalculation, similarities between 
> p2m_ioreq_server
> and other changeable types exceeds their differences. As to the special 
> cases, how
> about we use a macro, i.e. p2m_is_ioreq?

That'd be better than the open coded check, but would still result
in (taking the above example)

 p2m_is_changeable(ept_entry->sa_p2mt) &&
 !p2m_is_ioreq(ept_entry->sa_p2mt) )

? What I'd prefer is a predicate that can be applied here on its own,
without involving && or ||.

Jan


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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Andrew Cooper]

On 09/09/16 08:56, Jan Beulich wrote:
 On 09.09.16 at 07:37,  wrote:
 Did you go through and check that there is nothing this information
 can already get derived from? I can't immediately point you at
 anything, but it feels like there should. 

>>> Indeed. And if there isn't and we need to do add our own flagging,
>>> isn't there a better way and place where to put it (e.g., what Juergen
>>> and Andrew are hinting at)?
>> I prefer that to derive whether guest boot finishes is neither limited to a
>> specific domain type (pv, hvm, pvhvm or pvh) nor a specific arch (i386, 
>> x86_64,
>> arm32, arm64 or more in the future). Ideally, I would have one or a combo of
>> fields belong to "struct domain" but there isn't.
> Of course.
>
>> Can we use the field in vcpu[0]?
> I don't think so: What if another vCPU was scheduled to run first?

Use the XEN_DOMCTL_unpausedomain hypercall.  It must be called by
toolstacks on all architectures to complete domain construction.

~Andrew

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

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

On 9/9/2016 4:20 PM, Jan Beulich wrote:

On 09.09.16 at 09:24,  wrote:

On 9/9/2016 1:26 PM, Yu Zhang wrote:

On 02.09.16 at 12:47,  wrote:

@@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
  if ( is_epte_valid(ept_entry) )
  {
  if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_is_changeable(ept_entry->sa_p2mt) &&
+ (ept_entry->sa_p2mt != p2m_ioreq_server) )
  *t = p2m_is_logdirty_range(p2m, gfn, gfn) ?

p2m_ram_logdirty

: p2m_ram_rw;
  else

Considering this (and at least one more similar adjustment further
down), is it really appropriate to include p2m_ioreq_server in the
set of "changeable" types?

Well, I agree p2m_ioreq_server do have different behaviors than the
p2m_log_dirty, but removing p2m_ioreq_server from changeable type
would need more specific code for the p2m_ioreq_server in routines like
resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
I've tried this approach and abandoned later. :)

I can see that the other option might require more adjustments, in
which case I guess this variant would be fine if you created another
helper (well named) inline function instead of open coding this in
several places. Of course such dissimilar handling in the various
places p2m_is_changeable() gets used right now will additionally
require good reasoning - after all that predicate exists to express
the similarities between different code paths.


Thanks Jan.
Well, for the logic of p2m type recalculation, similarities between 
p2m_ioreq_server
and other changeable types exceeds their differences. As to the special 
cases, how

about we use a macro, i.e. p2m_is_ioreq?




Jan




Yu

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

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

On 9/9/2016 4:09 PM, Jan Beulich wrote:

On 09.09.16 at 07:55,  wrote:

On 9/5/2016 9:31 PM, Jan Beulich wrote:

On 02.09.16 at 12:47,  wrote:

@@ -178,8 +179,27 @@ static int hvmemul_do_io(
   break;
   case X86EMUL_UNHANDLEABLE:
   {
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);

What I recall is that we had agreed on p2m_ioreq_server pages
to be treated as ordinary RAM ones as long as no server can be
found. The type check here contradicts that. Is there a reason?

Thanks Jan. I had given my explaination on Sep 6's reply. :)
If s is NULL for a p2m_ioreq_server page, we do not wish to traverse the
rangeset
by hvm_select_ioreq_server() again, it may probably be a read emulation
process
for a read-modify-write scenario.

Well, yes, I recall. Yet my request stands: At the very least there
should be a comment here outlining the intended behavior. That'll
make it quite a bit easier, I think, for the reader to figure whether
the code actually matches those intentions (and also help people
needing to touch this code again down the road).



OK. Thanks. I'll add a comment here. :)

Yu

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

[Xen-devel] [PATCH v3 2/2] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Julien Grall]

With livepatch the alternatives that should be patched are outside of
the Xen hypervisor _start -> _end. The current code is assuming that
only Xen could be patched and therefore will explode when a payload
contains alternatives.

Given that alt_instr contains a relative offset, the function
__apply_alternatives could directly take in parameter the virtual
address of the alt_instr set of the re-mapped region. So we can mandate
the callers of __apply_alternatives to provide use with a region that has
read-write access.

The only caller that will patch directly the Xen binary is the function
__apply_alternatives_multi_stop. The other caller apply_alternatives
will work on the payload which will still have read-write access at that
time.

Signed-off-by: Julien Grall 
Reviewed-by: Konrad Rzeszutek Wilk 

---

This is an alternative of the patch suggested by Konrad [1] to fix
alternatives patching with livepatching.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02880.html

Changes in v3:
- Add Konrad's reviewed-by

Changes in v2:
- Fix typoes
- Add a comment to details how __apply_alternative should be
called
- Clean-up the casting for region.begin and region.end
---
 xen/arch/arm/alternative.c | 65 ++
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index bd7d409..7203bae 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -94,28 +94,18 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 return insn;
 }
 
+/*
+ * The region patched should be read-write to allow __apply_alternatives
+ * to replacing the instructions when necessary.
+ */
 static int __apply_alternatives(const struct alt_region *region)
 {
 const struct alt_instr *alt;
-const u32 *origptr, *replptr;
-u32 *writeptr, *writemap;
-mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
-unsigned int xen_order = get_order_from_bytes(_end - _start);
+const u32 *replptr;
+u32 *origptr;
 
-printk(XENLOG_INFO "alternatives: Patching kernel code\n");
-
-/*
- * The text and inittext section are read-only. So re-map Xen to be
- * able to patch the code.
- */
-writemap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
-  VMAP_DEFAULT);
-if ( !writemap )
-{
-printk(XENLOG_ERR "alternatives: Unable to map the text section (size 
%u)\n",
-   1 << xen_order);
-return -ENOMEM;
-}
+printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
+   region->begin, region->end);
 
 for ( alt = region->begin; alt < region->end; alt++ )
 {
@@ -128,7 +118,6 @@ static int __apply_alternatives(const struct alt_region 
*region)
 BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
-writeptr = origptr - (u32 *)_start + writemap;
 replptr = ALT_REPL_PTR(alt);
 
 nr_inst = alt->alt_len / sizeof(insn);
@@ -136,19 +125,17 @@ static int __apply_alternatives(const struct alt_region 
*region)
 for ( i = 0; i < nr_inst; i++ )
 {
 insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(writeptr + i) = cpu_to_le32(insn);
+*(origptr + i) = cpu_to_le32(insn);
 }
 
 /* Ensure the new instructions reached the memory and nuke */
-clean_and_invalidate_dcache_va_range(writeptr,
- (sizeof (*writeptr) * nr_inst));
+clean_and_invalidate_dcache_va_range(origptr,
+ (sizeof (*origptr) * nr_inst));
 }
 
 /* Nuke the instruction cache */
 invalidate_icache();
 
-vunmap(writemap);
-
 return 0;
 }
 
@@ -159,10 +146,6 @@ static int __apply_alternatives(const struct alt_region 
*region)
 static int __apply_alternatives_multi_stop(void *unused)
 {
 static int patched = 0;
-const struct alt_region region = {
-.begin = __alt_instructions,
-.end = __alt_instructions_end,
-};
 
 /* We always have a CPU 0 at this point (__init) */
 if ( smp_processor_id() )
@@ -174,12 +157,38 @@ static int __apply_alternatives_multi_stop(void *unused)
 else
 {
 int ret;
+struct alt_region region;
+mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+unsigned int xen_order = get_order_from_bytes(_end - _start);
+void *xenmap;
 
 BUG_ON(patched);
+
+/*
+ * The text and inittext section are read-only. So re-map Xen to
+ * be able to patch the code.
+ */
+xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
+VMAP_DEFAULT);
+/* Re-mapping Xen is not expected to fail during boot. */
+BUG_ON(!xenmap);
+
+/*
+ * Find the virtual address of

[Xen-devel] [PATCH v3 0/2] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Julien Grall]

Hi,

The first patch is a clean-up, the second contains the meat of this series.

Yours sincerely,

Julien Grall (2):
  xen/arm: alternative: Clean-up __apply_alternatives
  xen/arm: alternative: Make it possible to patch outside of the
hypervisor

 xen/arch/arm/alternative.c | 65 ++
 1 file changed, 37 insertions(+), 28 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v3 1/2] xen/arm: alternative: Clean-up __apply_alternatives

[Julien Grall]

This patch contains only renaming and comment update. There are no
functional changes:
- Don't mix _start and _stext, they both point to the same address
but the former makes more sense (we are mapping the Xen binary, not
only the text section).
- s/text_mfn/xen_mfn/ and s/text_order/xen_order/ to make clear that
we map the Xen binary.
- Mention about inittext as alternative may patch this section.
- Use 1U instead of 1 in shift

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Julien Grall 

---
Konrad, I added your signed-off by because I squashed your patch [1]
in it. Let me know if there is any issue for that.

[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02890.html

Changes in v3:
- Replace "1 << xen_order" by "1U << xen_order".

Changes in v2:
- Patch added
---
 xen/arch/arm/alternative.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..bd7d409 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -99,21 +99,21 @@ static int __apply_alternatives(const struct alt_region 
*region)
 const struct alt_instr *alt;
 const u32 *origptr, *replptr;
 u32 *writeptr, *writemap;
-mfn_t text_mfn = _mfn(virt_to_mfn(_stext));
-unsigned int text_order = get_order_from_bytes(_end - _start);
+mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+unsigned int xen_order = get_order_from_bytes(_end - _start);
 
 printk(XENLOG_INFO "alternatives: Patching kernel code\n");
 
 /*
- * The text section is read-only. So re-map Xen to be able to patch
- * the code.
+ * The text and inittext section are read-only. So re-map Xen to be
+ * able to patch the code.
  */
-writemap = __vmap(&text_mfn, 1 << text_order, 1, 1, PAGE_HYPERVISOR,
+writemap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
   VMAP_DEFAULT);
 if ( !writemap )
 {
 printk(XENLOG_ERR "alternatives: Unable to map the text section (size 
%u)\n",
-   1 << text_order);
+   1 << xen_order);
 return -ENOMEM;
 }
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] xen/x86: Fix build with clang following c/s 4fa0105

[Jan Beulich]

>>> On 08.09.16 at 20:21,  wrote:
> https://travis-ci.org/xen-project/xen/jobs/158494027#L2344 
> 
> Clang complains:
> 
>   emulate.c:2016:14: error: comparison of unsigned enum expression < 0
>   is always false [-Werror,-Wtautological-compare]
>   if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
>~~~ ^ ~
> 
> Clang is wrong to raise a warning like this.  The signed-ness of an enum is
> implementation defined in C, and robust code must not assume the choices made
> by the compiler.

Indeed.

> In this case, dropping the < 0 check creates a latent bug which would result
> in an array underflow when compiled with a compiler which chooses a signed
> enum.
> 
> Work around the bug by explicitly pulling seg into an unsigned integer, and
> only perform the upper bounds check.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

[Jan Beulich]

>>> On 09.09.16 at 10:09,  wrote:
> On 16-09-08 03:54:24, Jan Beulich wrote:
>> >>> On 08.09.16 at 09:28,  wrote:
>> > On 16-09-07 03:01:34, Jan Beulich wrote:
>> >> >> >>> On 25.08.16 at 07:22,  wrote:
>> >> >> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list 
>> >> >> > *pFeat,
>> >> >> > + unsigned int cos);
>> >> >> 
>> >> >> According to the comment this is kind of a predicate, which seems
>> >> >> unlikely to return an unsigned value. In fact without a word on the
>> >> >> return value I'd expect such to return bool. And I'd also expect the
>> >> >> name to reflect the purpose, i.e. "exceeds_name()". Plus just like
>> >> >> for compare above I wonder whether come or all of the parameters
>> >> >> should be pointers to const (please go over the entire patch and do
>> >> >> constification wherever possible/sensible).
>> >> >> 
>> >> > Yes, you are right. I will change the function type to bool and add 
>> >> > const
>> >> > for not changed input pointers.
>> >> > 
>> >> > This function is used to check if the input cos id exceeds the cos_max. 
>> >> > If yes
>> >> > and the set value is not default value, we should return error. So, I 
>> >> > think
>> >> > to change the function name to exceed_cos_max(). How do you think?
>> >> 
>> >> Okay, except that I continue to think you mean "exceeds".
>> >> "exceed_cos_max" to me is kind of a directive, not a predicate.
>> >> 
>> > How about "beyond"?
>> 
>> What's wrong with "exceeds"?
>> 
> Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good name?

According to my knowledge of English this would still need to be
"check_exceeds_cos_max", and then the check ends up being quite
redundant.

>> >> >> > +static int l3_cat_compare_mask(uint64_t *mask, struct feat_list 
>> >> >> > *pFeat,
>> >> >> > +   unsigned int cos, bool_t *found)
>> >> >> > +{
>> >> >> > +struct psr_cat_lvl_info cat_info;
>> >> >> > +uint64_t l3_def_cbm;
>> >> >> > +
>> >> >> > +memcpy(&cat_info, pFeat->feat_info, sizeof(struct 
>> >> >> > psr_cat_lvl_info));
>> >> >> 
>> >> >> Already here I think this memcpy()ing gets unwieldy. Can't you
>> >> >> simply make the structure field a union of all types of interest?
>> >> >> 
>> >> > Sorry that I am not very clear about your meaning to make a union. Do 
>> >> > you mean
>> >> > make feat_info a union? If so, it will lose the universality to cover 
>> >> > all
>> >> > features. Future feature may have different info.
>> >> 
>> >> Which is the purpose of a union - you'd simply add a new member
>> >> then.
>> >>
>> > I guess your idea likes below. Right?
>> > union {
>> > struct l3_info {
>> > union {
>> > uint64_t cbm;
>> > struct {
>> > uint64_t code;
>> > uint64_t data;
>> > };
>> > };
>> > 
>> > };
>> > 
>> > struct l2_info {
>> > uint64_t cbm;
>> > };
>> > };
>> >  
>> > My original design is to use this feat_info cover all features and 
>> > eliminate
>> > the feature's specific properties. If using above union, we still need to
>> > know the current feature is which when handles feat_info. That loses the
>> > abstraction.
>> > 
>> > If my thought is not right, please correct me. Thanks!
>> 
>> I don't understand what abstraction you would lose with the above
>> layout. The memcpy()int you currently do is, I'm sorry to say that,
>> horrible.
>> 
> Sorry to make you feel bad. I will avoid to use memcpy() in the codes.
> 
> I think I have got your mean. I will construct a union for feat_info in next
> version. Different features can use different members in union. Then, I can
> directly assign the struct value without memcpy. Thanks for the guidance!

You shouldn't need to do such assignments in the vast majority of
places you do the memcpy()ing in right now. (And don't forget,
structure assignment in the end is only a type safe variant of
memcpy().)

>> >> >> > +if ( type == PSR_MASK_TYPE_L3_CBM )
>> >> >> > +mask[0] = m;
>> >> >> 
>> >> >> This overwriting behavior also looks quite strange to me. What's
>> >> >> the purpose? And if this really is meant to be that way, why is
>> >> >> this not (leaving aside the other suggested adjustment)
>> >> >> 
>> >> >> if ( type == PSR_MASK_TYPE_L3_CBM )
>> >> >> mask[0] = m;
>> >> >> else if ( old_cos > cat_info.cos_max )
>> >> >> mask[0] = pFeat->cos_reg_val[0];
>> >> >> else
>> >> >> mask[0] = pFeat->cos_reg_val[old_cos];
>> >> >> 
>> >> >> ?
>> >> >> 
>> >> > get_old_set_new() is used to do below two things:
>> >> > 1. get old_cos register value of all supported features and
>> >> > 2. set the new value for appointed feature.
>> >> > 
>> >> > So, if the appointed feature is L3 CAT, we should set input vallue for 
>> >> > it 
>> >> > here.
>> >> 
>> >> Okay, that answers the "what" aspect, but leaves open _why_ it
>> >> needs to be that way.

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Jan Beulich]

>>> On 09.09.16 at 09:24,  wrote:
> On 9/9/2016 1:26 PM, Yu Zhang wrote:
>> >>> On 02.09.16 at 12:47,  wrote:
>> > @@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
>> >  if ( is_epte_valid(ept_entry) )
>> >  {
>> >  if ( (recalc || ept_entry->recalc) &&
>> > - p2m_is_changeable(ept_entry->sa_p2mt) )
>> > + p2m_is_changeable(ept_entry->sa_p2mt) &&
>> > + (ept_entry->sa_p2mt != p2m_ioreq_server) )
>> >  *t = p2m_is_logdirty_range(p2m, gfn, gfn) ? 
>> p2m_ram_logdirty
>> >: p2m_ram_rw;
>> >  else
>>
>> Considering this (and at least one more similar adjustment further
>> down), is it really appropriate to include p2m_ioreq_server in the
>> set of "changeable" types?
> 
> Well, I agree p2m_ioreq_server do have different behaviors than the
> p2m_log_dirty, but removing p2m_ioreq_server from changeable type
> would need more specific code for the p2m_ioreq_server in routines like
> resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
> I've tried this approach and abandoned later. :)

I can see that the other option might require more adjustments, in
which case I guess this variant would be fine if you created another
helper (well named) inline function instead of open coding this in
several places. Of course such dissimilar handling in the various
places p2m_is_changeable() gets used right now will additionally
require good reasoning - after all that predicate exists to express
the similarities between different code paths.

>> > +while ( gfn <= end )
>> > +{
>> > +get_gfn_query_unlocked(d, gfn, &t);
>> > +
>> > +if ( t == ot )
>> > +p2m_change_type_one(d, gfn, t, nt);
>> > +
>> > +gfn++;
>> > +}
>> > +
>> > +p2m_unlock(p2m);
>> > +}
>>
>> And then I wonder why p2m_change_type_range() can't be used
>> instead of adding this new function.
>>
> 
> Well, like p2m_change_entry_type_global() , p2m_change_type_range() also
> does the change asynchronously. And here this routine is introduced
> to synchronously reset the p2m type.

Ah, of course. Silly me.

Jan


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

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

[Yi Sun]

On 16-09-08 03:54:24, Jan Beulich wrote:
> >>> On 08.09.16 at 09:28,  wrote:
> > On 16-09-07 03:01:34, Jan Beulich wrote:
> >> >> >>> On 25.08.16 at 07:22,  wrote:
> >> >> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list 
> >> >> > *pFeat,
> >> >> > + unsigned int cos);
> >> >> 
> >> >> According to the comment this is kind of a predicate, which seems
> >> >> unlikely to return an unsigned value. In fact without a word on the
> >> >> return value I'd expect such to return bool. And I'd also expect the
> >> >> name to reflect the purpose, i.e. "exceeds_name()". Plus just like
> >> >> for compare above I wonder whether come or all of the parameters
> >> >> should be pointers to const (please go over the entire patch and do
> >> >> constification wherever possible/sensible).
> >> >> 
> >> > Yes, you are right. I will change the function type to bool and add const
> >> > for not changed input pointers.
> >> > 
> >> > This function is used to check if the input cos id exceeds the cos_max. 
> >> > If yes
> >> > and the set value is not default value, we should return error. So, I 
> >> > think
> >> > to change the function name to exceed_cos_max(). How do you think?
> >> 
> >> Okay, except that I continue to think you mean "exceeds".
> >> "exceed_cos_max" to me is kind of a directive, not a predicate.
> >> 
> > How about "beyond"?
> 
> What's wrong with "exceeds"?
> 
Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good name?

> >> >> > +static int l3_cat_compare_mask(uint64_t *mask, struct feat_list 
> >> >> > *pFeat,
> >> >> > +   unsigned int cos, bool_t *found)
> >> >> > +{
> >> >> > +struct psr_cat_lvl_info cat_info;
> >> >> > +uint64_t l3_def_cbm;
> >> >> > +
> >> >> > +memcpy(&cat_info, pFeat->feat_info, sizeof(struct 
> >> >> > psr_cat_lvl_info));
> >> >> 
> >> >> Already here I think this memcpy()ing gets unwieldy. Can't you
> >> >> simply make the structure field a union of all types of interest?
> >> >> 
> >> > Sorry that I am not very clear about your meaning to make a union. Do 
> >> > you mean
> >> > make feat_info a union? If so, it will lose the universality to cover all
> >> > features. Future feature may have different info.
> >> 
> >> Which is the purpose of a union - you'd simply add a new member
> >> then.
> >>
> > I guess your idea likes below. Right?
> > union {
> > struct l3_info {
> > union {
> > uint64_t cbm;
> > struct {
> > uint64_t code;
> > uint64_t data;
> > };
> > };
> > 
> > };
> > 
> > struct l2_info {
> > uint64_t cbm;
> > };
> > };
> >  
> > My original design is to use this feat_info cover all features and eliminate
> > the feature's specific properties. If using above union, we still need to
> > know the current feature is which when handles feat_info. That loses the
> > abstraction.
> > 
> > If my thought is not right, please correct me. Thanks!
> 
> I don't understand what abstraction you would lose with the above
> layout. The memcpy()int you currently do is, I'm sorry to say that,
> horrible.
> 
Sorry to make you feel bad. I will avoid to use memcpy() in the codes.

I think I have got your mean. I will construct a union for feat_info in next
version. Different features can use different members in union. Then, I can
directly assign the struct value without memcpy. Thanks for the guidance!

> >> > I think I can replace the memcpy() to directly assign value to cat_info.
> >> 
> >> No, this copying (done in _many_ places) really should go away.
> >> 
> > I want to replace memcpy() to below codes.
> > cat_info.cbm_len = feat_info[0];
> > cat_info.cos_max = feat_info[1];
> 
> And again do that in a dozen places? No, please don't.
> 
Sure.

> >> >> > +if ( type == PSR_MASK_TYPE_L3_CBM )
> >> >> > +mask[0] = m;
> >> >> 
> >> >> This overwriting behavior also looks quite strange to me. What's
> >> >> the purpose? And if this really is meant to be that way, why is
> >> >> this not (leaving aside the other suggested adjustment)
> >> >> 
> >> >> if ( type == PSR_MASK_TYPE_L3_CBM )
> >> >> mask[0] = m;
> >> >> else if ( old_cos > cat_info.cos_max )
> >> >> mask[0] = pFeat->cos_reg_val[0];
> >> >> else
> >> >> mask[0] = pFeat->cos_reg_val[old_cos];
> >> >> 
> >> >> ?
> >> >> 
> >> > get_old_set_new() is used to do below two things:
> >> > 1. get old_cos register value of all supported features and
> >> > 2. set the new value for appointed feature.
> >> > 
> >> > So, if the appointed feature is L3 CAT, we should set input vallue for 
> >> > it 
> >> > here.
> >> 
> >> Okay, that answers the "what" aspect, but leaves open _why_ it
> >> needs to be that way.
> >> 
> > A scenario here to help to understand _why_. 
> > 
> > Like the example for explaining get_old_set_new(), old_cos of the domain is 
> > 1.
> > Then, User wants t