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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 112655
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 112655
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112655
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112655
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 112655
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112655
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112655
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 112655

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112655
 build-arm64   2 hosts-allocate  broken like 112655
 build-arm64-xsm   3 capture-logsbroken like 112655
 build-arm64-pvops 2 hosts-allocate  broken like 112655
 build-arm64-pvops 3 capture-logsbroken like 112655
 build-arm64   3 capture-logsbroken like 112655
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112655
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112655
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112655
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112655
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112655
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112655
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112655
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112655
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 

[Xen-devel] [libvirt test] 112693: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112677
 build-arm64-pvops 2 hosts-allocate  broken like 112677
 build-arm64-xsm   3 capture-logsbroken like 112677
 build-arm64   2 hosts-allocate  broken like 112677
 build-arm64-pvops 3 capture-logsbroken like 112677
 build-arm64   3 capture-logsbroken like 112677
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112677
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112677
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112677
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  ad97fecee721a4527e9aca9977b8e2360989620d
baseline version:
 libvirt  21de51c3e26d2b5ca71f7891704b4f8cd8049b58

Last test of basis   112677  2017-08-17 04:21:06 Z1 days
Testing same since   112693  2017-08-18 04:29:09 Z0 days1 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Erik Skultety 
  John Ferlan 
  Michal Privoznik 
  Pavel Hrdina 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 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-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112703
 build-arm64   2 hosts-allocate  broken like 112703
 build-arm64-pvops 3 capture-logsbroken like 112703
 build-arm64   3 capture-logsbroken like 112703
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82d510c88dc12c8aa31aa97bab633b922737bdf4
baseline version:
 xen  7f86858186f4932ceba91f731337e0ef536d6cd0

Last test of basis   112703  2017-08-18 18:20:18 Z0 days
Testing same since   112705  2017-08-18 21:02:27 Z0 days1 attempts


People who touched revisions under test:
  Tim Deegan 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

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

Re: [Xen-devel] [PATCH] xsm: policy hooks to require an IOMMU and interrupt remapping

[Daniel De Graaf]

On 08/18/2017 05:02 PM, christopher.w.cl...@gmail.com wrote:

From: Christopher Clark 

Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
available.

More graceful degradation of behaviour when an IOMMU is absent can be
achieved by enabling XSM to perform enforcement of IOMMU requirement.

This patch enables an enforceable XSM policy to specify that an IOMMU is
required for particular domains to access devices and how capable that
IOMMU must be. This allows a Xen system to boot whilst still
ensuring that an IOMMU is active before permitting device use.

Using a XSM policy ensures that the isolation properties remain enforced
even when the large, complex toolstack software changes.

For some hardware platforms interrupt remapping is a strict requirement
for secure isolation. Not all IOMMUs provide interrupt remapping.
The XSM policy can now optionally require interrupt remapping.

The device use hooks now check whether an IOMMU is:
  * Active and securely isolating:
 -- current criteria for this is that interrupt remapping is ok
  * Active but interrupt remapping is not available
  * Not active

This patch also updates the reference XSM policy to use the new
primitives, with policy entries that do not require an active IOMMU.

Signed-off-by: Christopher Clark 


Acked-by: Daniel De Graaf 

One additional note: if this type of permission expansion needs to be
applied to more permissions based on hypervisor settings, it may be
useful to look at other solutions (such as policy booleans) to implement
this logic.  However, most of those solutions are more complicated than
necessary for a single distinction like this, and the simpler ones do
not provide the same ease of verification that this version has.

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

[Xen-devel] [xen-4.5-testing test] 112689: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 14 guest-saverestorefail REGR. vs. 110906
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
110906
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 110906
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
110906
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 110906

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110906
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 110906
 test-xtf-amd64-amd64-2   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-3   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-1   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-5   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-4   59 leak-check/check fail  like 110906
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110906
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110906
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110906
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110906
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110906
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore  fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 13 guest-saverestore  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 

[Xen-devel] [PATCH] xsm: policy hooks to require an IOMMU and interrupt remapping

[christopher . w . clark]

From: Christopher Clark 

Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
available.

More graceful degradation of behaviour when an IOMMU is absent can be
achieved by enabling XSM to perform enforcement of IOMMU requirement.

This patch enables an enforceable XSM policy to specify that an IOMMU is
required for particular domains to access devices and how capable that
IOMMU must be. This allows a Xen system to boot whilst still
ensuring that an IOMMU is active before permitting device use.

Using a XSM policy ensures that the isolation properties remain enforced
even when the large, complex toolstack software changes.

For some hardware platforms interrupt remapping is a strict requirement
for secure isolation. Not all IOMMUs provide interrupt remapping.
The XSM policy can now optionally require interrupt remapping.

The device use hooks now check whether an IOMMU is:
 * Active and securely isolating:
-- current criteria for this is that interrupt remapping is ok
 * Active but interrupt remapping is not available
 * Not active

This patch also updates the reference XSM policy to use the new
primitives, with policy entries that do not require an active IOMMU.

Signed-off-by: Christopher Clark 
---
Patch author: Christopher Clark
Copyright belongs to BAE Systems. Written for OpenXT. [OXT-826]
The author is grateful to Daniel De Graaf, Stephen Smalley,
Daniel Smith and Ross Philipson for feedback on earlier revisions
of this patch.

This patch was developed for OpenXT for the 2017 stable-7 release
to ensure that a network interface card cannot be passed through
to the network driver domain unless the IOMMU is active.

Earlier versions of OpenXT had ensured this via logic in the toolstack,
but this behaviour was discovered to have been lost after porting the
upper level of the toolstack to use libxl. This motivated introduction
of a robust way of ensuring that this important system policy would
be preserved across any future toolstack changes.

The XSM hook code in this patch is the same as in OpenXT; the reference
policy is not. The hooks have been validated as behaving correctly on
several generations of Dell and HP Intel-based hardware, with this patch
applied to Xen 4.6, with and without interrupt remapping capability;
and further testing with Xen 4.9 on a subset of that hardware.
The reference policy in this patch has been compile-tested only.

An OpenXT system will still boot even with the IOMMU disabled -- which
is different behaviour than would be the case if the IOMMU was required
via the Xen command line. The system retains its isolation from the
network by preventing passthrough of the NIC(s) to the domain containing
the device drivers, whilst still allowing user access to VMs stored
locally on the system.

Since OpenXT supports older hardware with less capable IOMMUs, its
default configuration is to allow use without interrupt remapping,
but derivative projects of OpenXT with different hardware support
requirements are able to change their policy to the stronger setting
that insists on interrupt remapping availability.

Device isolation can be:
  Useful, eg. for resiliency against occasionally buggy devices
or
  Necessary, eg. strictly required for system security

and sometimes both are true:

The hooks in this patch enable a single XSM policy to be created
for a common software build that is usable across diverse hardware
to express:

  * that allowing GPU passthrough to a particular class of VMs does
require an IOMMU, but it can proceed without interrupt remapping,

  * whereas the network interface card is not allowed to be used
by the network driver domain unless an IOMMU is active and
it has interrupt remapping capability.

 tools/flask/policy/modules/nic_dev.te |  2 +-
 tools/flask/policy/modules/xen.if | 29 +++
 tools/flask/policy/modules/xen.te |  3 ++-
 xen/xsm/flask/hooks.c | 44 +--
 xen/xsm/flask/policy/access_vectors   | 20 ++--
 5 files changed, 83 insertions(+), 15 deletions(-)

diff --git a/tools/flask/policy/modules/nic_dev.te 
b/tools/flask/policy/modules/nic_dev.te
index e0484af..5206f1e 100644
--- a/tools/flask/policy/modules/nic_dev.te
+++ b/tools/flask/policy/modules/nic_dev.te
@@ -11,4 +11,4 @@
 type nic_dev_t, resource_type;
 
 admin_device(dom0_t, nic_dev_t)
-use_device(domU_t, nic_dev_t)
+use_device_noiommu(domU_t, nic_dev_t)
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index ed0df4f..9126400 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -167,11 +167,32 @@ define(`make_device_model', `
 #
 

Re: [Xen-devel] RT-Xen on ARM

[Meng Xu]

Hi Andrii,

On Tue, Aug 1, 2017 at 4:02 AM, Andrii Anisov  wrote:
> Hello Meng Xu,
>
> I've get back to this stuff.

Sorry for the late response. I'm not sure if you have already solved this.

>
>
> On 03.07.17 17:58, Andrii Anisov wrote:
>>
>> That's why we are going to keep configuration (of guests and workloads)
>> close to [1] for evaluation, but on our target SoC.
>> I'm wondering if there are known issues or specifics for ARM.
>>
>> [1] https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf
>
> Currently I have a setup with dom0 and domU's with Litmus-RT.

Great!

> Following the
> document I need workload tasks.
> Maybe you have mentioned workload tasks sources you can share, so that would
> shorten my steps.

Sure. The workload we used in the paper is mainly the cpu-intensive task.
We first calibrate a busy-loop of multiplications that runs for 1ms.
Then for a task that executes for exe(ms), we simply let the task
execute the 1ms busy loop for exe times.
It is also good to run the same task for several times to make sure
the task's execution time is table from different runs.

The Section 4.1 and 4.2 in [1] explained the whole experiment steps.
If you have any question or confusion on a specific step, please feel
free to let me know.
We may schedule a meeting to clarify all the questions or confusions
you may have.

[1] https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf

Best regards,

Meng




>
> --
>
> *Andrii Anisov*
>
>



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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112700
 build-arm64   2 hosts-allocate  broken like 112700
 build-arm64-pvops 3 capture-logsbroken like 112700
 build-arm64   3 capture-logsbroken like 112700
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7f86858186f4932ceba91f731337e0ef536d6cd0
baseline version:
 xen  08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a

Last test of basis   112700  2017-08-18 15:02:00 Z0 days
Testing same since   112703  2017-08-18 18:20:18 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Sergej Proskurin 
  Stefano Stabellini 
  Tamas K Lengyel 
  Volodymyr Babchuk 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=7f86858186f4932ceba91f731337e0ef536d6cd0
+ . ./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 
7f86858186f4932ceba91f731337e0ef536d6cd0
+ branch=xen-unstable-smoke
+ revision=7f86858186f4932ceba91f731337e0ef536d6cd0
+ . ./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.9-testing
+ '[' x7f86858186f4932ceba91f731337e0ef536d6cd0 = 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
++ : 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3a424c5f49239b810e08aa23368945a9f0360d4c
baseline version:
 ovmf d75b8ac278bc9f0159aa7eb9a92fd2cc87a18d8c

Last test of basis71988  2017-08-17 14:49:14 Z1 days
Testing same since71992  2017-08-18 16:50:24 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Dandan Bi 
  Eric Dong 
  Hao Wu 
  Jiaxin Wu 
  Laszlo Ersek 
  Marvin H?user 
  Marvin Haeuser 
  Wu Jiaxin 

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 3a424c5f49239b810e08aa23368945a9f0360d4c
Author: Ard Biesheuvel 
Date:   Thu Aug 17 13:16:58 2017 +0100

ArmPkg/ArmDmaLib: use double buffering only for bus master write

The ArmPkg implementation of DmaLib uses double buffering to ensure
that any attempt to perform non-coherent DMA on unaligned buffers cannot
corrupt adjacent unrelated data which happens to share cachelines with
the data we are exchanging with the device.

Such corruption can only occur on bus master write, in which case we have
to invalidate the caches to ensure the CPU will see the data written to
memory by the device. In the bus master read case, we can simply clean
and invalidate at the same time, which may purge unrelated adjacent data
from the caches, but will not corrupt its contents.

Also, this double buffer does not necessarily have to be allocated from
uncached memory: by the same reasoning, we can perform cache invalidation
on an ordinary pool allocation as long as we take the same alignment
constraints into account.

So update our code accordingly: remove double buffering from the bus
master read path, and switch to a pool allocation for the double buffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 5f0f5e90ae8c57f4a0702740d5aee95ce50fc684
Author: Laszlo Ersek 
Date:   Wed Aug 16 12:45:59 2017 +0200

ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib 
APIs

With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe:
Process timeout consistently in SerialRead", 2017-07-18), setting
EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the
GetControl() SerialPortLib function, is no longer a "small optimization".
Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in
TerminalDxe's TerminalConInTimerHandler() can take very long if the input
queue is empty, even if GetOneKeyFromSerial()'s return value causes the
loop to be exited right after, in the first iteration.

This issue causes a boot hang in ArmVirtQemu: with the input queue empty,
TerminalConInTimerHandler() takes so long to return that, by the time it
returns, there's another execution queued already (due to the associated
timer event being signaled meanwhile). The boot process is stuck in the
timer event handler.

Therefore even the first GetOneKeyFromSerial() iteration must be prevented
in TerminalConInTimerHandler() if the input queue is empty, and that
requires implementing GetControl() for real.

[Xen-devel] [PATCH v3] hvm: vmx/svm_cpu_up_prepare should be called only once

[Boris Ostrovsky]

These routines are first called via CPU_UP_PREPARE notifier by the BSP
and then by the booting ASP from vmx_cpu_up()/_svm_cpu_up().

Avoid the unnecessary second call. Becasue BSP doesn't go through
CPU_UP_PREPARE it is a special case and so we pass 'bsp' flag to
hvm_funcs.cpu_up() to help it decide whether or not to call
vmx/svm_cpu_up_prepare().

Signed-off-by: Boris Ostrovsky 
Reported-by: Andrew Cooper 
---
V3:
* Reverted to v1-style patch, without assumption that BSP is always CPU0.
  Problem with V2 was that on Intel vmx_cpu_up_prepare() needs to be called
  after vmx_init_vmcs_config(): the latter sets vmcs_revision_id, used
  later by vmx_alloc_vmcs().


 xen/arch/x86/hvm/svm/svm.c | 11 +++
 xen/arch/x86/hvm/vmx/vmcs.c|  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c |  2 +-
 xen/include/asm-x86/hvm/hvm.h  |  4 ++--
 xen/include/asm-x86/hvm/vmx/vmcs.h |  2 +-
 5 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0dc9442..6babb9b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1523,7 +1523,7 @@ static int svm_handle_osvw(struct vcpu *v, uint32_t msr, 
uint64_t *val, bool_t r
 return 0;
 }
 
-static int _svm_cpu_up(bool bsp)
+static int svm_cpu_up(bool bsp)
 {
 uint64_t msr_content;
 int rc;
@@ -1538,7 +1538,7 @@ static int _svm_cpu_up(bool bsp)
 return -EINVAL;
 }
 
-if ( (rc = svm_cpu_up_prepare(cpu)) != 0 )
+if ( bsp && (rc = svm_cpu_up_prepare(cpu)) != 0 )
 return rc;
 
 write_efer(read_efer() | EFER_SVME);
@@ -1578,18 +1578,13 @@ static int _svm_cpu_up(bool bsp)
 return 0;
 }
 
-static int svm_cpu_up(void)
-{
-return _svm_cpu_up(false);
-}
-
 const struct hvm_function_table * __init start_svm(void)
 {
 bool_t printed = 0;
 
 svm_host_osvw_reset();
 
-if ( _svm_cpu_up(true) )
+if ( svm_cpu_up(true) )
 {
 printk("SVM: failed to initialise.\n");
 return NULL;
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 7854802..2b20d03 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -603,7 +603,7 @@ void vmx_cpu_dead(unsigned int cpu)
 vmx_pi_desc_fixup(cpu);
 }
 
-int vmx_cpu_up(void)
+int vmx_cpu_up(bool bsp)
 {
 u32 eax, edx;
 int rc, bios_locked, cpu = smp_processor_id();
@@ -652,7 +652,7 @@ int vmx_cpu_up(void)
 
 INIT_LIST_HEAD(_cpu(active_vmcs_list));
 
-if ( (rc = vmx_cpu_up_prepare(cpu)) != 0 )
+if ( bsp && (rc = vmx_cpu_up_prepare(cpu)) != 0 )
 return rc;
 
 switch ( __vmxon(this_cpu(vmxon_region)) )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 67fc85b..41900ef 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2433,7 +2433,7 @@ const struct hvm_function_table * __init start_vmx(void)
 {
 set_in_cr4(X86_CR4_VMXE);
 
-if ( vmx_cpu_up() )
+if ( vmx_cpu_up(true) )
 {
 printk("VMX: failed to initialise.\n");
 return NULL;
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b687e03..cd427e5 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -158,7 +158,7 @@ struct hvm_function_table {
 int  (*cpu_up_prepare)(unsigned int cpu);
 void (*cpu_dead)(unsigned int cpu);
 
-int  (*cpu_up)(void);
+int  (*cpu_up)(bool bsp);
 void (*cpu_down)(void);
 
 /* Copy up to 15 bytes from cached instruction bytes at current rIP. */
@@ -443,7 +443,7 @@ void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
 
 static inline int hvm_cpu_up(void)
 {
-return (hvm_funcs.cpu_up ? hvm_funcs.cpu_up() : 0);
+return (hvm_funcs.cpu_up ? hvm_funcs.cpu_up(false) : 0);
 }
 
 static inline void hvm_cpu_down(void)
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index e3faf78..ccabcc2 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -25,7 +25,7 @@ extern void vmcs_dump_vcpu(struct vcpu *v);
 extern void setup_vmcs_dump(void);
 extern int  vmx_cpu_up_prepare(unsigned int cpu);
 extern void vmx_cpu_dead(unsigned int cpu);
-extern int  vmx_cpu_up(void);
+extern int  vmx_cpu_up(bool bsp);
 extern void vmx_cpu_down(void);
 
 struct vmcs_struct {
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Michael S. Tsirkin]

On Fri, Aug 18, 2017 at 05:00:18PM +0100, Anthony PERARD wrote:
> > > > > 
> > > > > Clean it up after 2.10.
> > > > >   
> > > 
> > > So is the v2 good enough or do I need to resend it?
> > Do you really need it in 2.10?
> > it's only 2 days left till release so unless it's blocker
> > I'd wait till after release and do clean fix.
> 
> It mostly means that someone building QEMU 2.10 would be unable to do
> PCI passthrough hotplug. But PCI PT works fine when the device is added
> before a guest is started. Maybe hotplug can work as well with extra
> steps done in the guest to force to probe for new devices.
> 
> So I would say it is not a blocker, and could be added in the known
> issue of the release notes?

Regressions aren't nice. But risk to working setups isn't nice either.
If you can come up with a patch that obviously limits the effect to xen
only, I'll merge it or ack for merge through Xen tree.

> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Michael S. Tsirkin]

On Fri, Aug 18, 2017 at 04:19:57PM +0200, Igor Mammedov wrote:
> > > > 
> > > > Clean it up after 2.10.
> > > >   
> > 
> > So is the v2 good enough or do I need to resend it?
> Do you really need it in 2.10?
> it's only 2 days left till release so unless it's blocker
> I'd wait till after release and do clean fix.

Well it's a regression isn't it?

> 
> > Thanks,
> > 

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

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

[Tamas K Lengyel]

On Thu, Aug 17, 2017 at 5:50 AM, Alexandru Isaila
 wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
>
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

>
> ---
> Changes since V5:
> - Added the bool allow_userspace to the xc_monitor_guest_request
>  function
> ---
>  tools/libxc/include/xenctrl.h |  2 +-
>  tools/libxc/xc_monitor.c  |  3 ++-
>  xen/arch/x86/hvm/hypercall.c  |  5 +
>  xen/common/monitor.c  |  1 +
>  xen/include/asm-x86/domain.h  | 19 ++-
>  xen/include/public/domctl.h   |  1 +
>  6 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index bde8313..a3d0929 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2021,7 +2021,7 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
> domid_t domain_id,
>  int xc_monitor_descriptor_access(xc_interface *xch, domid_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
> - bool enable, bool sync);
> + bool enable, bool sync, bool allow_userspace);
>  int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b44ce93..a677820 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -147,7 +147,7 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
> domid_t domain_id,
>  }
>
>  int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id, bool 
> enable,
> - bool sync)
> + bool sync, bool allow_userspace)
>  {
>  DECLARE_DOMCTL;
>
> @@ -157,6 +157,7 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
> domain_id, bool enable,
>  : XEN_DOMCTL_MONITOR_OP_DISABLE;
>  domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST;
>  domctl.u.monitor_op.u.guest_request.sync = sync;
> +domctl.u.monitor_op.u.guest_request.allow_userspace = enable ? 
> allow_userspace : false;
>
>  return do_domctl(xch, );
>  }
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index e7238ce..5742dd1 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
>  /* Fallthrough to permission check. */
>  case 4:
>  case 2:
> +if ( currd->arch.monitor.guest_request_userspace_enabled &&
> +eax == __HYPERVISOR_hvm_op &&
> +(mode == 8 ? regs->rdi : regs->ebx) == 
> HVMOP_guest_request_vm_event )
> +break;
> +
>  if ( unlikely(hvm_get_cpl(curr)) )
>  {
>  default:
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 451f42f..20463e0 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct 
> xen_domctl_monitor_op *mop)
>  domain_pause(d);
>  d->monitor.guest_request_sync = mop->u.guest_request.sync;
>  d->monitor.guest_request_enabled = requested_status;
> +d->arch.monitor.guest_request_userspace_enabled = 
> mop->u.guest_request.allow_userspace;
>  domain_unpause(d);
>  break;
>  }
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index c10522b..de02507 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -396,15 +396,16 @@ struct arch_domain
>
>  /* Arch-specific monitor options */
>  struct {
> -unsigned int write_ctrlreg_enabled   : 4;
> -unsigned int write_ctrlreg_sync  : 4;
> -unsigned int write_ctrlreg_onchangeonly  : 4;
> -unsigned int singlestep_enabled  : 1;
> -unsigned int software_breakpoint_enabled : 1;
> -unsigned int debug_exception_enabled : 1;
> -unsigned int debug_exception_sync: 1;
> -unsigned int cpuid_enabled   : 1;
> -unsigned int descriptor_access_enabled   : 1;
> +unsigned int write_ctrlreg_enabled : 
> 4;
> +unsigned int write_ctrlreg_sync: 
> 4;
> +unsigned int 

[Xen-devel] [xen-4.7-testing test] 112685: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112667
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 112667
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112667
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112667
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112667
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 112667
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112667
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112667
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 112667

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112667
 build-arm64-xsm   2 hosts-allocate  broken like 112667
 build-arm64   2 hosts-allocate  broken like 112667
 build-arm64-xsm   3 capture-logsbroken like 112667
 build-arm64   3 capture-logsbroken like 112667
 build-arm64-pvops 3 capture-logsbroken like 112667
 test-xtf-amd64-amd64-1  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112650
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112650
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112667
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112667
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112667
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112667
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 

[Xen-devel] [PATCH v3 4/6] xen: RCU: don't let a CPU with a callback go idle.

[Dario Faggioli]

If a CPU has a callback queued, it must be ready to invoke
it, as soon as all the other CPUs involved in the grace period
has gone through a quiescent state.

But if we let such CPU go idle, we can't really tell when (if!)
it will realize that it is actually time to invoke the callback.
To solve this problem, a CPU that has a callback queued (and has
already gone through a quiescent state itself) will stay online,
until the grace period ends, and the callback can be invoked.

This is similar to what Linux does, and is the second and last
step for fixing the overly long (or infinite!) grace periods.
The problem, though, is that, within Linux, we have the tick,
so, all that is necessary is to not stop the tick for the CPU
(even if it has gone idle). In Xen, there's no tick, so we must
avoid for the CPU to go idle entirely, and let it spin on
rcu_pending(), consuming power and causing overhead.

In this commit, we implement the above, using rcu_needs_cpu(),
in a way similar to how it is used in Linux. This it correct,
useful and not wasteful for CPUs that participate in grace
period, but have not a callback queued. For the ones that
has callbacks, an optimization that avoids having to spin is
introduced in a subsequent change.

Signed-off-by: Dario Faggioli 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/xen/sched.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 5828a01..c116604 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -847,7 +847,8 @@ uint64_t get_cpu_idle_time(unsigned int cpu);
 
 /*
  * Used by idle loop to decide whether there is work to do:
- *  (1) Run softirqs; or (2) Play dead; or (3) Run tasklets.
+ *  (1) Deal with RCU; (2) or run softirqs; or (3) Play dead;
+ *  or (4) Run tasklets.
  *
  * About (3), if a tasklet is enqueued, it will be scheduled
  * really really soon, and hence it's pointless to try to
@@ -855,7 +856,8 @@ uint64_t get_cpu_idle_time(unsigned int cpu);
  * the tasklet_work_to_do() helper).
  */
 #define cpu_is_haltable(cpu)\
-(!softirq_pending(cpu) &&   \
+(!rcu_needs_cpu(cpu) && \
+ !softirq_pending(cpu) &&   \
  cpu_online(cpu) && \
  !per_cpu(tasklet_work_to_do, cpu))
 


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

[Xen-devel] [PATCH v3 0/6] xen: RCU: x86/ARM: Add support of rcu_idle_{enter, exit}

[Dario Faggioli]

Hey,

I know, v2 of this series just went out. But since I leave for 2 weeks, I
wanted the version with as much as possible comments addressed to be on the
list, and since it was rather quick to do that (and test it), for latest Tim's
comment, here I am.

So, basically, this is v2, as here:

 https://lists.xen.org/archives/html/xen-devel/2017-08/msg01881.html

But with, as Tim suggested, the idle_cpumask initialized to "all clear". The
various CPUs, therefore, are considered busy when they come up, and clear their
own bit in the mask, as soon as they enter the idle loop for the first time
(which is pretty soon). Doing like this, we close another window for a
potential (although, rather unlikely) race/unnecessary extension of the grace
period, and we simplify the code (a.k.a. 'win-win' :-D).

Regards,
Dario
---
Dario Faggioli (6):
  xen: in do_softirq() sample smp_processor_id() once and for all.
  xen: ARM: suspend the tick (if in use) when going idle.
  xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.
  xen: RCU: don't let a CPU with a callback go idle.
  xen: RCU: avoid busy waiting until the end of grace period.
  xen: try to prevent idle timer from firing too often.

 xen/arch/arm/domain.c |   29 +++---
 xen/arch/x86/cpu/mwait-idle.c |3 -
 xen/common/rcupdate.c |  123 -
 xen/common/schedule.c |4 +
 xen/common/softirq.c  |8 +--
 xen/include/xen/perfc_defn.h  |2 +
 xen/include/xen/rcupdate.h|6 ++
 xen/include/xen/sched.h   |6 +-
 8 files changed, 159 insertions(+), 22 deletions(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH v3 5/6] xen: RCU: avoid busy waiting until the end of grace period.

[Dario Faggioli]

On the CPU where a callback is queued, cpu_is_haltable()
returns false (due to rcu_needs_cpu() being itself false).
That means the CPU would spin inside idle_loop(), continuously
calling do_softirq(), and, in there, continuously checking
rcu_pending(), in a tight loop.

Let's instead allow the CPU to really go idle, but make sure,
by arming a timer, that we periodically check whether the
grace period has come to an ended. As the period of the
timer, we pick a value that makes thing look like what
happens in Linux, with the periodic tick (as this code
comes from there).

Note that the timer will *only* be armed on CPUs that are
going idle while having queued RCU callbacks. On CPUs that
don't, there won't be any timer, and their sleep won't be
interrupted (and even for CPUs with callbacks, we only
expect an handful of wakeups at most, but that depends on
the system load, as much as from other things).

Signed-off-by: Dario Faggioli 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: George Dunlap 
Cc: Julien Grall 
---
Changes from v1:
* clarified changelog;
* fix style/indentation issues;
* deal with RCU idle timer in tick suspension logic;
* as a consequence of the point above, the timer now fires, so kill
  the ASSERT_UNREACHABLE, and put a perfcounter there (to count the
  times it triggers);
* add a comment about the value chosen for programming the idle timer;
* avoid pointless/bogus '!!' and void* casts;
* rearrange the rcu_needs_cpu() return condition;
* add a comment to clarify why we don't want to check rcu_pending()
  in rcu_idle_timer_start().
---
 xen/arch/x86/cpu/mwait-idle.c |3 +-
 xen/common/rcupdate.c |   72 -
 xen/common/schedule.c |2 +
 xen/include/xen/perfc_defn.h  |2 +
 xen/include/xen/rcupdate.h|3 ++
 5 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 762dff1..b6770ea 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -741,9 +741,8 @@ static void mwait_idle(void)
}
 
cpufreq_dbs_timer_suspend();
-
sched_tick_suspend();
-   /* sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. */
+   /* Timer related operations can raise TIMER_SOFTIRQ. Process it now. */
process_pending_softirqs();
 
/* Interrupts must be disabled for C2 and higher transitions. */
diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index 12ae7da..871936f 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -84,8 +84,37 @@ struct rcu_data {
 int cpu;
 struct rcu_head barrier;
 longlast_rs_qlen; /* qlen during the last resched */
+
+/* 3) idle CPUs handling */
+struct timer idle_timer;
+bool idle_timer_active;
 };
 
+/*
+ * If a CPU with RCU callbacks queued goes idle, when the grace period is
+ * not finished yet, how can we make sure that the callbacks will eventually
+ * be executed? In Linux (2.6.21, the first "tickless idle" Linux kernel),
+ * the periodic timer tick would not be stopped for such CPU. Here in Xen,
+ * we (may) don't even have a periodic timer tick, so we need to use a
+ * special purpose timer.
+ *
+ * Such timer:
+ * 1) is armed only when a CPU with an RCU callback(s) queued goes idle
+ *before the end of the current grace period (_not_ for any CPUs that
+ *go idle!);
+ * 2) when it fires, it is only re-armed if the grace period is still
+ *running;
+ * 3) it is stopped immediately, if the CPU wakes up from idle and
+ *resumes 'normal' execution.
+ *
+ * About how far in the future the timer should be programmed each time,
+ * it's hard to tell (guess!!). Since this mimics Linux's periodic timer
+ * tick, take values used there as an indication. In Linux 2.6.21, tick
+ * period can be 10ms, 4ms, 3.33ms or 1ms. Let's use 10ms, to enable
+ * at least some power saving on the CPU that is going idle.
+ */
+#define RCU_IDLE_TIMER_PERIOD MILLISECS(10)
+
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
 
 static int blimit = 10;
@@ -404,7 +433,45 @@ int rcu_needs_cpu(int cpu)
 {
 struct rcu_data *rdp = _cpu(rcu_data, cpu);
 
-return (!!rdp->curlist || rcu_pending(cpu));
+return (rdp->curlist && !rdp->idle_timer_active) || rcu_pending(cpu);
+}
+
+/*
+ * Timer for making sure the CPU where a callback is queued does
+ * periodically poke rcu_pedning(), so that it will invoke the callback
+ * not too late after the end of the grace period.
+ */
+void rcu_idle_timer_start()
+{
+struct rcu_data *rdp = 

[Xen-devel] [PATCH v3 6/6] xen: try to prevent idle timer from firing too often.

[Dario Faggioli]

Idea is: the more CPUs are still active in a grace period,
the more we can wait to check whether it's time to invoke
the callbacks (on those CPUs that have already quiesced,
are idle, and have callbacks queued).

What we're trying to avoid is one of those idle CPUs to
wake up, only to discover that the grace period is still
running, and that it hence could have be slept longer
(saving more power).

This patch implements an heuristic aimed at achieving
that, at the price of having to call cpumask_weight() on
the 'entering idle' path, on CPUs with queued callbacks.

Of course, we, at the same time, don't want to delay
recognising that we can invoke the callbacks for too
much, so we also set a maximum.

Signed-off-by: Dario Faggioli 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
---
 xen/common/rcupdate.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index 871936f..5a3cb1d 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -110,10 +110,17 @@ struct rcu_data {
  * About how far in the future the timer should be programmed each time,
  * it's hard to tell (guess!!). Since this mimics Linux's periodic timer
  * tick, take values used there as an indication. In Linux 2.6.21, tick
- * period can be 10ms, 4ms, 3.33ms or 1ms. Let's use 10ms, to enable
- * at least some power saving on the CPU that is going idle.
+ * period can be 10ms, 4ms, 3.33ms or 1ms.
+ *
+ * That being said, we can assume that, the more CPUs are still active in
+ * the current grace period, the longer it will take for it to come to its
+ * end. We wait 10ms for each active CPU, as minimizing the wakeups enables
+ * more effective power saving, on the CPU that has gone idle. But we also
+ * never wait more than 100ms, to avoid delaying recognising the end of a
+ * grace period (and the invocation of the callbacks) by too much.
  */
-#define RCU_IDLE_TIMER_PERIOD MILLISECS(10)
+#define RCU_IDLE_TIMER_CPU_DELAY  MILLISECS(10)
+#define RCU_IDLE_TIMER_PERIOD_MAX MILLISECS(100)
 
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
 
@@ -444,6 +451,7 @@ int rcu_needs_cpu(int cpu)
 void rcu_idle_timer_start()
 {
 struct rcu_data *rdp = _cpu(rcu_data);
+s_time_t next;
 
 /*
  * Note that we don't check rcu_pending() here. In fact, we don't want
@@ -453,7 +461,9 @@ void rcu_idle_timer_start()
 if (likely(!rdp->curlist))
 return;
 
-set_timer(>idle_timer, NOW() + RCU_IDLE_TIMER_PERIOD);
+next = min_t(s_time_t, RCU_IDLE_TIMER_PERIOD_MAX,
+ cpumask_weight(_ctrlblk.cpumask) * 
RCU_IDLE_TIMER_CPU_DELAY);
+set_timer(>idle_timer, NOW() + next);
 rdp->idle_timer_active = true;
 }
 


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

[Xen-devel] [PATCH v3 3/6] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Dario Faggioli]

Xen is a tickless (micro-)kernel, i.e., when a CPU becomes
idle there is no timer tick that will periodically wake the
CPU up.
OTOH, when we imported RCU from Linux, Linux was (on x86) a
ticking kernel, i.e., there was a periodic timer tick always
running, even on idle CPUs. This was bad for power consumption,
but, for instance, made it easy to monitor the quiescent states
of all the CPUs, and hence tell when RCU grace periods ended.

In Xen, that is impossible, and that's particularly problematic
when the system is very lightly loaded, as some CPUs may never
have the chance to tell the RCU core logic about their quiescence,
and grace periods could extend indefinitely!

This has led, on x86, to long (and unpredictable) delays between
RCU callbacks queueing and their actual invokation. On ARM, we've
even seen infinite grace periods (e.g., complate_domain_destroy()
never being actually invoked!). See here:

 https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg02454.html

The first step for fixing this situation is for RCU to record,
at the beginning of a grace period, which CPUs are already idle.
In fact, being idle, they can't be in the middle of any read-side
critical section, and we don't have to wait for their quiescence.

This is tracked in a cpumask, in a similar way to how it was also
done in Linux (on s390, which was tickless already). It is also
basically the same approach used for making Linux x86 tickless,
in 2.6.21 on (see commit 79bf2bb3 "tick-management: dyntick /
highres functionality").

For correctness, wee also add barriers. One is also present in
Linux, (see commit c3f59023, "Fix RCU race in access of nohz_cpu_mask",
although, we change the code comment to something that makes better
sense for us). The other (which is its pair), is put in the newly
introduced function rcu_idle_enter(), right after updating the
cpumask. They prevent races between CPUs going idle during the
beginning of a grace period.

Signed-off-by: Dario Faggioli 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
---
Changes from v2:
* initialize idle_cpumask to "all clear", i.e., all the CPUs are busy;
  they'll clear their bit out themselves as soon as the run the idle
  loop (pretty soon anyway).

Changes from v1:
* call rcu_idle_{enter,exit}() from tick suspension/restarting logic.  This
  widen the window during which a CPU has its bit set in the idle cpumask.
  During review, it was suggested to do the opposite (narrow it), and that's
  what I did first. But then, I changed my mind, as doing things as they look
  now (wide window), cures another pre-existing (and independent) raca which
  Tim discovered, still during v1 review;
* add a barrier in rcu_idle_enter() too, to properly deal with the race Tim
  pointed out during review;
* mark CPU where RCU initialization happens, at boot, as non-idle.
---
 xen/common/rcupdate.c  |   41 +++--
 xen/common/schedule.c  |2 ++
 xen/include/xen/rcupdate.h |3 +++
 3 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index 8cc5a82..12ae7da 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -52,7 +52,8 @@ static struct rcu_ctrlblk {
 int  next_pending;  /* Is the next batch already waiting? */
 
 spinlock_t  lock __cacheline_aligned;
-cpumask_t   cpumask; /* CPUs that need to switch in order*/
+cpumask_t   cpumask; /* CPUs that need to switch in order ... */
+cpumask_t   idle_cpumask; /* ... unless they are already idle */
 /* for current batch to proceed.*/
 } __cacheline_aligned rcu_ctrlblk = {
 .cur = -300,
@@ -248,7 +249,16 @@ static void rcu_start_batch(struct rcu_ctrlblk *rcp)
 smp_wmb();
 rcp->cur++;
 
-cpumask_copy(>cpumask, _online_map);
+   /*
+* Make sure the increment of rcp->cur is visible so, even if a
+* CPU that is about to go idle, is captured inside rcp->cpumask,
+* rcu_pending() will return false, which then means cpu_quiet()
+* will be invoked, before the CPU would actually enter idle.
+*
+* This barrier is paired with the one in rcu_idle_enter().
+*/
+smp_mb();
+cpumask_andnot(>cpumask, _online_map, >idle_cpumask);
 }
 }
 
@@ -474,7 +484,34 @@ static struct notifier_block cpu_nfb = {
 void __init rcu_init(void)
 {
 void *cpu = (void *)(long)smp_processor_id();
+
+cpumask_clear(_ctrlblk.idle_cpumask);
 cpu_callback(_nfb, CPU_UP_PREPARE, cpu);
 register_cpu_notifier(_nfb);
 open_softirq(RCU_SOFTIRQ, 

[Xen-devel] [PATCH v3 2/6] xen: ARM: suspend the tick (if in use) when going idle.

[Dario Faggioli]

Since commit 964fae8ac ("cpuidle: suspend/resume scheduler
tick timer during cpu idle state entry/exit"), if a scheduler
has a periodic tick timer, we stop it when going idle.

This, however, is only true for x86. Make it true for ARM as
well.

Signed-off-by: Dario Faggioli 
Reviewed-by: Stefano Stabellini 
---
Cc: Julien Grall 
---
 xen/arch/arm/domain.c |   29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index eeebbdb..2160d2b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -39,6 +39,25 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
+static void do_idle(void)
+{
+unsigned int cpu = smp_processor_id();
+
+sched_tick_suspend();
+/* sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. */
+process_pending_softirqs();
+
+local_irq_disable();
+if ( cpu_is_haltable(cpu) )
+{
+dsb(sy);
+wfi();
+}
+local_irq_enable();
+
+sched_tick_resume();
+}
+
 void idle_loop(void)
 {
 unsigned int cpu = smp_processor_id();
@@ -52,15 +71,7 @@ void idle_loop(void)
 if ( unlikely(tasklet_work_to_do(cpu)) )
 do_tasklet();
 else
-{
-local_irq_disable();
-if ( cpu_is_haltable(cpu) )
-{
-dsb(sy);
-wfi();
-}
-local_irq_enable();
-}
+do_idle();
 
 do_softirq();
 /*


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

[Xen-devel] [PATCH v3 1/6] xen: in do_softirq() sample smp_processor_id() once and for all.

[Dario Faggioli]

In fact, right now, we read it at every iteration of the loop.
The reason it's done like this is how context switch was handled
on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).

However:
1) we don't have IA64 any longer, and all the achitectures that
   we do support, are ok with sampling once and for all;
2) sampling at every iteration (slightly) affect performance;
3) sampling at every iteration is misleading, as it makes people
   believe that it is currently possible that SCHEDULE_SOFTIRQ
   moves the execution flow on another CPU (and the comment,
   by reinforcing this belief, makes things even worse!).

Therefore, let's:
- do the sampling only once, and remove the comment;
- leave an ASSERT() around, so that, if context switching
  logic changes (in current or new arches), we will notice.

[1] Some more (historical) information here:

http://old-list-archives.xenproject.org/archives/html/xen-devel/2006-06/msg01262.html

Signed-off-by: Dario Faggioli 
Reviewed-by: George Dunlap 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Tim Deegan 
---
This has been submitted already, as a part of another series. Discussion is 
here:
 https://lists.xen.org/archives/html/xen-devel/2017-06/msg00102.html

For the super lazy, Jan's latest word in that thread were these:
 "I've voiced my opinion, but I don't mean to block the patch. After
  all there's no active issue the change introduces."
 (https://lists.xen.org/archives/html/xen-devel/2017-06/msg00797.html)

Since then:
- changed "once and for all" with "only once", as requested by George (and
  applied his Reviewed-by, as he said I could).
---
 xen/common/softirq.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/xen/common/softirq.c b/xen/common/softirq.c
index ac12cf8..67c84ba 100644
--- a/xen/common/softirq.c
+++ b/xen/common/softirq.c
@@ -27,16 +27,12 @@ static DEFINE_PER_CPU(unsigned int, batching);
 
 static void __do_softirq(unsigned long ignore_mask)
 {
-unsigned int i, cpu;
+unsigned int i, cpu = smp_processor_id();
 unsigned long pending;
 
 for ( ; ; )
 {
-/*
- * Initialise @cpu on every iteration: SCHEDULE_SOFTIRQ may move
- * us to another processor.
- */
-cpu = smp_processor_id();
+ASSERT(cpu == smp_processor_id());
 
 if ( rcu_pending(cpu) )
 rcu_check_callbacks(cpu);


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

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[Roger Pau Monné]

On Fri, Aug 18, 2017 at 10:29:15AM -0400, annie li wrote:
> 
> On 8/18/2017 5:14 AM, Roger Pau Monné wrote:
> > On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:
> > > If there is inflight I/O in any non-last queue, blkback returns -EBUSY
> > > directly, and never stops thread of remaining queue and processs them. 
> > > When
> > > removing vbd device with lots of disk I/O load, some queues with inflight
> > > I/O still have blkback thread running even though the corresponding vbd
> > > device or guest is gone.
> > > And this could cause some problems, for example, if the backend device 
> > > type
> > > is file, some loop devices and blkback thread always lingers there forever
> > > after guest is destroyed, and this causes failure of umounting 
> > > repositories
> > > unless rebooting the dom0. So stop all threads properly and return -EBUSY
> > > if any queue has inflight I/O.
> > > 
> > > Signed-off-by: Annie Li 
> > > Reviewed-by: Herbert van den Bergh 
> > > Reviewed-by: Bhavesh Davda 
> > > Reviewed-by: Adnan Misherfi 
> > > ---
> > >   drivers/block/xen-blkback/xenbus.c | 10 --
> > >   1 file changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkback/xenbus.c 
> > > b/drivers/block/xen-blkback/xenbus.c
> > > index 792da68..2adb859 100644
> > > --- a/drivers/block/xen-blkback/xenbus.c
> > > +++ b/drivers/block/xen-blkback/xenbus.c
> > > @@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif 
> > > *blkif)
> > >   {
> > >   struct pending_req *req, *n;
> > >   unsigned int j, r;
> > > + bool busy = false;
> > >   for (r = 0; r < blkif->nr_rings; r++) {
> > >   struct xen_blkif_ring *ring = >rings[r];
> > > @@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif 
> > > *blkif)
> > >* don't have any discard_io or other_io requests. So, 
> > > checking
> > >* for inflight IO is enough.
> > >*/
> > > - if (atomic_read(>inflight) > 0)
> > > - return -EBUSY;
> > > + if (atomic_read(>inflight) > 0) {
> > > + busy = true;
> > > + continue;
> > > + }
> > I guess I'm missing something, but I don't see how this is solving the
> > problem described in the description.
> > 
> > If the problem is that xen_blkif_disconnect returns without cleaning
> > all the queues, this patch keeps the current behavior, just that it
> > will try to remove more queues before returning, as opposed to
> > returning when finding the first busy queue.
> Before checking inflight, following code stops the blkback thread,
> if (ring->xenblkd) {
> kthread_stop(ring->xenblkd);
> wake_up(>shutdown_wq);
> }
> This patch allows thread of every queue has the chance to get stopped.
> Otherwise, only thread of queue before(including) first busy one get
> stopped, threads of remaining queue will still run, and these blkthread and
> corresponding loop device will linger forever even after guest is destroyed.

Thanks for the explanation:

Acked-by: Roger Pau Monné 

Roger.

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

[Xen-devel] [PATCH] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

[Zhongze Liu]

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:

  commit 20e725e9364cff4a29945f66986ecd88cca8743d

Now add the wrapper to XENMEM_remove_from_physmap.

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxc/include/xenctrl.h |  4 
 tools/libxc/xc_domain.c   | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8f36..0ff15a9255 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1381,6 +1381,10 @@ int xc_domain_add_to_physmap_batch(xc_interface *xch,
xen_pfn_t *gfpns,
int *errs);
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn);
+
 int xc_domain_populate_physmap(xc_interface *xch,
uint32_t domid,
unsigned long nr_extents,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8bab..e6b32792c0 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1077,6 +1077,17 @@ out:
 return rc;
 }
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn)
+{
+struct xen_remove_from_physmap xrfp = {
+.domid = domid,
+.gpfn = gpfn,
+};
+return do_memory_op(xch, XENMEM_remove_from_physmap, , sizeof(xrfp));
+}
+
 int xc_domain_claim_pages(xc_interface *xch,
uint32_t domid,
unsigned long nr_pages)
-- 
2.14.0


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

Re: [Xen-devel] [PATCH v2 3/6] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Dario Faggioli]

On Thu, 2017-08-17 at 14:03 +0100, Tim Deegan wrote:
> At 18:45 +0200 on 16 Aug (1502909149), Dario Faggioli wrote:
> > +
> > +/*
> > + * The CPU is becoming idle, so no more read side critical
> > + * sections, and one more step toward grace period.
> > + */
> > +void rcu_idle_enter(unsigned int cpu)
> > +{
> > +/*
> > + * During non-boot CPU bringup and resume, until this function
> > is
> > + * called for the first time, it's fine to find our bit
> > already set.
> > + */
> > +ASSERT(!cpumask_test_cpu(cpu, _ctrlblk.idle_cpumask) ||
> > +   (system_state < SYS_STATE_active || system_state >=
> > SYS_STATE_resume));
> 
> Does every newly started CPU immediately idle?  If not, then it might
> run in an RCU read section but excluded from the grace period
> mechanism.
> 
They do call startup_cpu_idle_loop() pretty soon, yes (right at the end
of start_secondary(), on both x86 and ARM). But technically, yes, there
is a window for that.

> It seems like it would be better to start with the idle_cpumask
> empty,
> and rely on online_cpumask to exclude CPUs that aren't running.
>
I thought about that too, but then ended up doing it the other way
(i.e., having the mask fully set).

Now, I just tried to initialize it to "all clear"... It works, and I
have to admit that I like it better. :-)

As I'm going on vacations for a couple of weeks, I'll send v3 right
now, with just this changed, so it could even be checked-in, if others
too are happy with this, and the rest of the patches (if not, we'll
talk about it when I'm back :-P).

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

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: Skip check apic_id_limit for Xen

[Paolo Bonzini]

On 18/08/2017 18:38, Eduardo Habkost wrote:
>>> I think you still need to do a check for vIOMMU being enabled.
>>
>> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
>> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
>> Xen tool stack.
>
> Shouldn't we make QEMU have knowledge of the vIOMMU device, then?
> Won't QEMU need to know about it eventually?

No, it actually makes sense since Xen hosts all system-wide interrupt
sources outside QEMU, unlike KVM which only hosts the (per-CPU) local APIC.

Paolo

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112699
 build-arm64   2 hosts-allocate  broken like 112699
 build-arm64-pvops 3 capture-logsbroken like 112699
 build-arm64   3 capture-logsbroken like 112699
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a
baseline version:
 xen  85d6028a8fd7807162e189e5e32e71642cb62519

Last test of basis   112699  2017-08-18 13:01:23 Z0 days
Testing same since   112700  2017-08-18 15:02:00 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a
+ . ./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 
08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a
+ branch=xen-unstable-smoke
+ revision=08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a
+ . ./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.9-testing
+ '[' x08143c5b6c1fc1e67e0d86cbff09aa3c2d46b93a = 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
++ : 

Re: [Xen-devel] [PATCH] x86: Skip check apic_id_limit for Xen

[Eduardo Habkost]

On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
> On 2017年08月16日 19:21, Paolo Bonzini wrote:
> > On 16/08/2017 02:22, Lan Tianyu wrote:
> >> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
> >> check for Xen here when vcpu number is more than 255.
> > 
> > I think you still need to do a check for vIOMMU being enabled.
> 
> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
> Xen tool stack.

Shouldn't we make QEMU have knowledge of the vIOMMU device, then?
Won't QEMU need to know about it eventually?

-- 
Eduardo

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3a424c5f49239b810e08aa23368945a9f0360d4c
baseline version:
 ovmf d75b8ac278bc9f0159aa7eb9a92fd2cc87a18d8c

Last test of basis   112671  2017-08-16 18:47:30 Z1 days
Testing same since   112687  2017-08-17 14:40:19 Z1 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Dandan Bi 
  Eric Dong 
  Hao Wu 
  Jiaxin Wu 
  Laszlo Ersek 
  Marvin H?user 
  Marvin Haeuser 
  Wu Jiaxin 

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

Re: [Xen-devel] "MMIO emulation failed" from booting OVMF on Xen v4.9.0

[Andrew Cooper]

On 18/08/17 16:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 16, 2017 at 06:47:23PM +, Andri Möll wrote:
>
>> (d1) Invoking OVMF ...
>> (XEN) MMIO emulation failed: d1v0 16bit @ f000:ff54 -> 66 ea 5c ff ff ff 
>> 10 00 b8 40 06 00 00 0f 22
> That code is:
> cripts/decodecode 
> Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22
> Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22
> sed: -e expression #1, char 1: unknown command: `-'
>
> Code starting with the faulting instruction
> ===
>0:   66 ea   data16 (bad) 
>2:   5c  pop%rsp
>3:   ff  (bad)  
>4:   ff  (bad)  
>5:   ff 10   callq  *(%rax)
>7:   00 b8 40 06 00 00   add%bh,0x640(%rax)
>d:   0f  .byte 0xf
>e:   22  .byte 0x22
>
> Which looks to be garbage.

That is because you're disassembling it as 64bit code, not 16. :)

The offending instruction is actually ljmpl $0x10,$0xff5c, and is
almost certainly following a write to CR0 which enables protected mode.

0xea is not valid in 64bit mode.  Decoding it is already complicated
because it takes two adjacent immediate operands, with the offset
encoded before the segment. There is no "immediate operand override"
prefix in x86, so making the instruction usable in a 64bit code segment
is tricky.  Given how rarely it is used, I expect AMD decided it wasn't
worth the effort or silicon trying to make it work.

~Andrew

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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Anthony PERARD]

On Fri, Aug 18, 2017 at 04:19:57PM +0200, Igor Mammedov wrote:
> On Fri, 18 Aug 2017 14:31:07 +0100
> Anthony PERARD  wrote:
> 
> > On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> > > On Fri, 18 Aug 2017 04:40:02 +0300
> > > "Michael S. Tsirkin"  wrote:
> > >   
> > > > On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:  
> > > > > This means that the function will be call and the property
> > > > > acpi-pcihp-bsel will be set even if ACPI build is disable.
> > > > > 
> > > > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to 
> > > > > be
> > > > > set, but this was done only when ACPI tables are built which is not
> > > > > needed for a Xen guest. The need for the property starts with commit
> > > > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > > > 
> > > > > Reported-by: Sander Eikelenboom 
> > > > > Signed-off-by: Anthony PERARD 
> > > > > 
> > > > > ---
> > > > > Changes in V3:
> > > > >   - move acpi_set_pci_info to pcihp instead
> > > > > 
> > > > > Changes in V2:
> > > > >   - check for acpi_enabled before calling acpi_set_pci_info.
> > > > >   - set the property on the root bus only.
> > > > > 
> > > > > This patch would be a canditade to backport to 2.9, along with
> > > > > "hw/acpi: Limit hotplug to root bus on legacy mode"
> > > > > 
> > > > > CC: Stefano Stabellini 
> > > > > CC: Bruce Rogers 
> > > > > ---
> > > > >  hw/acpi/pcihp.c  | 31 +++
> > > > >  hw/i386/acpi-build.c | 32 
> > > > >  2 files changed, 31 insertions(+), 32 deletions(-)
> > > > > 
> > > > > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > > > > index 9db3c2eaf2..44e8842db8 100644
> > > > > --- a/hw/acpi/pcihp.c
> > > > > +++ b/hw/acpi/pcihp.c
> > > > > @@ -75,6 +75,36 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
> > > > >  }
> > > > >  }
> > > > >  
> > > > > +/* Assign BSEL property to all buses.  In the future, this can be 
> > > > > changed
> > > > > + * to only assign to buses that support hotplug.
> > > > > + */
> > > > > +static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> > > > > +{
> > > > > +unsigned *bsel_alloc = opaque;
> > > > > +unsigned *bus_bsel;
> > > > > +
> > > > > +if (qbus_is_hotpluggable(BUS(bus))) {
> > > > > +bus_bsel = g_malloc(sizeof *bus_bsel);
> > > > > +
> > > > > +*bus_bsel = (*bsel_alloc)++;
> > > > > +object_property_add_uint32_ptr(OBJECT(bus), 
> > > > > ACPI_PCIHP_PROP_BSEL,
> > > > > +   bus_bsel, _abort);
> > > > > +}
> > > > > +
> > > > > +return bsel_alloc;
> > > > > +}
> > > > > +
> > > > > +static void acpi_set_pci_info(void)
> > > > > +{
> > > > > +PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> > > > > +unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> > > > > +
> > > > > +if (bus) {
> > > > > +/* Scan all PCI buses. Set property to enable acpi based 
> > > > > hotplug. */
> > > > > +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > > > > _alloc);
> > > > > +}
> > > > > +}
> > > > > +
> > > > >  static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
> > > > >  {
> > > > >  AcpiPciHpFind *find = opaque;
> > > > > @@ -177,6 +207,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
> > > > >  
> > > > >  void acpi_pcihp_reset(AcpiPciHpState *s)
> > > > >  {
> > > > > +acpi_set_pci_info();
> > > > >  acpi_pcihp_update(s);
> > > > >  }
> > > > 
> > > > IIUC doing this on reset will add property over and over again leaking
> > > > memory.  
> > > in v2 I've explicitly suggested to call it once, like:  
> > 
> > Sorry I misunderstood. I'll fix it.
> > 
> > > acpi_set_pci_info() {
> > > 
> > >static bool bsel_is set;
> > > 
> > >if (bsel_is set)
> > >return;
> > >bsel_is set = true;
> > > 
> > >...
> > > }
> > > 
> > > not patch related:
> > > BTW bsel assignment is not stable in hotplug + migration use case,
> > > and we probably should fix it up in 2.11 (CCing Marcel)
> > >   
> > > > I think that we need to do it on machine done.
> > > > 
> > > > Igor,  I think reordering acpi-build like earlier version did
> > > > is less intrusive and more appropriate for 2.10.
> > > > 
> > > > For 2.10 I would like to see ideally some changes that
> > > > are all if (xen) making it obvious non xen is not
> > > > affected. I can then ack it and it will be merged in xen tree.  
> > > it didn't work before so I'd just push fix to 2.11 without
> > > intermediate fix.
> > > But if you guys think it's worth to fix in 2.10, I'm fine with v2
> > > for it if Anthony will take care of it (rebase this series)
> > > in 2.11 merge window.  
> > 
> > Yes, I can take care of this series for 2.11, and find out 

Re: [Xen-devel] "MMIO emulation failed" from booting OVMF on Xen v4.9.0

[Konrad Rzeszutek Wilk]

On Wed, Aug 16, 2017 at 06:47:23PM +, Andri Möll wrote:
> Hey,
> 
> As per Andrew [Cooper]'s suggestion, writing here instead of #xen on
> Freenode.
> 
> I'm trying out Xen (4.9.0) with OVMF (r21243.3858b4a1ff-1) and having it

OK, so this is
ommit 3858b4a1ff09d3243fea8d07bd135478237cb8f7
Author: Ard Biesheuvel 
Date:   Wed Mar 1 18:34:33 2017 +

ArmPlatformPkg/PlatformIntelBdsLib: don't clobber ConSplitter handle

Which looks to be done right after the 4MB increase. What is 
the side of the binary blob?

> crash right on boot both with the 32b and 64b OVMF binaries. This is on Arch

Did you build them as RELEASE or DEBUG?

> Linux, AMD Ryzen on a X370 motherboard.
> 
> Given the following minimal VM declaration:
> > builder = "hvm"
> > maxmem = 512
> > memory = 512
> > vcpus = 1
> > on_poweroff = "destroy"
> > on_reboot = "destroy"
> > on_crash = "destroy"
> > bios = "ovmf"
> > device_model_version = "qemu-xen"
> > bios_path_override = "/usr/share/ovmf/ovmf_code_ia32.bin"
> and running it with `xl create vm.cfg`, I see it crash while booting with
> the following displayed by `xl dmesg`:
> 
> > (XEN) MMIO emulation failed: d1v0 16bit @ f000:ff54 -> 66 ea 5c ff
> > ff ff 10 00 b8 40 06 00 00 0f 22
> > (XEN) d1v0 Triple fault - invoking HVM shutdown action 1
> I've run the hypervisor with `guest_loglvl=all` for more output and attached
> it here and uploaded it at
> https://gist.github.com/moll/a46dffc7466ced93a0365a6916a4db96 in case the
> file doesn't go through.
> 
> Any ideas anyone? Thanks in advance!
> 
> Andri

> (XEN) HVM1 save: CPU
> (XEN) HVM1 save: PIC
> (XEN) HVM1 save: IOAPIC
> (XEN) HVM1 save: LAPIC
> (XEN) HVM1 save: LAPIC_REGS
> (XEN) HVM1 save: PCI_IRQ
> (XEN) HVM1 save: ISA_IRQ
> (XEN) HVM1 save: PCI_LINK
> (XEN) HVM1 save: PIT
> (XEN) HVM1 save: RTC
> (XEN) HVM1 save: HPET
> (XEN) HVM1 save: PMTIMER
> (XEN) HVM1 save: MTRR
> (XEN) HVM1 save: VIRIDIAN_DOMAIN
> (XEN) HVM1 save: CPU_XSAVE
> (XEN) HVM1 save: VIRIDIAN_VCPU
> (XEN) HVM1 save: VMCE_VCPU
> (XEN) HVM1 save: TSC_ADJUST
> (XEN) HVM1 save: CPU_MSR
> (XEN) HVM1 restore: CPU 0
> (d1) HVM Loader
> (d1) Detected Xen v4.9.0
> (d1) Xenbus rings @0xfeffc000, event channel 1
> (d1) System requested OVMF
> (d1) CPU speed is 3001 MHz
> (d1) Relocating guest memory for lowmem MMIO space disabled
> (d1) PCI-ISA link 0 routed to IRQ5
> (d1) PCI-ISA link 1 routed to IRQ10
> (d1) PCI-ISA link 2 routed to IRQ11
> (d1) PCI-ISA link 3 routed to IRQ5
> (d1) pci dev 01:3 INTA->IRQ10
> (d1) pci dev 02:0 INTA->IRQ11
> (d1) No RAM in high memory; setting high_mem resource base to 1
> (d1) pci dev 03:0 bar 10 size 00200: 0f008
> (d1) pci dev 02:0 bar 14 size 00100: 0f208
> (d1) pci dev 03:0 bar 30 size 1: 0f300
> (d1) pci dev 03:0 bar 14 size 01000: 0f301
> (d1) pci dev 02:0 bar 10 size 00100: 0c001
> (d1) pci dev 01:1 bar 20 size 00010: 0c101
> (d1) Multiprocessor initialisation:
> (d1)  - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> (d1) Writing SMBIOS tables ...
> (d1) Loading OVMF ...
> (XEN) d1v0 Over-allocation for domain 1: 131329 > 131328
> (d1) Loading ACPI ...
> (d1) CONV disabled
> (d1) vm86 TSS at fc00a400
> (d1) BIOS map:
> (d1)  ffe0-fffd: Main BIOS
> (d1) E820 table:
> (d1)  [00]: : - :000a: RAM
> (d1)  HOLE: :000a - :000f
> (d1)  [01]: :000f - :0010: RESERVED
> (d1)  [02]: :0010 - :1f715000: RAM
> (d1)  HOLE: :1f715000 - :fc00
> (d1)  [03]: :fc00 - 0001:: RESERVED
> (d1) Invoking OVMF ...
> (XEN) MMIO emulation failed: d1v0 16bit @ f000:ff54 -> 66 ea 5c ff ff ff 
> 10 00 b8 40 06 00 00 0f 22

That code is:
cripts/decodecode 
Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22
Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22
sed: -e expression #1, char 1: unknown command: `-'

Code starting with the faulting instruction
===
   0:   66 ea   data16 (bad) 
   2:   5c  pop%rsp
   3:   ff  (bad)  
   4:   ff  (bad)  
   5:   ff 10   callq  *(%rax)
   7:   00 b8 40 06 00 00   add%bh,0x640(%rax)
   d:   0f  .byte 0xf
   e:   22  .byte 0x22

Which looks to be garbage.

Also can you share what version of compiler you are using GCC?

And did you build the OVMF out of tree or use the Makefile and such that
came with Xen?

There is a way to get an good idea of where things are going bad by
cranked the debug up and making an special port be pipped to
a file (which you should be able to do with the crafty usage of extra
guest config parameters).

> (XEN) d1v0 Triple fault - invoking HVM shutdown action 1
> (XEN) *** Dumping Dom1 vcpu#0 state: ***
> (XEN) [ Xen-4.9.0  x86_64  debug=n   Not tainted 

[Xen-devel] [PATCH v2 1/4] xen: credit2: implement utilization cap

[Dario Faggioli]

This commit implements the Xen part of the cap mechanism for
Credit2.

A cap is how much, in terms of % of physical CPU time, a domain
can execute at most.

For instance, a domain that must not use more than 1/4 of
one physical CPU, must have a cap of 25%; one that must not
use more than 1+1/2 of physical CPU time, must be given a cap
of 150%.

Caps are per domain, so it is all a domain's vCPUs, cumulatively,
that will be forced to execute no more than the decided amount.

This is implemented by giving each domain a 'budget', and
using a (per-domain again) periodic timer. Values of budget
and 'period' are chosen so that budget/period is equal to the
cap itself.

Budget is burned by the domain's vCPUs, in a similar way to
how credits are.

When a domain runs out of budget, its vCPUs can't run any
longer. They can gain, when the budget is replenishment by
the timer, which event happens once every period.

Blocking the vCPUs because of lack of budget happens by
means of a new (_VPF_parked) pause flag, so that, e.g.,
vcpu_runnable() still works. This is similar to what is
done in sched_rtds.c, as opposed to what happens in
sched_credit.c, where vcpu_pause() and vcpu_unpause()
(which means, among other things, more overhead).

Note that, while adding new fields to csched2_vcpu and
csched2_dom, currently existing members are being moved
around, to achieve best placement inside cache lines.

Note also that xenalyze and tools/xentrace/format are being
updated too.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Anshul Makkar 
---
Changed from v1:
* used has_cap() instead of open coding it in burn_credits();
* removed some of the unlikely() around has_cap(), as, although cap is not on
  by default, it's up to the user to decide how many domains will have caps,
  and we can't assume much about what users will actually do;
* tried to clarify the comment about (the non deterministic nature of the)
  CPU capacity distribution between the vCPUs of a multi-vCPUs guest;
* clarified the comment about budget being replenished to nothing more than
  top capacity, i.e., about the fact that budget is *not* being accumulated
  across different period;
* fixed many style and typo issues in comments;
* added a comment about the budget distribution logic (to the vCPUs) being
  subject to be refined in subsequent commits;
* renaming:
   vcpu_try_to_get_budget() --> vcpu_grab_budget()
   vcpu_give_back_budget() --> vcpu_return_budget()
   repl_sdom_budget() --> replanish_domain_budget()
* change how replenishment logic deals with cases of overrun. In v1, we were
  always doing multiple replenishment at once, until the domain's budget was
  back into the black. Now, in cases of substantial overrun, we just do one
  replenishment, and rely on future ones to bring back the budget into
  being a positive number. This was agreed upon with George during v1's
  review.
---
 tools/xentrace/formats |2 
 tools/xentrace/xenalyze.c  |   10 +
 xen/common/sched_credit2.c |  521 +---
 xen/include/xen/sched.h|3 
 4 files changed, 492 insertions(+), 44 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index f39182a..d6e7e3f 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -51,7 +51,7 @@
 
 0x00022201  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tick
 0x00022202  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_pos   [ 
dom:vcpu = 0x%(1)08x, pos = %(2)d]
-0x00022203  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit burn[ 
dom:vcpu = 0x%(1)08x, credit = %(2)d, delta = %(3)d ]
+0x00022203  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit burn[ 
dom:vcpu = 0x%(1)08x, credit = %(2)d, budget = %(3)d, delta = %(4)d ]
 0x00022204  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit_add
 0x00022205  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle_check   [ 
dom:vcpu = 0x%(1)08x, credit = %(2)d, score = %(3)d ]
 0x00022206  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle [ cpu = 
%(1)d ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 39fc35f..79bdba7 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7680,12 +7680,14 @@ void sched_process(struct pcpu_info *p)
 if(opt.dump_all) {
 struct {
 unsigned int vcpuid:16, domid:16;
-int credit, delta;
+int credit, budget, delta;
 } *r = (typeof(r))ri->d;
 
-printf(" %s csched2:burn_credits d%uv%u, credit = %d, delta = 
%d\n",
-   ri->dump_header, r->domid, r->vcpuid,
-   r->credit, 

[Xen-devel] [PATCH v2 4/4] libxl/xl: allow to get and set cap on Credit2.

[Dario Faggioli]

Note that a cap is considered valid only if
it is within the [1, nr_vcpus]% interval.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxl/libxl_sched.c |   21 +
 tools/xl/xl_cmdtable.c|1 +
 tools/xl/xl_sched.c   |   25 +
 3 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_sched.c b/tools/libxl/libxl_sched.c
index faa604e..7d144d0 100644
--- a/tools/libxl/libxl_sched.c
+++ b/tools/libxl/libxl_sched.c
@@ -405,6 +405,7 @@ static int sched_credit2_domain_get(libxl__gc *gc, uint32_t 
domid,
 libxl_domain_sched_params_init(scinfo);
 scinfo->sched = LIBXL_SCHEDULER_CREDIT2;
 scinfo->weight = sdom.weight;
+scinfo->cap = sdom.cap;
 
 return 0;
 }
@@ -413,8 +414,17 @@ static int sched_credit2_domain_set(libxl__gc *gc, 
uint32_t domid,
 const libxl_domain_sched_params *scinfo)
 {
 struct xen_domctl_sched_credit2 sdom;
+xc_domaininfo_t info;
 int rc;
 
+rc = xc_domain_getinfolist(CTX->xch, domid, 1, );
+if (rc < 0) {
+LOGED(ERROR, domid, "Getting domain info");
+return ERROR_FAIL;
+}
+if (rc != 1 || info.domain != domid)
+return ERROR_INVAL;
+
 rc = xc_sched_credit2_domain_get(CTX->xch, domid, );
 if (rc != 0) {
 LOGED(ERROR, domid, "Getting domain sched credit2");
@@ -430,6 +440,17 @@ static int sched_credit2_domain_set(libxl__gc *gc, 
uint32_t domid,
 sdom.weight = scinfo->weight;
 }
 
+if (scinfo->cap != LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT) {
+if (scinfo->cap < 0
+|| scinfo->cap > (info.max_vcpu_id + 1) * 100) {
+LOGD(ERROR, domid, "Cpu cap out of range, "
+ "valid range is from 0 to %d for specified number of vcpus",
+ ((info.max_vcpu_id + 1) * 100));
+return ERROR_INVAL;
+}
+sdom.cap = scinfo->cap;
+}
+
 rc = xc_sched_credit2_domain_set(CTX->xch, domid, );
 if ( rc < 0 ) {
 LOGED(ERROR, domid, "Setting domain sched credit2");
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 2c71a9f..bfe6eb0 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -265,6 +265,7 @@ struct cmd_spec cmd_table[] = {
   "[-d  [-w[=WEIGHT]]] [-p CPUPOOL]",
   "-d DOMAIN, --domain=DOMAIN Domain to modify\n"
   "-w WEIGHT, --weight=WEIGHT Weight (int)\n"
+  "-c CAP,--cap=CAP   Cap (int)\n"
   "-s --schedparamQuery / modify scheduler parameters\n"
   "-r RLIMIT, --ratelimit_us=RLIMIT Set the scheduling rate limit, in 
microseconds\n"
   "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
diff --git a/tools/xl/xl_sched.c b/tools/xl/xl_sched.c
index 85722fe..7fabce3 100644
--- a/tools/xl/xl_sched.c
+++ b/tools/xl/xl_sched.c
@@ -209,7 +209,7 @@ static int sched_credit2_domain_output(int domid)
 libxl_domain_sched_params scinfo;
 
 if (domid < 0) {
-printf("%-33s %4s %6s\n", "Name", "ID", "Weight");
+printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
 return 0;
 }
 
@@ -219,10 +219,11 @@ static int sched_credit2_domain_output(int domid)
 return 1;
 }
 domname = libxl_domid_to_name(ctx, domid);
-printf("%-33s %4d %6d\n",
+printf("%-33s %4d %6d %4d\n",
 domname,
 domid,
-scinfo.weight);
+scinfo.weight,
+scinfo.cap);
 free(domname);
 libxl_domain_sched_params_dispose();
 return 0;
@@ -589,21 +590,23 @@ int main_sched_credit2(int argc, char **argv)
 const char *dom = NULL;
 const char *cpupool = NULL;
 int ratelimit = 0;
-int weight = 256;
+int weight = 256, cap = 0;
 bool opt_s = false;
 bool opt_r = false;
 bool opt_w = false;
+bool opt_c = false;
 int opt, rc;
 static struct option opts[] = {
 {"domain", 1, 0, 'd'},
 {"weight", 1, 0, 'w'},
+{"cap", 1, 0, 'c'},
 {"schedparam", 0, 0, 's'},
 {"ratelimit_us", 1, 0, 'r'},
 {"cpupool", 1, 0, 'p'},
 COMMON_LONG_OPTS
 };
 
-SWITCH_FOREACH_OPT(opt, "d:w:p:r:s", opts, "sched-credit2", 0) {
+SWITCH_FOREACH_OPT(opt, "d:w:c:p:r:s", opts, "sched-credit2", 0) {
 case 'd':
 dom = optarg;
 break;
@@ -611,6 +614,10 @@ int main_sched_credit2(int argc, char **argv)
 weight = strtol(optarg, NULL, 10);
 opt_w = true;
 break;
+case 'c':
+cap = strtol(optarg, NULL, 10);
+opt_c = true;
+break;
 case 's':
 opt_s = true;
 break;
@@ -623,12 +630,12 @@ int main_sched_credit2(int argc, char **argv)
 break;
 }
 
-if (cpupool && (dom || opt_w)) {
+if (cpupool && (dom || opt_w || opt_c)) {
 

[Xen-devel] [PATCH v2 3/4] xen: credit2: improve distribution of budget (for domains with caps)

[Dario Faggioli]

Instead of letting the vCPU that for first tries to get
some budget take it all (although temporarily), allow each
vCPU to only get a specific quota of the total budget.

This improves fairness, allows for more parallelism, and
prevents vCPUs from not being able to get any budget (e.g.,
because some other vCPU always comes before and gets it all)
for one or more period, and hence starve (and cause troubles
in guest kernels, such as livelocks, triggering of whatchdogs,
etc.).

Signed-off-by: Dario Faggioli 
Reviewed-by: George Dunlap 
---
Cc: Anshul Makkar 
---
Changes from v1:
- typos;
- spurious hunk moved to previous patch.
---
 xen/common/sched_credit2.c |   56 
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ce70224..211e2d6 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -522,6 +522,8 @@ struct csched2_vcpu {
 unsigned flags;/* Status flags (16 bits would be ok,  
*/
 s_time_t budget;   /* Current budget (if domains has cap) 
*/
/* but clear_bit() does not like that) 
*/
+s_time_t budget_quota; /* Budget to which vCPU is entitled
*/
+
 s_time_t start_time;   /* Time we were scheduled (for credit) 
*/
 
 /* Individual contribution to load
*/
@@ -1791,17 +1793,16 @@ static bool vcpu_grab_budget(struct csched2_vcpu *svc)
 
 if ( sdom->budget > 0 )
 {
-/*
- * NB: we give the whole remaining budget a domain has, to the first
- * vCPU that comes here and asks for it. This means that, in a domain
- * with a cap, only 1 vCPU is able to run, at any given time.
- * /THIS IS GOING TO CHANGE/ in subsequent patches, toward something
- * that allows much better fairness and parallelism. Proceeding in
- * two steps, is for making things easy to understand, when looking
- * at the signle commits.
- */
-svc->budget = sdom->budget;
-sdom->budget = 0;
+s_time_t budget;
+
+/* Get our quota, if there's at least as much budget */
+if ( likely(sdom->budget >= svc->budget_quota) )
+budget = svc->budget_quota;
+else
+budget = sdom->budget;
+
+svc->budget = budget;
+sdom->budget -= budget;
 }
 else
 {
@@ -2036,6 +2037,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
vcpu *vc, void *dd)
 svc->tickled_cpu = -1;
 
 svc->budget = STIME_MAX;
+svc->budget_quota = 0;
 INIT_LIST_HEAD(>parked_elem);
 
 SCHED_STAT_CRANK(vcpu_alloc);
@@ -2822,6 +2824,9 @@ csched2_dom_cntl(
 /* Cap */
 if ( op->u.credit2.cap != 0 )
 {
+struct csched2_vcpu *svc;
+spinlock_t *lock;
+
 /* Cap is only valid if it's below 100 * nr_of_vCPUS */
 if ( op->u.credit2.cap > 100 * sdom->nr_vcpus )
 {
@@ -2834,6 +2839,26 @@ csched2_dom_cntl(
 sdom->tot_budget /= 100;
 spin_unlock(>budget_lock);
 
+/*
+ * When trying to get some budget and run, each vCPU will grab
+ * from the pool 1/N (with N = nr of vCPUs of the domain) of
+ * the total budget. Roughly speaking, this means each vCPU will
+ * have at least one chance to run during every period.
+ */
+for_each_vcpu ( d, v )
+{
+svc = csched2_vcpu(v);
+lock = vcpu_schedule_lock(svc->vcpu);
+/*
+ * Too small quotas would in theory cause a lot of overhead,
+ * which then won't happen because, in csched2_runtime(),
+ * CSCHED2_MIN_TIMER is what would be used anyway.
+ */
+svc->budget_quota = max(sdom->tot_budget / sdom->nr_vcpus,
+CSCHED2_MIN_TIMER);
+vcpu_schedule_unlock(lock, svc->vcpu);
+}
+
 if ( sdom->cap == 0 )
 {
 /*
@@ -2865,9 +2890,8 @@ csched2_dom_cntl(
  */
 for_each_vcpu ( d, v )
 {
-struct csched2_vcpu *svc = csched2_vcpu(v);
-spinlock_t *lock = vcpu_schedule_lock(svc->vcpu);
-
+svc = csched2_vcpu(v);
+lock = vcpu_schedule_lock(svc->vcpu);
 if ( v->is_running )
 {
 unsigned int cpu = v->processor;
@@ -2917,6 +2941,7 @@ csched2_dom_cntl(
 spinlock_t *lock = vcpu_schedule_lock(svc->vcpu);
 
 svc->budget = STIME_MAX;
+svc->budget_quota = 0;
 
   

[Xen-devel] [PATCH v2 2/4] xen: credit2: allow to set and get utilization cap

[Dario Faggioli]

As cap is already present in Credit1, as a parameter, all
the wiring is there already for it to be percolate down
to csched2_dom_cntl() too.

In this commit, we actually deal with it, and implement
setting, changing or disabling the cap of a domain.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Anshul Makkar 
---
Changes from v1:
- check that cap is below 100*nr_vcpus;
- do multiplication first when computing the domain's budget, given the cap;
- when disabling cap, take the budget lock for manipulating the list of
  parked vCPUs. Things would have been safe without it, but it's just
  more linear, more robust and more future-proof, to "do thing properly".
---
 xen/common/sched_credit2.c  |  129 +--
 xen/include/public/domctl.h |1 
 2 files changed, 125 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 69a7679..ce70224 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2772,30 +2772,35 @@ csched2_dom_cntl(
 struct csched2_dom * const sdom = csched2_dom(d);
 struct csched2_private *prv = csched2_priv(ops);
 unsigned long flags;
+struct vcpu *v;
 int rc = 0;
 
 /*
  * Locking:
  *  - we must take the private lock for accessing the weights of the
- *vcpus of d,
+ *vcpus of d, and/or the cap;
  *  - in the putinfo case, we also need the runqueue lock(s), for
  *updating the max waight of the runqueue(s).
+ *If changing the cap, we also need the budget_lock, for updating
+ *the value of the domain budget pool (and the runqueue lock,
+ *for adjusting the parameters and rescheduling any vCPU that is
+ *running at the time of the change).
  */
 switch ( op->cmd )
 {
 case XEN_DOMCTL_SCHEDOP_getinfo:
 read_lock_irqsave(>lock, flags);
 op->u.credit2.weight = sdom->weight;
+op->u.credit2.cap = sdom->cap;
 read_unlock_irqrestore(>lock, flags);
 break;
 case XEN_DOMCTL_SCHEDOP_putinfo:
+write_lock_irqsave(>lock, flags);
+/* Weight */
 if ( op->u.credit2.weight != 0 )
 {
-struct vcpu *v;
 int old_weight;
 
-write_lock_irqsave(>lock, flags);
-
 old_weight = sdom->weight;
 
 sdom->weight = op->u.credit2.weight;
@@ -2813,9 +2818,123 @@ csched2_dom_cntl(
 
 vcpu_schedule_unlock(lock, svc->vcpu);
 }
+}
+/* Cap */
+if ( op->u.credit2.cap != 0 )
+{
+/* Cap is only valid if it's below 100 * nr_of_vCPUS */
+if ( op->u.credit2.cap > 100 * sdom->nr_vcpus )
+{
+rc = -EINVAL;
+break;
+}
+
+spin_lock(>budget_lock);
+sdom->tot_budget = (CSCHED2_BDGT_REPL_PERIOD * op->u.credit2.cap);
+sdom->tot_budget /= 100;
+spin_unlock(>budget_lock);
+
+if ( sdom->cap == 0 )
+{
+/*
+ * We give to the domain the budget to which it is entitled,
+ * and queue its first replenishment event.
+ *
+ * Since cap is currently disabled for this domain, we
+ * know no vCPU is messing with the domain's budget, and
+ * the replenishment timer is still off.
+ * For these reasons, it is safe to do the following without
+ * taking the budget_lock.
+ */
+sdom->budget = sdom->tot_budget;
+sdom->next_repl = NOW() + CSCHED2_BDGT_REPL_PERIOD;
+set_timer(sdom->repl_timer, sdom->next_repl);
+
+/*
+ * Now, let's enable budget accounting for all the vCPUs.
+ * For making sure that they will start to honour the domain's
+ * cap, we set their budget to 0.
+ * This way, as soon as they will try to run, they will have
+ * to get some budget.
+ *
+ * For the vCPUs that are already running, we trigger the
+ * scheduler on their pCPU. When, as a consequence of this,
+ * csched2_schedule() will run, it will figure out there is
+ * no budget, and the vCPU will try to get some (and be parked,
+ * if there's none, and we'll switch to someone else).
+ */
+for_each_vcpu ( d, v )
+{
+struct csched2_vcpu *svc = csched2_vcpu(v);
+spinlock_t 

[Xen-devel] [PATCH v2 0/4] xen/tools: Credit2: implement caps.

[Dario Faggioli]

This is v2 of the 'caps for Credit2' series.

Posting of v1 is here:

 https://lists.xen.org/archives/html/xen-devel/2017-06/msg00700.html

No change wrt that, apart from taking care of the review comments. The patch
that required more rework is patch 1, as I changed how a corner case (budget
overrun, due to potential timer or accounting issues) is dealt with, complying
with what George suggested and thought it was best.

Note, however, that this series is *NOT* based on top of staging. In fact, it
is based on top of staging + "Soft affinity for Credit2, v2":

 https://lists.xen.org/archives/html/xen-devel/2017-07/msg02802.html

Reason I did things like this is that the two series do clash, and since the
soft affinity one is pretty much all acked and ready to go in (with the only
exception of patch 2, as George still needs to look at it), I just assumed that
one will go in first, and based on top of it.

In fact, as I'm leaving for 2 weeks, having done things like this allows one to
commit both the series, even with me away, in case both collect all the needed
acks, of course (hey, one can dream, can't him? :-D :-D).

As usual, I aslo prepared a git branch:

 git://xenbits.xen.org/people/dariof/xen.git  rel/sched/credit2-caps-v2
 https://travis-ci.org/fdario/xen/builds/266018957

Thanks and Regards,
Dario
---
Dario Faggioli (4):
  xen: credit2: implement utilization cap
  xen: credit2: allow to set and get utilization cap
  xen: credit2: improve distribution of budget (for domains with caps)
  libxl/xl: allow to get and set cap on Credit2.

 tools/libxl/libxl_sched.c   |   21 +
 tools/xentrace/formats  |2 
 tools/xentrace/xenalyze.c   |   10 -
 tools/xl/xl_cmdtable.c  |1 
 tools/xl/xl_sched.c |   25 +-
 xen/common/sched_credit2.c  |  676 ---
 xen/include/public/domctl.h |1 
 xen/include/xen/sched.h |3 
 8 files changed, 682 insertions(+), 57 deletions(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [xen-4.8-testing test] 112684: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112664
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112664
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112664
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112664
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 112664
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 112664
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112664
 test-amd64-amd64-pygrub  10 debian-di-installfail REGR. vs. 112664
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 112664

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112664
 build-arm64-xsm   2 hosts-allocate  broken like 112664
 build-arm64   2 hosts-allocate  broken like 112664
 build-arm64-pvops 3 capture-logsbroken like 112664
 build-arm64-xsm   3 capture-logsbroken like 112664
 build-arm64   3 capture-logsbroken like 112664
 test-xtf-amd64-amd64-1  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112664
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112664
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112664
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112664
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Tim Deegan]

At 09:04 -0600 on 18 Aug (1503047077), Jan Beulich wrote:
> >>> On 18.08.17 at 16:47,  wrote:
> > At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> >> >>> On 16.08.17 at 18:47,  wrote:
> >> > On 16/08/17 16:23, Jan Beulich wrote:
> >> > On 16.08.17 at 13:22,  wrote:
> >> >>> --- a/xen/arch/x86/mm/shadow/multi.c
> >> >>> +++ b/xen/arch/x86/mm/shadow/multi.c
> >> >>> @@ -3112,7 +3112,6 @@ static int sh_page_fault(struct vcpu *v,
> >> >>>   * will make sure no inconsistent mapping being translated into
> >> >>>   * shadow page table. */
> >> >>>  version = 
> >> >>> atomic_read(>arch.paging.shadow.gtable_dirty_version);
> >> >>> -rmb();
> >> >>>  walk_ok = sh_walk_guest_tables(v, va, , error_code);
> >> >> Isn't this supposed to make sure version is being read first? I.e.
> >> >> doesn't this at least need to be barrier()?
> >> > 
> >> > atomic_read() is not free to be reordered by the compiler.  It is an asm
> >> > volatile with a volatile memory reference.
> >> 
> >> Oh, right - I did forget about the volatiles there (since generally,
> >> like in Linux, we appear to try to avoid volatile).
> > 
> > FWIW, I don't think that's quite right.  The GCC docs I have say that
> > "volatile" will stop the compiler from omitting an asm altogether, or
> > hoisting it out of a loop (on the assumption that it will always
> > produce the same output for the same inputs).  And that "the compiler
> > can move even volatile 'asm' instructions relative to other code,
> > including across jump instructions."
> 
> Oh, I had talked about the volatile qualifiers, no the volatile asm-s.

I'm not sure what other volatile you mean here, but accesses to
volatile objects are only ordered WRT other _volatile_ accesses.
So, e.g.: https://godbolt.org/g/L2qa8h

Tim.

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

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Tim Deegan]

At 15:47 +0100 on 18 Aug (1503071247), Tim Deegan wrote:
> At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> > >>> On 16.08.17 at 18:47,  wrote:
> > > atomic_read() is not free to be reordered by the compiler.  It is an asm
> > > volatile with a volatile memory reference.
> > 
> > Oh, right - I did forget about the volatiles there (since generally,
> > like in Linux, we appear to try to avoid volatile).
> 
> FWIW, I don't think that's quite right.  The GCC docs I have say that
> "volatile" will stop the compiler from omitting an asm altogether, or
> hoisting it out of a loop (on the assumption that it will always
> produce the same output for the same inputs).  And that "the compiler
> can move even volatile 'asm' instructions relative to other code,
> including across jump instructions."

...and indeed: https://godbolt.org/g/KW19QR

Tim.

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

Re: [Xen-devel] [PATCH v2] hvm: vmx/svm_cpu_up_prepare should be called only once

[Boris Ostrovsky]

On 08/17/2017 02:07 PM, Andrew Cooper wrote:
> On 17/08/17 17:51, Boris Ostrovsky wrote:
>> @@ -1589,7 +1585,7 @@ const struct hvm_function_table * __init 
>> start_svm(void)
>>  
>>  svm_host_osvw_reset();
>>  
>> -if ( _svm_cpu_up(true) )
>> +if ( svm_cpu_up_prepare(smp_processor_id()) || _svm_cpu_up(true) )
> Both of these could pass 0 rather than smp_processor_id(), but either
> way, Reviewed-by: Andrew Cooper 


This patch breaks VMX on Intel, let me rework it.

-boris



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

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Jan Beulich]

>>> On 18.08.17 at 16:47,  wrote:
> At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
>> >>> On 16.08.17 at 18:47,  wrote:
>> > On 16/08/17 16:23, Jan Beulich wrote:
>> > On 16.08.17 at 13:22,  wrote:
>> >>> --- a/xen/arch/x86/mm/shadow/multi.c
>> >>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> >>> @@ -3112,7 +3112,6 @@ static int sh_page_fault(struct vcpu *v,
>> >>>   * will make sure no inconsistent mapping being translated into
>> >>>   * shadow page table. */
>> >>>  version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
>> >>> -rmb();
>> >>>  walk_ok = sh_walk_guest_tables(v, va, , error_code);
>> >> Isn't this supposed to make sure version is being read first? I.e.
>> >> doesn't this at least need to be barrier()?
>> > 
>> > atomic_read() is not free to be reordered by the compiler.  It is an asm
>> > volatile with a volatile memory reference.
>> 
>> Oh, right - I did forget about the volatiles there (since generally,
>> like in Linux, we appear to try to avoid volatile).
> 
> FWIW, I don't think that's quite right.  The GCC docs I have say that
> "volatile" will stop the compiler from omitting an asm altogether, or
> hoisting it out of a loop (on the assumption that it will always
> produce the same output for the same inputs).  And that "the compiler
> can move even volatile 'asm' instructions relative to other code,
> including across jump instructions."

Oh, I had talked about the volatile qualifiers, no the volatile asm-s.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112686
 build-arm64   2 hosts-allocate  broken like 112686
 build-arm64-pvops 3 capture-logsbroken like 112686
 build-arm64   3 capture-logsbroken like 112686
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  85d6028a8fd7807162e189e5e32e71642cb62519
baseline version:
 xen  c39cf093fc7de5eb3c8bc2bee0cd3078d4049947

Last test of basis   112686  2017-08-17 14:01:16 Z1 days
Testing same since   112699  2017-08-18 13:01:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

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

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Tim Deegan]

At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote:
> >>> On 16.08.17 at 18:47,  wrote:
> > On 16/08/17 16:23, Jan Beulich wrote:
> > On 16.08.17 at 13:22,  wrote:
> >>> --- a/xen/arch/x86/mm/shadow/multi.c
> >>> +++ b/xen/arch/x86/mm/shadow/multi.c
> >>> @@ -3112,7 +3112,6 @@ static int sh_page_fault(struct vcpu *v,
> >>>   * will make sure no inconsistent mapping being translated into
> >>>   * shadow page table. */
> >>>  version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
> >>> -rmb();
> >>>  walk_ok = sh_walk_guest_tables(v, va, , error_code);
> >> Isn't this supposed to make sure version is being read first? I.e.
> >> doesn't this at least need to be barrier()?
> > 
> > atomic_read() is not free to be reordered by the compiler.  It is an asm
> > volatile with a volatile memory reference.
> 
> Oh, right - I did forget about the volatiles there (since generally,
> like in Linux, we appear to try to avoid volatile).

FWIW, I don't think that's quite right.  The GCC docs I have say that
"volatile" will stop the compiler from omitting an asm altogether, or
hoisting it out of a loop (on the assumption that it will always
produce the same output for the same inputs).  And that "the compiler
can move even volatile 'asm' instructions relative to other code,
including across jump instructions."

Cheers,

Tim.

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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

[Andre Przywara]

Hi,

On 18/08/17 15:21, Julien Grall wrote:
> 
> 
> On 17/08/17 18:06, Andre Przywara wrote:
>> Hi,
> 
> Hi Andre,
> 
>> On 11/08/17 15:10, Julien Grall wrote:
>>> Hi Andre,
>>> 
>>> On 21/07/17 20:59, Andre Przywara wrote:
 Since the GICs MMIO access always covers a number of IRQs at
 once, introduce wrapper functions which loop over those IRQs,
 take their locks and read or update the priority values. This
 will be used in a later patch.
 
 Signed-off-by: Andre Przywara  --- 
 xen/arch/arm/vgic.c| 37
 + 
 xen/include/asm-arm/vgic.h |  5 + 2 files changed, 42
 insertions(+)
 
 diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index
 434b7e2..b2c9632 100644 --- a/xen/arch/arm/vgic.c +++
 b/xen/arch/arm/vgic.c @@ -243,6 +243,43 @@ static int
 vgic_get_virq_priority(struct vcpu *v, unsigned int virq) 
 return ACCESS_ONCE(rank->priority[virq &
 INTERRUPT_RANK_MASK]); }
 
 +#define MAX_IRQS_PER_IPRIORITYR 4
>>> 
>>> The name gives the impression that you may have IPRIORITYR with
>>> only 1 IRQ. But this is not true. The registers is always 4.
>>> However, you are able to access using byte or word.
>>> 
 +uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int
 nrirqs,
>>> 
>>> I am well aware that the vgic code is mixing between virq and
>>> irq. Moving forward, we should use virq to avoid confusion.
>>> 
 + unsigned int first_irq)
>>> 
>>> Please stay consistent, with the naming. Either nr_irqs/first_irq
>>> or nrirqs/firstirq. But not a mix.
>>> 
>>> Also, it makes more sense to describe first the start then
>>> number.
>>> 
 +{ +struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR]; +
 unsigned long flags; +uint32_t ret = 0, i; + +
 local_irq_save(flags); +vgic_lock_irqs(v, nrirqs,
 first_irq, pirqs);
>>> 
>>> I am not convinced on the usefulness of taking all the locks in
>>> one go. At one point in the time, you only need to lock a given
>>> pending_irq.
>> 
>> I don't think so. The MMIO access a guest does is expected to be
>> atomic, so it expects to read the priorities of the four interrupts
>> as they were *at one point in time*. This issue is more obvious for
>> the enabled bit, for instance, but also here a (32-bit) read and a
>> write of some IPRIORITYR might race against each other. This was
>> covered by the rank lock before, but now we have to bite the bullet
>> and lock all involved IRQs.
> 
> A well-behaved guest would need a lock in order to modify the
> hardware as it can't predict in which order the write will happen. If
> the guest does not respect that I don't think you it is necessary to
> require atomicity of the modification.
> 
> This is making the code more complex for a little benefits and also 
> increase the duration of the interrupt masked.
> 
> So as long as it does not affect the hypervisor, then I think it is
> fine to not handle more than the atomicity at the IRQ level.

Fair enough, I can live with that. I didn't like the added complexity
for the tiny benefit either, just wanted to retain the behaviour we had
naturally with the rank lock before.
So this is definitely true for IPRIORITYR, ICFGR and friends, but I need
to double check on ISENABLER/ICENABLER, because of the OR/AND-NOT
semantics, which allows lockless accesses from the software side. I
believe this is fine, though.

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[annie li]

On 8/18/2017 5:14 AM, Roger Pau Monné wrote:

On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:

If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
device or guest is gone.
And this could cause some problems, for example, if the backend device type
is file, some loop devices and blkback thread always lingers there forever
after guest is destroyed, and this causes failure of umounting repositories
unless rebooting the dom0. So stop all threads properly and return -EBUSY
if any queue has inflight I/O.

Signed-off-by: Annie Li 
Reviewed-by: Herbert van den Bergh 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Adnan Misherfi 
---
  drivers/block/xen-blkback/xenbus.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 792da68..2adb859 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
  {
struct pending_req *req, *n;
unsigned int j, r;
+   bool busy = false;
  
  	for (r = 0; r < blkif->nr_rings; r++) {

struct xen_blkif_ring *ring = >rings[r];
@@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 * don't have any discard_io or other_io requests. So, checking
 * for inflight IO is enough.
 */
-   if (atomic_read(>inflight) > 0)
-   return -EBUSY;
+   if (atomic_read(>inflight) > 0) {
+   busy = true;
+   continue;
+   }

I guess I'm missing something, but I don't see how this is solving the
problem described in the description.

If the problem is that xen_blkif_disconnect returns without cleaning
all the queues, this patch keeps the current behavior, just that it
will try to remove more queues before returning, as opposed to
returning when finding the first busy queue.

Before checking inflight, following code stops the blkback thread,
if (ring->xenblkd) {
kthread_stop(ring->xenblkd);
wake_up(>shutdown_wq);
}
This patch allows thread of every queue has the chance to get stopped. 
Otherwise, only thread of queue before(including) first busy one get 
stopped, threads of remaining queue will still run, and these blkthread 
and corresponding loop device will linger forever even after guest is 
destroyed.


Thanks
Annie


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

Re: [Xen-devel] [PATCH] xen/x86/shadow: adjust barriers around gtable_dirty_version.

[Andrew Cooper]

On 18/08/17 15:23, Tim Deegan wrote:
> Use the smp_ variants, as we're only synchronizing against other CPUs.
>
> Add a write barrier before incrementing the version.
>
> x86's memory ordering rules and the presence of various out-of-unit
> function calls mean that this code worked OK before, and the barriers
> are mostly decorative.
>
> Signed-off-by: Tim Deegan 

Thanks!

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/mm/shadow/multi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index c9c2252..f8a8928 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -206,6 +206,7 @@ shadow_check_gwalk(struct vcpu *v, unsigned long va, 
> walk_t *gw, int version)
>  
>  ASSERT(paging_locked_by_me(d));
>  
> +/* No need for smp_rmb() here; taking the paging lock was enough. */
>  if ( version == atomic_read(>arch.paging.shadow.gtable_dirty_version) 
> )
>   return 1;
>  
> @@ -3112,7 +3113,7 @@ static int sh_page_fault(struct vcpu *v,
>   * will make sure no inconsistent mapping being translated into
>   * shadow page table. */
>  version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
> -rmb();
> +smp_rmb();
>  walk_ok = sh_walk_guest_tables(v, va, , error_code);
>  
>  #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
> @@ -3188,6 +3189,7 @@ static int sh_page_fault(struct vcpu *v,
>   * overlapping with this one may be inconsistent
>   */
>  perfc_incr(shadow_rm_write_flush_tlb);
> +smp_wmb();
>  atomic_inc(>arch.paging.shadow.gtable_dirty_version);
>  flush_tlb_mask(d->domain_dirty_cpumask);
>  }


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

[Xen-devel] [PATCH] xen/x86/shadow: adjust barriers around gtable_dirty_version.

[Tim Deegan]

Use the smp_ variants, as we're only synchronizing against other CPUs.

Add a write barrier before incrementing the version.

x86's memory ordering rules and the presence of various out-of-unit
function calls mean that this code worked OK before, and the barriers
are mostly decorative.

Signed-off-by: Tim Deegan 
---
 xen/arch/x86/mm/shadow/multi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index c9c2252..f8a8928 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -206,6 +206,7 @@ shadow_check_gwalk(struct vcpu *v, unsigned long va, walk_t 
*gw, int version)
 
 ASSERT(paging_locked_by_me(d));
 
+/* No need for smp_rmb() here; taking the paging lock was enough. */
 if ( version == atomic_read(>arch.paging.shadow.gtable_dirty_version) )
  return 1;
 
@@ -3112,7 +3113,7 @@ static int sh_page_fault(struct vcpu *v,
  * will make sure no inconsistent mapping being translated into
  * shadow page table. */
 version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
-rmb();
+smp_rmb();
 walk_ok = sh_walk_guest_tables(v, va, , error_code);
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -3188,6 +3189,7 @@ static int sh_page_fault(struct vcpu *v,
  * overlapping with this one may be inconsistent
  */
 perfc_incr(shadow_rm_write_flush_tlb);
+smp_wmb();
 atomic_inc(>arch.paging.shadow.gtable_dirty_version);
 flush_tlb_mask(d->domain_dirty_cpumask);
 }
-- 
2.7.4


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

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

[Julien Grall]

On 17/08/17 18:06, Andre Przywara wrote:

Hi,


Hi Andre,


On 11/08/17 15:10, Julien Grall wrote:

Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 37 +
 xen/include/asm-arm/vgic.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 434b7e2..b2c9632 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -243,6 +243,43 @@ static int vgic_get_virq_priority(struct vcpu *v,
unsigned int virq)
 return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
 }

+#define MAX_IRQS_PER_IPRIORITYR 4


The name gives the impression that you may have IPRIORITYR with only 1
IRQ. But this is not true. The registers is always 4. However, you are
able to access using byte or word.


+uint32_t vgic_fetch_irq_priority(struct vcpu *v, unsigned int nrirqs,


I am well aware that the vgic code is mixing between virq and irq.
Moving forward, we should use virq to avoid confusion.


+ unsigned int first_irq)


Please stay consistent, with the naming. Either nr_irqs/first_irq or
nrirqs/firstirq. But not a mix.

Also, it makes more sense to describe first the start then number.


+{
+struct pending_irq *pirqs[MAX_IRQS_PER_IPRIORITYR];
+unsigned long flags;
+uint32_t ret = 0, i;
+
+local_irq_save(flags);
+vgic_lock_irqs(v, nrirqs, first_irq, pirqs);


I am not convinced on the usefulness of taking all the locks in one go.
At one point in the time, you only need to lock a given pending_irq.


I don't think so. The MMIO access a guest does is expected to be atomic,
so it expects to read the priorities of the four interrupts as they were
*at one point in time*.
This issue is more obvious for the enabled bit, for instance, but also
here a (32-bit) read and a write of some IPRIORITYR might race against
each other. This was covered by the rank lock before, but now we have to
bite the bullet and lock all involved IRQs.


A well-behaved guest would need a lock in order to modify the hardware 
as it can't predict in which order the write will happen. If the guest 
does not respect that I don't think you it is necessary to require 
atomicity of the modification.


This is making the code more complex for a little benefits and also 
increase the duration of the interrupt masked.


So as long as it does not affect the hypervisor, then I think it is fine 
to not handle more than the atomicity at the IRQ level.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Igor Mammedov]

On Fri, 18 Aug 2017 14:31:07 +0100
Anthony PERARD  wrote:

> On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> > On Fri, 18 Aug 2017 04:40:02 +0300
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:  
> > > > This means that the function will be call and the property
> > > > acpi-pcihp-bsel will be set even if ACPI build is disable.
> > > > 
> > > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > > > set, but this was done only when ACPI tables are built which is not
> > > > needed for a Xen guest. The need for the property starts with commit
> > > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > > 
> > > > Reported-by: Sander Eikelenboom 
> > > > Signed-off-by: Anthony PERARD 
> > > > 
> > > > ---
> > > > Changes in V3:
> > > >   - move acpi_set_pci_info to pcihp instead
> > > > 
> > > > Changes in V2:
> > > >   - check for acpi_enabled before calling acpi_set_pci_info.
> > > >   - set the property on the root bus only.
> > > > 
> > > > This patch would be a canditade to backport to 2.9, along with
> > > > "hw/acpi: Limit hotplug to root bus on legacy mode"
> > > > 
> > > > CC: Stefano Stabellini 
> > > > CC: Bruce Rogers 
> > > > ---
> > > >  hw/acpi/pcihp.c  | 31 +++
> > > >  hw/i386/acpi-build.c | 32 
> > > >  2 files changed, 31 insertions(+), 32 deletions(-)
> > > > 
> > > > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > > > index 9db3c2eaf2..44e8842db8 100644
> > > > --- a/hw/acpi/pcihp.c
> > > > +++ b/hw/acpi/pcihp.c
> > > > @@ -75,6 +75,36 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
> > > >  }
> > > >  }
> > > >  
> > > > +/* Assign BSEL property to all buses.  In the future, this can be 
> > > > changed
> > > > + * to only assign to buses that support hotplug.
> > > > + */
> > > > +static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> > > > +{
> > > > +unsigned *bsel_alloc = opaque;
> > > > +unsigned *bus_bsel;
> > > > +
> > > > +if (qbus_is_hotpluggable(BUS(bus))) {
> > > > +bus_bsel = g_malloc(sizeof *bus_bsel);
> > > > +
> > > > +*bus_bsel = (*bsel_alloc)++;
> > > > +object_property_add_uint32_ptr(OBJECT(bus), 
> > > > ACPI_PCIHP_PROP_BSEL,
> > > > +   bus_bsel, _abort);
> > > > +}
> > > > +
> > > > +return bsel_alloc;
> > > > +}
> > > > +
> > > > +static void acpi_set_pci_info(void)
> > > > +{
> > > > +PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> > > > +unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> > > > +
> > > > +if (bus) {
> > > > +/* Scan all PCI buses. Set property to enable acpi based 
> > > > hotplug. */
> > > > +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > > > _alloc);
> > > > +}
> > > > +}
> > > > +
> > > >  static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
> > > >  {
> > > >  AcpiPciHpFind *find = opaque;
> > > > @@ -177,6 +207,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
> > > >  
> > > >  void acpi_pcihp_reset(AcpiPciHpState *s)
> > > >  {
> > > > +acpi_set_pci_info();
> > > >  acpi_pcihp_update(s);
> > > >  }
> > > 
> > > IIUC doing this on reset will add property over and over again leaking
> > > memory.  
> > in v2 I've explicitly suggested to call it once, like:  
> 
> Sorry I misunderstood. I'll fix it.
> 
> > acpi_set_pci_info() {
> > 
> >static bool bsel_is set;
> > 
> >if (bsel_is set)
> >return;
> >bsel_is set = true;
> > 
> >...
> > }
> > 
> > not patch related:
> > BTW bsel assignment is not stable in hotplug + migration use case,
> > and we probably should fix it up in 2.11 (CCing Marcel)
> >   
> > > I think that we need to do it on machine done.
> > > 
> > > Igor,  I think reordering acpi-build like earlier version did
> > > is less intrusive and more appropriate for 2.10.
> > > 
> > > For 2.10 I would like to see ideally some changes that
> > > are all if (xen) making it obvious non xen is not
> > > affected. I can then ack it and it will be merged in xen tree.  
> > it didn't work before so I'd just push fix to 2.11 without
> > intermediate fix.
> > But if you guys think it's worth to fix in 2.10, I'm fine with v2
> > for it if Anthony will take care of it (rebase this series)
> > in 2.11 merge window.  
> 
> Yes, I can take care of this series for 2.11, and find out how to build
> the mips-softmmu target which does not build because it's missing
> find_i440fx.
it doesn't look like mips supports ACPI, so we probably shouldn't
build acpi/pcihp for it at all but I'm not sure how hard it
would be to factor out if possible at all

 
> > > 
> > > Clean it up after 2.10.
> > >   
> 
> So is the 

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Tim Deegan]

At 14:55 +0100 on 18 Aug (1503068128), Tim Deegan wrote:
> At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote:
> > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> > index c9c2252..1e3dfaf 100644
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -3112,7 +3112,6 @@ static int sh_page_fault(struct vcpu *v,
> >   * will make sure no inconsistent mapping being translated into
> >   * shadow page table. */
> >  version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
> > -rmb();
> >  walk_ok = sh_walk_guest_tables(v, va, , error_code);
> 
> Nack.  We must read the version before reading the tables, or we might
> accidentally use out-of-date tables.
> 
> If anything, this needs more barriers!  There ought to be a read
> barrier before we re-read the version in shadow_check_gwalk(), but
> taking the paging lock DTRT.  And there ought to be a wmb() before we
> increment the version later on, which I guess I'll make a patch for.

These can be smp_*mb(), though, to align with the rest of the series.

Tim.

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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Jan Beulich]

>>> On 18.08.17 at 15:45,  wrote:
> On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
>> >
>> >> > +}
>> >> > +}
>> >> > +}
>> >> 
>> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
>> >> table?
>> >> 
>> >
>> >Oh, I sorta see why you do this, but I still think this is wrong. The
>> >DMAR should either be a new module or be joined to the existing one (and
>> >with all conflicts resolved).
>> 
>> Hi, Wei
>> Thanks for your comments.
>> 
>> iirc, HVM only supports one module;
> 
> This is indeed how it is stated in various comments. I'm not sure why
> there is such restriction. Maybe x86 maintainers can shed more light on
> this?

Not me, sorry. Maybe ask whoever has written that code?

Jan


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

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

[Tim Deegan]

At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote:
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index c9c2252..1e3dfaf 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3112,7 +3112,6 @@ static int sh_page_fault(struct vcpu *v,
>   * will make sure no inconsistent mapping being translated into
>   * shadow page table. */
>  version = atomic_read(>arch.paging.shadow.gtable_dirty_version);
> -rmb();
>  walk_ok = sh_walk_guest_tables(v, va, , error_code);

Nack.  We must read the version before reading the tables, or we might
accidentally use out-of-date tables.

If anything, this needs more barriers!  There ought to be a read
barrier before we re-read the version in shadow_check_gwalk(), but
taking the paging lock DTRT.  And there ought to be a wmb() before we
increment the version later on, which I guess I'll make a patch for.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

[Wei Liu]

On Fri, Aug 18, 2017 at 02:30:03PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 15/08/17 10:49, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 06:51:24PM +0100, Julien Grall wrote:
> > > > > > The interface between Xen and xenconsoled can be asynchronous, it 
> > > > > > can
> > > > > > opt to queue X characters before sending an event, also setup a 
> > > > > > oneshot
> > > > > > timer to avoid hanging.
> > > > > > 
> > > > > > This however has some other implications -- it might not be as 
> > > > > > reliable
> > > > > > as the original method because data is not guaranteed to hit 
> > > > > > backend. If
> > > > > > the guest crashes very early on, depending the actual 
> > > > > > implementation you
> > > > > > might not be able get the data.
> > > > > 
> > > > > Would it be possible to ask xenconsoled to dump everything on domain 
> > > > > crash?
> > > > > Some kind of synchronization.
> > > > > 
> > > > 
> > > > No, not at the moment. If the data is still in Xen and destroyed,
> > > > xenconsoled can't do anything.
> > > 
> > > The vUART emulation is directly queuing the data, there are no 
> > > intermediate
> > > buffer. So all the data would be in the shared ring available for
> > > xenconsoled to go through.
> > > 
> > > It would be quite a useful enhancement for when the guest crash.
> > > 
> > 
> > What I meant was actually "If the data is still in the ring". There is
> > no synchronisation between Xen and xenconsoled to let the latter pull
> > out all data before destroying the guest.
> 
> I don't think you would need synchronisation between Xen and xenconsoled at
> domain destruction. Given that xenconsoled would have to unmap the page, I
> was suggesting that it makes sure that cons == prod before destroying the
> instance. So all the character queued would be displayed on the console.

So this is relying on Dom0 holding a reference to the page so that the
page won't be freed. This sounds plausible.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  12 guest-start   fail REGR. vs. 71978
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install   fail REGR. vs. 71978

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71978
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71978
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71978
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71978
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 71978
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 71978
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu1f296733876434118fd766cfef5eb6f29ecab6a8
baseline version:
 qemuuc4a6a8887c1b2a669e35ff9da9530824300bdce4

Last test of basis71978  2017-08-16 01:15:14 Z2 days
Testing same since71990  2017-08-18 07:15:25 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Eric Blake 
  Fam Zheng 
  Kevin Wolf 
  Paolo Bonzini 
  Peter Maydell 
  Portia Stephens 
  Richard Henderson 
  Stefan Hajnoczi 

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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Wei Liu]

On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
> >
> >> > +}
> >> > +}
> >> > +}
> >> 
> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
> >> table?
> >> 
> >
> >Oh, I sorta see why you do this, but I still think this is wrong. The
> >DMAR should either be a new module or be joined to the existing one (and
> >with all conflicts resolved).
> 
> Hi, Wei
> Thanks for your comments.
> 
> iirc, HVM only supports one module;

This is indeed how it is stated in various comments. I'm not sure why
there is such restriction. Maybe x86 maintainers can shed more light on
this?

> DMAR cannot be a new module. Joining to
> the existing one is the approach we are taking. 
> 
> Which kind of conflicts you think should be resolved? If you mean I
> forget to free the old buf, I will fix this. If you mean the potential
> overlap between the binary passed by admin and DMAR table built here, I
> don't have much idea on this. Even without the DMAR table, the binary
> may contains MADT or other tables and tool stacks don't intrepret the
> binary and check whether there are conflicts, right?

That's true. Ignore the comment about fixing up conflicts then.

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

Re: [Xen-devel] [PATCH V2 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

[Wei Liu]

On Thu, Aug 17, 2017 at 08:22:16PM -0400, Lan Tianyu wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b22aacc..d1f9b10 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -396,6 +396,9 @@ struct domain *domain_create(domid_t domid, unsigned int 
> domcr_flags,
>  spin_unlock(_update_lock);
>  }
>  
> +if ( (err = viommu_init_domain(d)) != 0 )
> +goto fail;
> +

Where is the code to destroy viommu during domain destruction?

I suppose you will need a viommu_destroy_domain and call it somewhere in
complete_domain_destroy.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +bool __read_mostly opt_viommu;
> +boolean_param("viommu", opt_viommu);

Missing patch to xen command line option doc.

> +
> +static spinlock_t type_list_lock;
> +static struct list_head type_list;
> +
> +struct viommu_type {
> +u64 type;

uintXX_t here and in all other places please.

[...]
> +
> +static int viommu_create(struct domain *d, u64 type, u64 base_address,
> +u64 length, u64 caps)
> +{
> +struct viommu_info *info = >viommu;
> +struct viommu *viommu;
> +struct viommu_type *viommu_type = NULL;
> +int rc;
> +
> +viommu_type = viommu_get_type(type);
> +if ( !viommu_type )
> +return -EINVAL;
> +
> +if ( info->nr_viommu >= NR_VIOMMU_PER_DOMAIN

E2BIG for this?

> +|| !viommu_type->ops || !viommu_type->ops->create )
> +return -EINVAL;
> +
> +viommu = xzalloc(struct viommu);
> +if ( !viommu )
> +return -ENOMEM;
> +
[...]
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 6673b27..98a965a 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -477,6 +478,7 @@ struct domain
>  /* vNUMA topology accesses are protected by rwlock. */
>  rwlock_t vnuma_rwlock;
>  struct vnuma_info *vnuma;

Please add a new line here.

> +struct viommu_info viommu;
>  
>  /* Common monitor options */
>  struct {
> diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
> new file mode 100644
> index 000..506ea54
> --- /dev/null
> +++ b/xen/include/xen/viommu.h
> @@ -0,0 +1,71 @@
> +/*
> + * include/xen/viommu.h
> + *
> + * Copyright (c) 2017, Intel Corporation
> + * Author: Lan Tianyu  
> + *
> + * 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 .
> + *
> + */
> +#ifndef __XEN_VIOMMU_H__
> +#define __XEN_VIOMMU_H__
> +
> +#define NR_VIOMMU_PER_DOMAIN 1
> +
> +struct viommu;
> +
> +struct viommu_ops {
> +u64 (*query_caps)(struct domain *d);
> +int (*create)(struct domain *d, struct viommu *viommu);
> +int (*destroy)(struct viommu *viommu);
> +};
> +
> +struct viommu {
> +u64 base_address;
> +u64 length;
> +u64 caps;
> +u32 viommu_id;
> +const struct viommu_ops *ops;
> +void *priv;
> +};
> +
> +struct viommu_info {
> +u32 nr_viommu;

unsigned int

> +struct viommu *viommu[NR_VIOMMU_PER_DOMAIN]; /* viommu array*/
> +};
> +
> +#ifdef CONFIG_VIOMMU
> +extern bool_t opt_viommu;

bool

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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Anthony PERARD]

On Fri, Aug 18, 2017 at 11:37:34AM +0200, Igor Mammedov wrote:
> On Fri, 18 Aug 2017 04:40:02 +0300
> "Michael S. Tsirkin"  wrote:
> 
> > On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> > > This means that the function will be call and the property
> > > acpi-pcihp-bsel will be set even if ACPI build is disable.
> > > 
> > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > > set, but this was done only when ACPI tables are built which is not
> > > needed for a Xen guest. The need for the property starts with commit
> > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > 
> > > Reported-by: Sander Eikelenboom 
> > > Signed-off-by: Anthony PERARD 
> > > 
> > > ---
> > > Changes in V3:
> > >   - move acpi_set_pci_info to pcihp instead
> > > 
> > > Changes in V2:
> > >   - check for acpi_enabled before calling acpi_set_pci_info.
> > >   - set the property on the root bus only.
> > > 
> > > This patch would be a canditade to backport to 2.9, along with
> > > "hw/acpi: Limit hotplug to root bus on legacy mode"
> > > 
> > > CC: Stefano Stabellini 
> > > CC: Bruce Rogers 
> > > ---
> > >  hw/acpi/pcihp.c  | 31 +++
> > >  hw/i386/acpi-build.c | 32 
> > >  2 files changed, 31 insertions(+), 32 deletions(-)
> > > 
> > > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > > index 9db3c2eaf2..44e8842db8 100644
> > > --- a/hw/acpi/pcihp.c
> > > +++ b/hw/acpi/pcihp.c
> > > @@ -75,6 +75,36 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
> > >  }
> > >  }
> > >  
> > > +/* Assign BSEL property to all buses.  In the future, this can be changed
> > > + * to only assign to buses that support hotplug.
> > > + */
> > > +static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> > > +{
> > > +unsigned *bsel_alloc = opaque;
> > > +unsigned *bus_bsel;
> > > +
> > > +if (qbus_is_hotpluggable(BUS(bus))) {
> > > +bus_bsel = g_malloc(sizeof *bus_bsel);
> > > +
> > > +*bus_bsel = (*bsel_alloc)++;
> > > +object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
> > > +   bus_bsel, _abort);
> > > +}
> > > +
> > > +return bsel_alloc;
> > > +}
> > > +
> > > +static void acpi_set_pci_info(void)
> > > +{
> > > +PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> > > +unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> > > +
> > > +if (bus) {
> > > +/* Scan all PCI buses. Set property to enable acpi based 
> > > hotplug. */
> > > +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > > _alloc);
> > > +}
> > > +}
> > > +
> > >  static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
> > >  {
> > >  AcpiPciHpFind *find = opaque;
> > > @@ -177,6 +207,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
> > >  
> > >  void acpi_pcihp_reset(AcpiPciHpState *s)
> > >  {
> > > +acpi_set_pci_info();
> > >  acpi_pcihp_update(s);
> > >  }  
> > 
> > IIUC doing this on reset will add property over and over again leaking
> > memory.
> in v2 I've explicitly suggested to call it once, like:

Sorry I misunderstood. I'll fix it.

> acpi_set_pci_info() {
> 
>static bool bsel_is set;
> 
>if (bsel_is set)
>return;
>bsel_is set = true;
> 
>...
> }
> 
> not patch related:
> BTW bsel assignment is not stable in hotplug + migration use case,
> and we probably should fix it up in 2.11 (CCing Marcel)
> 
> > I think that we need to do it on machine done.
> > 
> > Igor,  I think reordering acpi-build like earlier version did
> > is less intrusive and more appropriate for 2.10.
> > 
> > For 2.10 I would like to see ideally some changes that
> > are all if (xen) making it obvious non xen is not
> > affected. I can then ack it and it will be merged in xen tree.
> it didn't work before so I'd just push fix to 2.11 without
> intermediate fix.
> But if you guys think it's worth to fix in 2.10, I'm fine with v2
> for it if Anthony will take care of it (rebase this series)
> in 2.11 merge window.

Yes, I can take care of this series for 2.11, and find out how to build
the mips-softmmu target which does not build because it's missing
find_i440fx.

> > 
> > Clean it up after 2.10.
> > 

So is the v2 good enough or do I need to resend it?

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

[Julien Grall]

Hi Wei,

On 15/08/17 10:49, Wei Liu wrote:

On Thu, Aug 10, 2017 at 06:51:24PM +0100, Julien Grall wrote:

The interface between Xen and xenconsoled can be asynchronous, it can
opt to queue X characters before sending an event, also setup a oneshot
timer to avoid hanging.

This however has some other implications -- it might not be as reliable
as the original method because data is not guaranteed to hit backend. If
the guest crashes very early on, depending the actual implementation you
might not be able get the data.


Would it be possible to ask xenconsoled to dump everything on domain crash?
Some kind of synchronization.



No, not at the moment. If the data is still in Xen and destroyed,
xenconsoled can't do anything.


The vUART emulation is directly queuing the data, there are no intermediate
buffer. So all the data would be in the shared ring available for
xenconsoled to go through.

It would be quite a useful enhancement for when the guest crash.



What I meant was actually "If the data is still in the ring". There is
no synchronisation between Xen and xenconsoled to let the latter pull
out all data before destroying the guest.


I don't think you would need synchronisation between Xen and xenconsoled 
at domain destruction. Given that xenconsoled would have to unmap the 
page, I was suggesting that it makes sure that cons == prod before 
destroying the instance. So all the character queued would be displayed 
on the console.




As it stands, if we go with the fully-synchronised approach for now,
that won't be a problem. But when you want to fiddle with the BUSY bit
or any other optimisation -- leaving more data in the ring -- that might
cause data loss.


The fully-synchronised solution is far too slow, we are looking at 
optimization to avoid the synchronization for every single character. 
This would leave some potential data loss (max a few characters) if the 
domain crashed.




I'm not against bumping the rate-limit, but I want a justification and
want to consider as many approaches as possible. Ultimately the final
decision is up to you and Stefano.


I am not in favor of bumping the rate-limit at the moment. I believe we 
can solve the problem directly in the emulation. I spoke with Bhupinder 
about various solution that seem promising.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/2] paravirt,xen: remove xen_patch()

[Boris Ostrovsky]

On 08/16/2017 01:31 PM, Juergen Gross wrote:
> Xen's paravirt patch function xen_patch() does some special casing for
> irq_ops functions to apply relocations when those functions can be
> patched inline instead of calls.
>
> Unfortunately none of the special case function replacements is small
> enough to be patched inline, so the special case never applies.
>
> As xen_patch() will call paravirt_patch_default() in all cases it can
> be just dropped. xen-asm.h doesn't seem necessary without xen_patch()
> as the only thing left in it would be the definition of XEN_EFLAGS_NMI
> used only once. So move that definition and remove xen-asm.h.
>
> Signed-off-by: Juergen Gross 

Applied to for-linus-4.14

-boris



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

Re: [Xen-devel] [PATCH v2 1/4] x86/mcheck: Minor cleanup to amd_nonfatal

[Tim Deegan]

At 12:22 +0100 on 16 Aug (1502886127), Andrew Cooper wrote:
>   * Drop trailing whitespace.
>   * Move amd_nonfatal_mcheck_init() into .init.text and drop a trailing 
> return.
>   * Drop unnecessary wmb()'s.  Because of Xen's implementation, they are only
> compiler barriers anyway, and each wrmsr() is already fully serialising.

But wrmsr() is not a compiler barrier!  So if the write-barriers are
needed (e.g. for the update to the global 'adjust') then you can't
remove them just because WRMSR is a CPU barrier.

If they're not needed (which is plausible) then the commit message
should explain that instead.

Nit: I think tinkering with memory barriers deserves its own commit,
not to be the third item in a list of 'minor cleanup's.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCHES v8 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 08/18/2017 05:11 AM, Jan Beulich wrote:
 On 16.08.17 at 20:33,  wrote:
>> .. so that it's easy to find pages that need to be scrubbed (those pages are
>> now marked with _PGC_need_scrub bit).
>>
>> We keep track of the first unscrubbed page in a page buddy using first_dirty
>> field. For now it can have two values, 0 (whole buddy needs scrubbing) or
>> INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent 
>> patches
>> will allow scrubbing to be interrupted, resulting in first_dirty taking any
>> value.
>>
>> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Jan Beulich 
> with one remark:
>
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -261,7 +261,11 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
>>  #ifdef CONFIG_X86
>>  const unsigned long *badpage = NULL;
>>  unsigned int i, array_size;
>> +
>> +BUILD_BUG_ON(8 * sizeof(((struct page_info *)0)->u.free.first_dirty) <
>> + MAX_ORDER + 1);
>>  #endif
>> +BUILD_BUG_ON(sizeof(((struct page_info *)0)->u) != sizeof(unsigned 
>> long));
> As I'm generally opposed to casts whenever one can get away
> without, I dislike these as well. In the case here, short of a local
> variable of suitable type, I'd suggest using frame_table instead
> of the open-coded cast. If you're fine with that, this can easily
> be done while committing.

Sure.


-boris

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

[Xen-devel] [xen-4.6-testing test] 112683: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112661
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112661
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 112661
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112661
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112661
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 112661
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112661
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 112661

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112661

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-3  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112661
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112661
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112661
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112661
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112661
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112661
 test-xtf-amd64-amd64-5   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-xtf-amd64-amd64-2   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-xtf-amd64-amd64-1   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  1ac8162d8323481ea5fb9cf20c5b830c4ffb7aec
baseline version:
 xen  5ae011e6620fb3fdc1127c84873718ada4589e1c

Last test of basis   112661  2017-08-16 06:14:11 Z2 days
Testing same since   112683  2017-08-17 

Re: [Xen-devel] [PATCH 2/2] x86/smp: Misc cleanup

[Jan Beulich]

 >>> On 18.08.17 at 12:27,  wrote:
> * Delete trailing whitespace
>  * Switch to using mfn_t for mfn_to_page()/page_to_mfn()
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 
again with Wei's remark addressed.

Jan


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

Re: [Xen-devel] [PATCH 1/2] x86/mm: Override mfn_to_page() and page_to_mfn() to use mfn_t

[Andrew Cooper]

On 18/08/17 13:16, Jan Beulich wrote:
 On 18.08.17 at 12:27,  wrote:
>> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
>> are switched to using __mfn_to_page() and __page_to_mfn().
>>
>> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
>>
>> However, {alloc,free}_l1_table() are switched to using __map_domain_page(), 
>> as
>> their pfn parameters are otherwise unused.  get_page() has one pfn->mfn
>> correction in a printk(), and __get_page_type()'s IOMMU handling has its gfn
>> calculation broken out for clarity.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
> Acked-by: Jan Beulich 
> with Wei's remark addressed and with one optional further request:
>
>> --- a/xen/include/asm-x86/page.h
>> +++ b/xen/include/asm-x86/page.h
>> @@ -82,10 +82,10 @@
>>  ((paddr_t)(((x).l4 & (PADDR_MASK_MASK
>>  
>>  /* Get pointer to info structure of page mapped by pte (struct page_info 
>> *). */
>> -#define l1e_get_page(x)   (mfn_to_page(l1e_get_pfn(x)))
>> -#define l2e_get_page(x)   (mfn_to_page(l2e_get_pfn(x)))
>> -#define l3e_get_page(x)   (mfn_to_page(l3e_get_pfn(x)))
>> -#define l4e_get_page(x)   (mfn_to_page(l4e_get_pfn(x)))
>> +#define l1e_get_page(x)   (__mfn_to_page(l1e_get_pfn(x)))
>> +#define l2e_get_page(x)   (__mfn_to_page(l2e_get_pfn(x)))
>> +#define l3e_get_page(x)   (__mfn_to_page(l3e_get_pfn(x)))
>> +#define l4e_get_page(x)   (__mfn_to_page(l4e_get_pfn(x)))
>>  
>>  /* Get pte access flags (unsigned int). */
>>  #define l1e_get_flags(x)   (get_pte_flags((x).l1))
>> @@ -145,10 +145,10 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, 
>> unsigned int flags)
>>  #define l4e_from_intpte(intpte)((l4_pgentry_t) { (intpte_t)(intpte) })
>>  
>>  /* Construct a pte from a page pointer and access flags. */
>> -#define l1e_from_page(page, flags) (l1e_from_pfn(page_to_mfn(page),(flags)))
>> -#define l2e_from_page(page, flags) (l2e_from_pfn(page_to_mfn(page),(flags)))
>> -#define l3e_from_page(page, flags) (l3e_from_pfn(page_to_mfn(page),(flags)))
>> -#define l4e_from_page(page, flags) (l4e_from_pfn(page_to_mfn(page),(flags)))
>> +#define l1e_from_page(page, flags) (l1e_from_pfn(__page_to_mfn(page), 
>> (flags)))
>> +#define l2e_from_page(page, flags) (l2e_from_pfn(__page_to_mfn(page), 
>> (flags)))
>> +#define l3e_from_page(page, flags) (l3e_from_pfn(__page_to_mfn(page), 
>> (flags)))
>> +#define l4e_from_page(page, flags) (l4e_from_pfn(__page_to_mfn(page), 
>> (flags)))
> Mind at once stripping the pointless outer parentheses from all
> the macros you modify, and the ones around flags in the latter
> set?

Will do.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/mm: Override mfn_to_page() and page_to_mfn() to use mfn_t

[Jan Beulich]

>>> On 18.08.17 at 12:27,  wrote:
> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
> are switched to using __mfn_to_page() and __page_to_mfn().
> 
> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
> 
> However, {alloc,free}_l1_table() are switched to using __map_domain_page(), as
> their pfn parameters are otherwise unused.  get_page() has one pfn->mfn
> correction in a printk(), and __get_page_type()'s IOMMU handling has its gfn
> calculation broken out for clarity.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 
with Wei's remark addressed and with one optional further request:

> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -82,10 +82,10 @@
>  ((paddr_t)(((x).l4 & (PADDR_MASK_MASK
>  
>  /* Get pointer to info structure of page mapped by pte (struct page_info *). 
> */
> -#define l1e_get_page(x)   (mfn_to_page(l1e_get_pfn(x)))
> -#define l2e_get_page(x)   (mfn_to_page(l2e_get_pfn(x)))
> -#define l3e_get_page(x)   (mfn_to_page(l3e_get_pfn(x)))
> -#define l4e_get_page(x)   (mfn_to_page(l4e_get_pfn(x)))
> +#define l1e_get_page(x)   (__mfn_to_page(l1e_get_pfn(x)))
> +#define l2e_get_page(x)   (__mfn_to_page(l2e_get_pfn(x)))
> +#define l3e_get_page(x)   (__mfn_to_page(l3e_get_pfn(x)))
> +#define l4e_get_page(x)   (__mfn_to_page(l4e_get_pfn(x)))
>  
>  /* Get pte access flags (unsigned int). */
>  #define l1e_get_flags(x)   (get_pte_flags((x).l1))
> @@ -145,10 +145,10 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, 
> unsigned int flags)
>  #define l4e_from_intpte(intpte)((l4_pgentry_t) { (intpte_t)(intpte) })
>  
>  /* Construct a pte from a page pointer and access flags. */
> -#define l1e_from_page(page, flags) (l1e_from_pfn(page_to_mfn(page),(flags)))
> -#define l2e_from_page(page, flags) (l2e_from_pfn(page_to_mfn(page),(flags)))
> -#define l3e_from_page(page, flags) (l3e_from_pfn(page_to_mfn(page),(flags)))
> -#define l4e_from_page(page, flags) (l4e_from_pfn(page_to_mfn(page),(flags)))
> +#define l1e_from_page(page, flags) (l1e_from_pfn(__page_to_mfn(page), 
> (flags)))
> +#define l2e_from_page(page, flags) (l2e_from_pfn(__page_to_mfn(page), 
> (flags)))
> +#define l3e_from_page(page, flags) (l3e_from_pfn(__page_to_mfn(page), 
> (flags)))
> +#define l4e_from_page(page, flags) (l4e_from_pfn(__page_to_mfn(page), 
> (flags)))

Mind at once stripping the pointless outer parentheses from all
the macros you modify, and the ones around flags in the latter
set?

Jan


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

Re: [Xen-devel] [PATCH v4 06/31] x86: move pv_emul_is_mem_write to pv/emulate.c

[Andrew Cooper]

On 18/08/17 13:08, Wei Liu wrote:
> On Fri, Aug 18, 2017 at 04:08:44AM -0600, Jan Beulich wrote:
>>
>> If it can't be static anymore, and considering it's just a wrapper
>> around another function call, would there be anything wrong with
>> making it an inline function in the header?
> Yes it can be done:
>
> ---8<---
> From 129ea54249114f97fe66b85672f1710c5f63f604 Mon Sep 17 00:00:00 2001
> From: Wei Liu 
> Date: Wed, 19 Jul 2017 16:15:48 +0100
> Subject: [PATCH] x86: move pv_emul_is_mem_write to pv/emulate.h
>
> Make it a static inline function in pv/emulate.h.  In the mean time it
> is required to include pv/emulate.h in x86/mm.c.
>
> The said function will be used later by different emulation handlers
> in later patches.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 06/31] x86: move pv_emul_is_mem_write to pv/emulate.c

[Wei Liu]

On Fri, Aug 18, 2017 at 04:08:44AM -0600, Jan Beulich wrote:
> >>> On 17.08.17 at 16:44,  wrote:
> > @@ -5138,13 +5140,6 @@ static int ptwr_emulated_cmpxchg(
> >  container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
> >  }
> >  
> > -static int pv_emul_is_mem_write(const struct x86_emulate_state *state,
> > -struct x86_emulate_ctxt *ctxt)
> > -{
> > -return x86_insn_is_mem_write(state, ctxt) ? X86EMUL_OKAY
> > -  : X86EMUL_UNHANDLEABLE;
> > -}
> 
> If it can't be static anymore, and considering it's just a wrapper
> around another function call, would there be anything wrong with
> making it an inline function in the header?

Yes it can be done:

---8<---
From 129ea54249114f97fe66b85672f1710c5f63f604 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Wed, 19 Jul 2017 16:15:48 +0100
Subject: [PATCH] x86: move pv_emul_is_mem_write to pv/emulate.h

Make it a static inline function in pv/emulate.h.  In the mean time it
is required to include pv/emulate.h in x86/mm.c.

The said function will be used later by different emulation handlers
in later patches.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/mm.c | 9 ++---
 xen/arch/x86/pv/emulate.h | 9 +
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5983a56811..e0e655ac31 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -126,6 +126,8 @@
 #include 
 #include 
 
+#include "pv/emulate.h"
+
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 l1_fixmap[L1_PAGETABLE_ENTRIES];
@@ -5138,13 +5140,6 @@ static int ptwr_emulated_cmpxchg(
 container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
 }
 
-static int pv_emul_is_mem_write(const struct x86_emulate_state *state,
-struct x86_emulate_ctxt *ctxt)
-{
-return x86_insn_is_mem_write(state, ctxt) ? X86EMUL_OKAY
-  : X86EMUL_UNHANDLEABLE;
-}
-
 static const struct x86_emulate_ops ptwr_emulate_ops = {
 .read   = ptwr_emulated_read,
 .insn_fetch = ptwr_emulated_read,
diff --git a/xen/arch/x86/pv/emulate.h b/xen/arch/x86/pv/emulate.h
index b2b1192d48..656c12f62d 100644
--- a/xen/arch/x86/pv/emulate.h
+++ b/xen/arch/x86/pv/emulate.h
@@ -1,10 +1,19 @@
 #ifndef __PV_EMULATE_H__
 #define __PV_EMULATE_H__
 
+#include 
+
 int pv_emul_read_descriptor(unsigned int sel, const struct vcpu *v,
 unsigned long *base, unsigned long *limit,
 unsigned int *ar, bool insn_fetch);
 
 void pv_emul_instruction_done(struct cpu_user_regs *regs, unsigned long rip);
 
+static inline int pv_emul_is_mem_write(const struct x86_emulate_state *state,
+   struct x86_emulate_ctxt *ctxt)
+{
+return x86_insn_is_mem_write(state, ctxt) ? X86EMUL_OKAY
+  : X86EMUL_UNHANDLEABLE;
+}
+
 #endif /* __PV_EMULATE_H__ */
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 12/12] xen-blkfront: Avoid that gcc 7 warns about fall-through when building with W=1

[Roger Pau Monn303251]

On Fri, Aug 18, 2017 at 12:46:23PM +0100, Anthony PERARD wrote:
> On Fri, Aug 18, 2017 at 09:54:01AM +0100, Roger Pau Monn303251 wrote:
> > On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> > > Signed-off-by: Bart Van Assche 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: Roger Pau Monn303251 
> > > Cc: xen-de...@lists.xenproject.org
> > > ---
> > >  drivers/block/xen-blkfront.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > index 98e34e4c62b8..270019e3e5d8 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -2456,7 +2456,7 @@ static void blkback_changed(struct xenbus_device 
> > > *dev,
> > >   case XenbusStateClosed:
> > >   if (dev->state == XenbusStateClosed)
> > >   break;
> > > - /* Missed the backend's Closing state -- fallthrough */
> > > + /* fall through */
> > 
> > This is losing information present in the original comment. Would
> > splitting the comment into two make gcc happy?
> 
> What about:
> 
> - /* Missed the backend's Closing state -- fallthrough */
> + /* fallthrough -- Missed the backend's Closing state */
> 
> FIY:
> https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Warning-Options.html#index-Wimplicit-fallthrough
> 
> A dash seems to be needed between "fall through" and a extra comment,
> with fallthrough first.

I think so, according to the documentation -Wimplicit-fallthrough=3 is
enabled with -Wextra, and requires having "fallthrough" first. Your
proposed change seems fine to me.

Roger.

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

Re: [Xen-devel] [PATCH 2/2] x86/smp: Misc cleanup

[Wei Liu]

On Fri, Aug 18, 2017 at 11:27:27AM +0100, Andrew Cooper wrote:
>  * Delete trailing whitespace
>  * Switch to using mfn_t for mfn_to_page()/page_to_mfn()
> 
> Signed-off-by: Andrew Cooper 
>  
[...]
> +/* Override macros from asm/mm.h to make them work with mfn_t */

Same here.

Otherwise:

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] x86/mm: Override mfn_to_page() and page_to_mfn() to use mfn_t

[Wei Liu]

On Fri, Aug 18, 2017 at 11:27:26AM +0100, Andrew Cooper wrote:
> To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
> are switched to using __mfn_to_page() and __page_to_mfn().
> 
> Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.
> 
> However, {alloc,free}_l1_table() are switched to using __map_domain_page(), as
> their pfn parameters are otherwise unused.  get_page() has one pfn->mfn
> correction in a printk(), and __get_page_type()'s IOMMU handling has its gfn
> calculation broken out for clarity.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: George Dunlap 
> CC: Tim Deegan 
> ---
>  xen/arch/x86/mm.c  | 151 
> -
>  xen/include/asm-x86/page.h |  16 ++---
>  2 files changed, 88 insertions(+), 79 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 31fe8a1..e862380 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -123,6 +123,12 @@
>  #include 
>  #include 
>  
> +/* Override macros from asm/mm.h to make them work with mfn_t */

They are from asm/page.h.

Otherwise:

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 12/12] xen-blkfront: Avoid that gcc 7 warns about fall-through when building with W=1

[Anthony PERARD]

On Fri, Aug 18, 2017 at 09:54:01AM +0100, Roger Pau Monn303251 wrote:
> On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> > Signed-off-by: Bart Van Assche 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Roger Pau Monn303251 
> > Cc: xen-de...@lists.xenproject.org
> > ---
> >  drivers/block/xen-blkfront.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 98e34e4c62b8..270019e3e5d8 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -2456,7 +2456,7 @@ static void blkback_changed(struct xenbus_device *dev,
> > case XenbusStateClosed:
> > if (dev->state == XenbusStateClosed)
> > break;
> > -   /* Missed the backend's Closing state -- fallthrough */
> > +   /* fall through */
> 
> This is losing information present in the original comment. Would
> splitting the comment into two make gcc happy?

What about:

-   /* Missed the backend's Closing state -- fallthrough */
+   /* fallthrough -- Missed the backend's Closing state */

FIY:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Warning-Options.html#index-Wimplicit-fallthrough

A dash seems to be needed between "fall through" and a extra comment,
with fallthrough first.

Regards,

-- 
Anthony PERARD

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

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

[Roger Pau Monné]

On Thu, Aug 17, 2017 at 07:36:20PM +0200, Andreas Kinzler wrote:
> On Tue, 15 Aug 2017 11:55:10 +0200, Roger Pau Monné 
> wrote:
> > Could you please try the patch below and paste the output you get on
> > the Xen console?
> 
> Output is in attached file. Does it help?

Yes, thanks. I'm quite sure the problem is that MSIX table entries are
being unmasked before MSIX is enabled, and so Xen is not able to snoop
those writes.

Just to confirm, can you try the following two debug patches? One is
for the hypervisor, the other is for QEMU.

Thanks, Roger.
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index a36692c313..87caef300a 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -329,6 +329,8 @@ static int msixtbl_write(struct vcpu *v, unsigned long 
address,
 
 ASSERT(msi_desc == desc->msi_desc);

+printk("%smasking entry %#x\n",
+   (val & PCI_MSIX_VECTOR_BITMASK) ? "" : "un", nr_entry);
 guest_mask_msi_irq(desc, !!(val & PCI_MSIX_VECTOR_BITMASK));
 
 unlock:
@@ -430,6 +432,9 @@ static void add_msixtbl_entry(struct domain *d,
 entry->gtable = (unsigned long) gtable;
 
 list_add_rcu(>list, >arch.hvm_domain.msixtbl_list);
+
+printk("%04x:%02x:%02x.%u added to msixtbl list\n", pdev->seg, pdev->bus,
+PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
 }
 
 static void free_msixtbl_entry(struct rcu_head *rcu)
@@ -510,8 +515,12 @@ out:
  (gtable + msi_desc->msi_attrib.entry_nr *
PCI_MSIX_ENTRY_SIZE +
   PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET) )
+{
+printk("msixtbl_pt_register: detected attempt to write to 
vector ctrl (entry %#x)\n",
+   msi_desc->msi_attrib.entry_nr);
 v->arch.hvm_vcpu.hvm_io.msix_unmask_address =
 v->arch.hvm_vcpu.hvm_io.msix_snoop_address;
+}
 }
 }
 
@@ -619,6 +628,7 @@ void msix_write_completion(struct vcpu *v)
 return;
 
 v->arch.hvm_vcpu.hvm_io.msix_unmask_address = 0;
+printk("Detected MSI-X unmask in write completion\n");
 if ( msixtbl_write(v, ctrl_address, 4, 0) != X86EMUL_OKAY )
 gdprintk(XENLOG_WARNING, "MSI-X write completion failure\n");
 }
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 77998f4fb3..0ca31c22e2 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -980,6 +980,8 @@ static int msix_capability_init(struct pci_dev *dev,
 
 list_add_tail(>list, >msi_list);
 *desc = entry;
+printk("%04x:%02x:%02x.%u added entry %#x to msi_list\n",
+   seg, bus, slot, func, msi->entry_nr);
 }
 
 if ( !msix->used_entries )
@@ -1297,6 +1299,18 @@ int pci_msi_conf_write_intercept(struct pci_dev *pdev, 
unsigned int reg,
 if ( reg != msix_control_reg(pos) || size != 2 )
 return -EACCES;
 
+printk("MSIX ctrl write. Enabled: %d Maskall: %d. "
+   "Configured entries:\n",
+   !!(*data & PCI_MSIX_FLAGS_ENABLE),
+   !!(*data & PCI_MSIX_FLAGS_MASKALL));
+list_for_each_entry( entry, >msi_list, list )
+{
+printk("%#x host_masked: %d guest_masked: %d\n",
+   entry->msi_attrib.entry_nr,
+   entry->msi_attrib.host_masked,
+   entry->msi_attrib.guest_masked);
+}
+
 pdev->msix->guest_maskall = !!(*data & PCI_MSIX_FLAGS_MASKALL);
 if ( pdev->msix->host_maskall )
 *data |= PCI_MSIX_FLAGS_MASKALL;
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 191d9caea1..c296cf682c 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -10,6 +10,7 @@ void xen_pt_log(const PCIDevice *d, const char *f, ...) 
GCC_FMT_ATTR(2, 3);
 
 #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
 
+#define XEN_PT_LOGGING_ENABLED 1
 #ifdef XEN_PT_LOGGING_ENABLED
 #  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
 #  define XEN_PT_WARN(d, _f, _a...) \
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 1f04ec5eec..893ac06a80 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1482,6 +1482,7 @@ static int 
xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
 /* update MSI-X */
 if ((*val & PCI_MSIX_FLAGS_ENABLE)
 && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+XEN_PT_LOG(>dev, "Enabling MSIX, setting up entries\n");
 xen_pt_msix_update(s);
 } else if (!(*val & PCI_MSIX_FLAGS_ENABLE) && s->msix->enabled) {
 xen_pt_msix_disable(s);
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index dfb8d64654..2662eb1940 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -132,8 +132,9 @@ static int msi_msix_setup(XenPCIPassthroughState *s,
 
 if (is_msix) {

[Xen-devel] [PATCH 1/2] x86/mm: Override mfn_to_page() and page_to_mfn() to use mfn_t

[Andrew Cooper]

To avoid breaking the build elsewhere, the l{1..4}e_{from,get}_page() macros
are switched to using __mfn_to_page() and __page_to_mfn().

Most changes are wrapping or removing _mfn()/mfn_x() from existing callsites.

However, {alloc,free}_l1_table() are switched to using __map_domain_page(), as
their pfn parameters are otherwise unused.  get_page() has one pfn->mfn
correction in a printk(), and __get_page_type()'s IOMMU handling has its gfn
calculation broken out for clarity.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: George Dunlap 
CC: Tim Deegan 
---
 xen/arch/x86/mm.c  | 151 -
 xen/include/asm-x86/page.h |  16 ++---
 2 files changed, 88 insertions(+), 79 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 31fe8a1..e862380 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -123,6 +123,12 @@
 #include 
 #include 
 
+/* Override macros from asm/mm.h to make them work with mfn_t */
+#undef mfn_to_page
+#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
+#undef page_to_mfn
+#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
+
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 l1_fixmap[L1_PAGETABLE_ENTRIES];
@@ -282,7 +288,8 @@ void __init arch_init_memory(void)
 
 /* First 1MB of RAM is historically marked as I/O. */
 for ( i = 0; i < 0x100; i++ )
-share_xen_page_with_guest(mfn_to_page(i), dom_io, XENSHARE_writable);
+share_xen_page_with_guest(mfn_to_page(_mfn(i)),
+  dom_io, XENSHARE_writable);
 
 /* Any areas not specified as RAM by the e820 map are considered I/O. */
 for ( i = 0, pfn = 0; pfn < max_page; i++ )
@@ -323,7 +330,7 @@ void __init arch_init_memory(void)
 if ( !mfn_valid(_mfn(pfn)) )
 continue;
 share_xen_page_with_guest(
-mfn_to_page(pfn), dom_io, XENSHARE_writable);
+mfn_to_page(_mfn(pfn)), dom_io, XENSHARE_writable);
 }
 
 /* Skip the RAM region. */
@@ -425,7 +432,7 @@ void share_xen_page_with_guest(
 if ( page_get_owner(page) == d )
 return;
 
-set_gpfn_from_mfn(page_to_mfn(page), INVALID_M2P_ENTRY);
+set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), INVALID_M2P_ENTRY);
 
 spin_lock(>page_alloc_lock);
 
@@ -682,7 +689,8 @@ int map_ldt_shadow_page(unsigned int off)
 return 0;
 }
 
-nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);
+nl1e = l1e_from_pfn(mfn_x(page_to_mfn(page)),
+l1e_get_flags(l1e) | _PAGE_RW);
 
 spin_lock(>arch.pv_vcpu.shadow_ldt_lock);
 l1e_write(_ldt_ptes(d, v)[off + 16], nl1e);
@@ -695,7 +703,7 @@ int map_ldt_shadow_page(unsigned int off)
 
 static bool get_page_from_mfn(mfn_t mfn, struct domain *d)
 {
-struct page_info *page = mfn_to_page(mfn_x(mfn));
+struct page_info *page = mfn_to_page(mfn);
 
 if ( unlikely(!mfn_valid(mfn)) || unlikely(!get_page(page, d)) )
 {
@@ -712,7 +720,7 @@ static int get_page_and_type_from_mfn(
 mfn_t mfn, unsigned long type, struct domain *d,
 int partial, int preemptible)
 {
-struct page_info *page = mfn_to_page(mfn_x(mfn));
+struct page_info *page = mfn_to_page(mfn);
 int rc;
 
 if ( likely(partial >= 0) &&
@@ -777,7 +785,7 @@ get_##level##_linear_pagetable( 
\
  * Ensure that the mapped frame is an already-validated page table. \
  * If so, atomically increment the count (checking for overflow).   \
  */ \
-page = mfn_to_page(pfn);\
+page = mfn_to_page(_mfn(pfn));  \
 y = page->u.inuse.type_info;\
 do {\
 x = y;  \
@@ -804,7 +812,7 @@ bool is_iomem_page(mfn_t mfn)
 return true;
 
 /* Caller must know that it is an iomem page, or a reference is held. */
-page = mfn_to_page(mfn_x(mfn));
+page = mfn_to_page(mfn);
 ASSERT((page->count_info & PGC_count_mask) != 0);
 
 return (page_get_owner(page) == dom_io);
@@ -873,7 +881,7 @@ get_page_from_l1e(
 l1_pgentry_t l1e, struct domain *l1e_owner, struct domain *pg_owner)
 {
 unsigned long mfn = l1e_get_pfn(l1e);
-struct page_info *page = mfn_to_page(mfn);
+struct page_info *page = mfn_to_page(_mfn(mfn));
 uint32_t l1f = l1e_get_flags(l1e);
 struct vcpu *curr = current;
 struct domain *real_pg_owner;
@@ -1219,7 +1227,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, 

[Xen-devel] [PATCH 2/2] x86/smp: Misc cleanup

[Andrew Cooper]

 * Delete trailing whitespace
 * Switch to using mfn_t for mfn_to_page()/page_to_mfn()

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/smpboot.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 8d91f6c..4d45f42 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -4,17 +4,17 @@
  * This inherits a great deal from Linux's SMP boot code:
  *  (c) 1995 Alan Cox, Building #3 
  *  (c) 1998, 1999, 2000 Ingo Molnar 
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -46,6 +46,12 @@
 #include 
 #include 
 
+/* Override macros from asm/mm.h to make them work with mfn_t */
+#undef mfn_to_page
+#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
+#undef page_to_mfn
+#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
+
 #define setup_trampoline()(bootsym_phys(trampoline_realmode_entry))
 
 unsigned long __read_mostly trampoline_phys;
@@ -307,14 +313,14 @@ void start_secondary(void *unused)
  * Just as during early bootstrap, it is convenient here to disable
  * spinlock checking while we have IRQs disabled. This allows us to
  * acquire IRQ-unsafe locks when it would otherwise be disallowed.
- * 
+ *
  * It is safe because the race we are usually trying to avoid involves
  * a group of CPUs rendezvousing in an IPI handler, where one cannot
  * join because it is spinning with IRQs disabled waiting to acquire a
  * lock held by another in the rendezvous group (the lock must be an
  * IRQ-unsafe lock since the CPU took the IPI after acquiring it, and
  * hence had IRQs enabled). This is a deadlock scenario.
- * 
+ *
  * However, no CPU can be involved in rendezvous until it is online,
  * hence no such group can be waiting for this CPU until it is
  * visible in cpu_online_map. Hence such a deadlock is not possible.
@@ -423,8 +429,8 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned 
long start_eip)
 else if ( tboot_in_measured_env() )
 {
 /*
- * With tboot AP is actually spinning in a mini-guest before 
- * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit, 
+ * With tboot AP is actually spinning in a mini-guest before
+ * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit,
  * update VMCS to tracking SIPIs and VMResume.
  *
  * While AP is in root mode handling the INIT the CPU will drop
@@ -596,7 +602,7 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
long *mfn)
 BUILD_BUG_ON(STUBS_PER_PAGE & (STUBS_PER_PAGE - 1));
 
 if ( *mfn )
-pg = mfn_to_page(*mfn);
+pg = mfn_to_page(_mfn(*mfn));
 else
 {
 nodeid_t node = cpu_to_node(cpu);
@@ -610,7 +616,7 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
long *mfn)
 }
 
 stub_va = XEN_VIRT_END - (cpu + 1) * PAGE_SIZE;
-if ( map_pages_to_xen(stub_va, page_to_mfn(pg), 1,
+if ( map_pages_to_xen(stub_va, mfn_x(page_to_mfn(pg)), 1,
   PAGE_HYPERVISOR_RX | MAP_SMALL_PAGES) )
 {
 if ( !*mfn )
@@ -618,7 +624,7 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
long *mfn)
 stub_va = 0;
 }
 else if ( !*mfn )
-*mfn = page_to_mfn(pg);
+*mfn = mfn_x(page_to_mfn(pg));
 
 return stub_va;
 }
@@ -652,8 +658,8 @@ static void cpu_smpboot_free(unsigned int cpu)
 
 if ( per_cpu(stubs.addr, cpu) )
 {
-unsigned long mfn = per_cpu(stubs.mfn, cpu);
-unsigned char *stub_page = map_domain_page(_mfn(mfn));
+mfn_t mfn = _mfn(per_cpu(stubs.mfn, cpu));
+unsigned char *stub_page = map_domain_page(mfn);
 unsigned int i;
 
 memset(stub_page + STUB_BUF_CPU_OFFS(cpu), 0xcc, STUB_BUF_SIZE);
@@ -871,7 +877,7 @@ remove_siblinginfo(int cpu)
 if ( cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) == 1 )
 cpu_data[sibling].booted_cores--;
 }
-   
+
 for_each_cpu(sibling, per_cpu(cpu_sibling_mask, cpu))
 cpumask_clear_cpu(cpu, per_cpu(cpu_sibling_mask, sibling));
 cpumask_clear(per_cpu(cpu_sibling_mask, cpu));
-- 
2.1.4

Re: [Xen-devel] [PATCH v4 03/31] x86/mm: split HVM grant table code to hvm/grant_table.c

[Andrew Cooper]

On 17/08/17 15:44, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/hvm/Makefile  |  1 +
>  xen/arch/x86/hvm/grant_table.c | 89 
> ++
>  xen/arch/x86/mm.c  | 53 -
>  3 files changed, 90 insertions(+), 53 deletions(-)
>  create mode 100644 xen/arch/x86/hvm/grant_table.c
>
> diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
> index c394af7364..5bd38f633f 100644
> --- a/xen/arch/x86/hvm/Makefile
> +++ b/xen/arch/x86/hvm/Makefile
> @@ -6,6 +6,7 @@ obj-y += dm.o
>  obj-bin-y += dom0_build.init.o
>  obj-y += domain.o
>  obj-y += emulate.o
> +obj-y += grant_table.o
>  obj-y += hpet.o
>  obj-y += hvm.o
>  obj-y += hypercall.o
> diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c
> new file mode 100644
> index 00..7503c2c61b
> --- /dev/null
> +++ b/xen/arch/x86/hvm/grant_table.c
> @@ -0,0 +1,89 @@
> +/**
> + * arch/x86/hvm/grant_table.c
> + *
> + * Grant table interfaces for HVM guests
> + *
> + * Copyright (C) 2017 Wei Liu 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +int create_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> + unsigned int flags,
> + unsigned int cache_flags)
> +{
> +p2m_type_t p2mt;
> +int rc;
> +
> +if ( cache_flags  || (flags & ~GNTMAP_readonly) != GNTMAP_host_map )

Mind dropping this double space while moving?

~Andrew

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

Re: [Xen-devel] [PATCH v4 05/31] x86/mm: document the return values from get_page_from_l*e

[Jan Beulich]

>>> On 17.08.17 at 16:44,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

[Xen-devel] [xen-4.9-testing test] 112682: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 112647
 test-armhf-armhf-xl-credit2   4 host-install(4)broken REGR. vs. 112647
 test-amd64-i386-libvirt-xsm  12 guest-start  fail REGR. vs. 112647
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 112647
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112647
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112647
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112647
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 112647
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112647
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112647
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
112647
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 112647
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 112647
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 112647

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112647

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112647
 build-arm64-xsm   2 hosts-allocate  broken like 112647
 build-arm64-pvops 2 hosts-allocate  broken like 112647
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112647
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112647
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112647
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 

Re: [Xen-devel] [PATCH v4 03/31] x86/mm: split HVM grant table code to hvm/grant_table.c

[Jan Beulich]

>>> On 17.08.17 at 16:44,  wrote:
> Signed-off-by: Wei Liu 

Looks to be pure code movement, so
Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH] xen/events: events_fifo: Don't use {get, put}_cpu() in xen_evtchn_fifo_init()

[Julien Grall]

Hi Boris,

On 17/08/17 18:36, Boris Ostrovsky wrote:

On 08/17/2017 12:14 PM, Julien Grall wrote:

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following
splat appears:

[0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[0.019717] ASID allocator initialised with 65536 entries
[0.020019] xen:grant_table: Grant tables using version 1 layout
[0.020051] Grant table initialized
[0.020069] BUG: sleeping function called from invalid context at 
/data/src/linux/mm/page_alloc.c:4046
[0.020100] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
[0.020123] no locks held by swapper/0/1.
[0.020143] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc5 #598
[0.020166] Hardware name: FVP Base (DT)
[0.020182] Call trace:
[0.020199] [] dump_backtrace+0x0/0x270
[0.020222] [] show_stack+0x24/0x30
[0.020244] [] dump_stack+0xb8/0xf0
[0.020267] [] ___might_sleep+0x1c8/0x1f8
[0.020291] [] __might_sleep+0x58/0x90
[0.020313] [] __alloc_pages_nodemask+0x1c0/0x12e8
[0.020338] [] alloc_page_interleave+0x38/0x88
[0.020363] [] alloc_pages_current+0xdc/0xf0
[0.020387] [] __get_free_pages+0x28/0x50
[0.020411] [] evtchn_fifo_alloc_control_block+0x2c/0xa0
[0.020437] [] xen_evtchn_fifo_init+0x38/0xb4
[0.020461] [] xen_init_IRQ+0x44/0xc8
[0.020484] [] xen_guest_init+0x250/0x300
[0.020507] [] do_one_initcall+0x44/0x130
[0.020531] [] kernel_init_freeable+0x120/0x288
[0.020556] [] kernel_init+0x18/0x110
[0.020578] [] ret_from_fork+0x10/0x40
[0.020606] xen:events: Using FIFO-based ABI
[0.020658] Xen: initializing cpu0
[0.027727] Hierarchical SRCU implementation.
[0.036235] EFI services will not be available.
[0.043810] smp: Bringing up secondary CPUs ...

This is because get_cpu() in xen_evtchn_fifo_init() will disable
preemption, but __get_free_page() might sleep (GFP_ATOMIC is not set).

xen_evtchn_fifo_init() will always be called before SMP is initialized,
so {get,put}_cpu() could be replaced by a simple smp_processor_id().


On x86 this will be called out of init_IRQ(), which is already preceded
by preempt_disable().


Well the main problem is preempt_disable() itself. in_atomic() will 
check preempt_count and return 1 if it is non-zero.


__get_free_page might sleep if GFP_ATOMIC is not set and therefore you 
will see the splat when CONFIG_DEBUG_ATOMIC is enabled. However, those 
checks don't happen before the scheduler is setup. Hence why you don't 
see the error on x86.


Cheers,



Reviewed-by: Boris Ostrovsky 



--
Julien Grall

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

Re: [Xen-devel] [PATCH V2 4/25] Xen/doc: Add Xen virtual IOMMU doc

[Wei Liu]

On Fri, Aug 18, 2017 at 03:17:37PM +0800, Lan Tianyu wrote:
> On 2017年08月17日 19:19, Wei Liu wrote:
> > On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
> >> +Now just suppport single vIOMMU for one VM and introduced domctls are 
> >> compatible
> >> +with multi-vIOMMU support.
> > 
> > Is this still true? 
> 
> Yes, the patchset just supports single vIOMMU for one VM.
> 

The first part of the sentence is true, but the latter is probably not.
It seems to me domctl is able to cope with multiple viommu. Please
correct me if I'm wrong.

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

Re: [Xen-devel] [PATCH v4 02/31] x86/mm: carve out replace_grant_pv_mapping

[Jan Beulich]

>>> On 17.08.17 at 16:44,  wrote:
> And at once make it an inline function. Add declarations of
> replace_grant_{hvm,pv}_mapping to respective header files.

Same remark on function name.

> @@ -38,6 +40,12 @@ static inline int create_grant_p2m_mapping(uint64_t addr, 
> unsigned long frame,
>  return GNTST_general_error;
>  }
>  
> +int replace_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> +  uint64_t new_addr, unsigned int flags)

static inline

> @@ -37,6 +39,12 @@ static inline int create_grant_pv_mapping(uint64_t addr, 
> unsigned long frame,
>  return GNTST_general_error;
>  }
>  
> +int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
> + uint64_t new_addr, unsigned int flags)

Again.

With these taken care of
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH V2 2/25] VIOMMU: Add irq request callback to deal with irq remapping

[Wei Liu]

On Fri, Aug 18, 2017 at 03:09:55PM +0800, Lan Tianyu wrote:
> On 2017年08月17日 19:18, Wei Liu wrote:
> > On Wed, Aug 09, 2017 at 04:34:03PM -0400, Lan Tianyu wrote:
> >> This patch is to add irq request callback for platform implementation
> >> to deal with irq remapping request.
> >>
> >> Signed-off-by: Lan Tianyu 
> >> ---
> >>  xen/common/viommu.c  | 15 +
> >>  xen/include/asm-x86/viommu.h | 73 
> >> 
> >>  xen/include/xen/viommu.h |  9 ++
> >>  3 files changed, 97 insertions(+)
> >>  create mode 100644 xen/include/asm-x86/viommu.h
> >>
> >> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> >> index a4d004d..f4d34e6 100644
> >> --- a/xen/common/viommu.c
> >> +++ b/xen/common/viommu.c
> >> @@ -198,6 +198,21 @@ int __init viommu_setup(void)
> >>  return 0;
> >>  }
> >>  
> >> +int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
> >> +  struct irq_remapping_request *request)
> >> +{
> >> +struct viommu_info *info = >viommu;
> > 
> > Does this compile? This patch and the previous one don't have viommu
> > added to struct domain.
> 
> Oh. Sorry. Missed patch "VIOMMU: Add vIOMMU helper functions to create,
>  destroy and query capabilities" in this series. I just sent out and
> followed this mail. Please have a look.
> 
> > 
> >> +
> >> +if ( viommu_id >= info->nr_viommu
> >> + || !info->viommu[viommu_id] )
> > 
> > Join this to previous line?
> >
> 
> OK.
> 
> >> +return -EINVAL;
> > 
> > ASSERT(info->viommu[viommu_id]->ops);
> > 
> > For extra safety.
> 
> Or check ops in the previous if?
> 

That depends on if ops can be null or not.

> > 
> >> +
> >> +if ( !info->viommu[viommu_id]->ops->handle_irq_request )
> >> +return -EINVAL;
> >> +
> >> +return info->viommu[viommu_id]->ops->handle_irq_request(d, request);
> >> +}
> >> +
> >>  /*
> >>   * Local variables:
> >>   * mode: C
> >> diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
> >> new file mode 100644
> >> index 000..51bda72
> >> --- /dev/null
> >> +++ b/xen/include/asm-x86/viommu.h
> >> @@ -0,0 +1,73 @@
> >> +/*
> >> + * include/asm-x86/viommu.h
> >> + *
> >> + * Copyright (c) 2017 Intel Corporation.
> >> + * Author: Lan Tianyu  
> >> + *
> >> + * 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 .
> >> + *
> >> + */
> >> +#ifndef __ARCH_X86_VIOMMU_H__
> >> +#define __ARCH_X86_VIOMMU_H__
> >> +
> > 
> > Is a corresponding ARM header needed? Given viommu is common code.
> 
> I added such ARM header file in previous version but Julien hope vIOMMU
> should be disabled for ARM because ARM doesn't support vIOMMU so far.
> 

If that's what he wanted, sure.

Please build test ARM as well. You can do so using travis-ci.

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

Re: [Xen-devel] [PATCH v4 01/31] x86/mm: carve out create_grant_pv_mapping

[Jan Beulich]

>>> On 17.08.17 at 16:44,  wrote:
> And at once make create_grant_host_mapping an inline function.  This
> requires making create_grant_{hvm,pv}_mapping non-static.  Provide
> {hvm,pv}/grant_table.h. Include the headers where necessary.
> 
> The two functions create_grant_{hvm,pv}_mapping will be moved later in
> a dedicated patch with all their helpers.
> 
> Signed-off-by: Wei Liu 

With the function name in the description above corrected (it's
_p2m_ rather than _hvm_)
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v4 06/31] x86: move pv_emul_is_mem_write to pv/emulate.c

[Jan Beulich]

>>> On 17.08.17 at 16:44,  wrote:
> @@ -5138,13 +5140,6 @@ static int ptwr_emulated_cmpxchg(
>  container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
>  }
>  
> -static int pv_emul_is_mem_write(const struct x86_emulate_state *state,
> -struct x86_emulate_ctxt *ctxt)
> -{
> -return x86_insn_is_mem_write(state, ctxt) ? X86EMUL_OKAY
> -  : X86EMUL_UNHANDLEABLE;
> -}

If it can't be static anymore, and considering it's just a wrapper
around another function call, would there be anything wrong with
making it an inline function in the header?

Jan


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

[Xen-devel] [distros-debian-jessie test] 71989: tolerable trouble: blocked/broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

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

baseline version:
 flight   71962

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub 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] [Qemu-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Igor Mammedov]

On Thu, 17 Aug 2017 17:23:46 +0100
Anthony PERARD  wrote:

> This means that the function will be call and the property
> acpi-pcihp-bsel will be set even if ACPI build is disable.
s/call/called/
s/disable/disabled/

Maybe something along this lines:

HW part of APCI PCI hotplug in QEMU depends on ACPI_PCIHP_PROP_BSEL
being set on a PCI bus that supports ACPI hotplug. It should work
regardless of source of ACPI tables (QEMU generator/legacy Seabios/Xen).
So move ACPI_PCIHP_PROP_BSEL initialization into HW ACPI impl. part
from QEMU's ACPI table generator.

> 
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when ACPI tables are built which is not
> needed for a Xen guest. The need for the property starts with commit
> "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> 
> Reported-by: Sander Eikelenboom 
> Signed-off-by: Anthony PERARD 
> 
> ---
> Changes in V3:
>   - move acpi_set_pci_info to pcihp instead
> 
> Changes in V2:
>   - check for acpi_enabled before calling acpi_set_pci_info.
>   - set the property on the root bus only.
> 
> This patch would be a canditade to backport to 2.9, along with
> "hw/acpi: Limit hotplug to root bus on legacy mode"
> 
> CC: Stefano Stabellini 
> CC: Bruce Rogers 
> ---
>  hw/acpi/pcihp.c  | 31 +++
>  hw/i386/acpi-build.c | 32 
>  2 files changed, 31 insertions(+), 32 deletions(-)
> 
> diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> index 9db3c2eaf2..44e8842db8 100644
> --- a/hw/acpi/pcihp.c
> +++ b/hw/acpi/pcihp.c
> @@ -75,6 +75,36 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
>  }
>  }
>  
> +/* Assign BSEL property to all buses.  In the future, this can be changed
> + * to only assign to buses that support hotplug.
> + */
> +static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> +{
> +unsigned *bsel_alloc = opaque;
> +unsigned *bus_bsel;
> +
> +if (qbus_is_hotpluggable(BUS(bus))) {
> +bus_bsel = g_malloc(sizeof *bus_bsel);
> +
> +*bus_bsel = (*bsel_alloc)++;
> +object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
> +   bus_bsel, _abort);
> +}
> +
> +return bsel_alloc;
> +}
> +
> +static void acpi_set_pci_info(void)
> +{
> +PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> +unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> +
> +if (bus) {
> +/* Scan all PCI buses. Set property to enable acpi based hotplug. */
> +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, _alloc);
> +}
> +}
> +
>  static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
>  {
>  AcpiPciHpFind *find = opaque;
> @@ -177,6 +207,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
>  
>  void acpi_pcihp_reset(AcpiPciHpState *s)
>  {
> +acpi_set_pci_info();
>  acpi_pcihp_update(s);
>  }
>  
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 98dd424678..4d19d91e1b 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -493,36 +493,6 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
> PCMachineState *pcms)
>   table_data->len - madt_start, 1, NULL, NULL);
>  }
>  
> -/* Assign BSEL property to all buses.  In the future, this can be changed
> - * to only assign to buses that support hotplug.
> - */
> -static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> -{
> -unsigned *bsel_alloc = opaque;
> -unsigned *bus_bsel;
> -
> -if (qbus_is_hotpluggable(BUS(bus))) {
> -bus_bsel = g_malloc(sizeof *bus_bsel);
> -
> -*bus_bsel = (*bsel_alloc)++;
> -object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
> -   bus_bsel, _abort);
> -}
> -
> -return bsel_alloc;
> -}
> -
> -static void acpi_set_pci_info(void)
> -{
> -PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> -unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> -
> -if (bus) {
> -/* Scan all PCI buses. Set property to enable acpi based hotplug. */
> -pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, _alloc);
> -}
> -}
> -
>  static void build_append_pcihp_notify_entry(Aml *method, int slot)
>  {
>  Aml *if_ctx;
> @@ -2888,8 +2858,6 @@ void acpi_setup(void)
>  
>  build_state = g_malloc0(sizeof *build_state);
>  
> -acpi_set_pci_info();
> -
>  acpi_build_tables_init();
>  acpi_build(, MACHINE(pcms));
>  


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

Re: [Xen-devel] [PATCH for-2.10 v3 2/3] hw/acpi: Move acpi_set_pci_info to pcihp

[Igor Mammedov]

On Fri, 18 Aug 2017 04:40:02 +0300
"Michael S. Tsirkin"  wrote:

> On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> > This means that the function will be call and the property
> > acpi-pcihp-bsel will be set even if ACPI build is disable.
> > 
> > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > set, but this was done only when ACPI tables are built which is not
> > needed for a Xen guest. The need for the property starts with commit
> > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > 
> > Reported-by: Sander Eikelenboom 
> > Signed-off-by: Anthony PERARD 
> > 
> > ---
> > Changes in V3:
> >   - move acpi_set_pci_info to pcihp instead
> > 
> > Changes in V2:
> >   - check for acpi_enabled before calling acpi_set_pci_info.
> >   - set the property on the root bus only.
> > 
> > This patch would be a canditade to backport to 2.9, along with
> > "hw/acpi: Limit hotplug to root bus on legacy mode"
> > 
> > CC: Stefano Stabellini 
> > CC: Bruce Rogers 
> > ---
> >  hw/acpi/pcihp.c  | 31 +++
> >  hw/i386/acpi-build.c | 32 
> >  2 files changed, 31 insertions(+), 32 deletions(-)
> > 
> > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > index 9db3c2eaf2..44e8842db8 100644
> > --- a/hw/acpi/pcihp.c
> > +++ b/hw/acpi/pcihp.c
> > @@ -75,6 +75,36 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
> >  }
> >  }
> >  
> > +/* Assign BSEL property to all buses.  In the future, this can be changed
> > + * to only assign to buses that support hotplug.
> > + */
> > +static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> > +{
> > +unsigned *bsel_alloc = opaque;
> > +unsigned *bus_bsel;
> > +
> > +if (qbus_is_hotpluggable(BUS(bus))) {
> > +bus_bsel = g_malloc(sizeof *bus_bsel);
> > +
> > +*bus_bsel = (*bsel_alloc)++;
> > +object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
> > +   bus_bsel, _abort);
> > +}
> > +
> > +return bsel_alloc;
> > +}
> > +
> > +static void acpi_set_pci_info(void)
> > +{
> > +PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
> > +unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> > +
> > +if (bus) {
> > +/* Scan all PCI buses. Set property to enable acpi based hotplug. 
> > */
> > +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > _alloc);
> > +}
> > +}
> > +
> >  static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
> >  {
> >  AcpiPciHpFind *find = opaque;
> > @@ -177,6 +207,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
> >  
> >  void acpi_pcihp_reset(AcpiPciHpState *s)
> >  {
> > +acpi_set_pci_info();
> >  acpi_pcihp_update(s);
> >  }  
> 
> IIUC doing this on reset will add property over and over again leaking
> memory.
in v2 I've explicitly suggested to call it once, like:

acpi_set_pci_info() {

   static bool bsel_is set;

   if (bsel_is set)
   return;
   bsel_is set = true;

   ...
}

not patch related:
BTW bsel assignment is not stable in hotplug + migration use case,
and we probably should fix it up in 2.11 (CCing Marcel)

> I think that we need to do it on machine done.
> 
> Igor,  I think reordering acpi-build like earlier version did
> is less intrusive and more appropriate for 2.10.
> 
> For 2.10 I would like to see ideally some changes that
> are all if (xen) making it obvious non xen is not
> affected. I can then ack it and it will be merged in xen tree.
it didn't work before so I'd just push fix to 2.11 without
intermediate fix.
But if you guys think it's worth to fix in 2.10, I'm fine with v2
for it if Anthony will take care of it (rebase this series)
in 2.11 merge window.


> 
> Clean it up after 2.10.
> 
> >  
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index 98dd424678..4d19d91e1b 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -493,36 +493,6 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
> > PCMachineState *pcms)
> >   table_data->len - madt_start, 1, NULL, NULL);
> >  }
> >  
> > -/* Assign BSEL property to all buses.  In the future, this can be changed
> > - * to only assign to buses that support hotplug.
> > - */
> > -static void *acpi_set_bsel(PCIBus *bus, void *opaque)
> > -{
> > -unsigned *bsel_alloc = opaque;
> > -unsigned *bus_bsel;
> > -
> > -if (qbus_is_hotpluggable(BUS(bus))) {
> > -bus_bsel = g_malloc(sizeof *bus_bsel);
> > -
> > -*bus_bsel = (*bsel_alloc)++;
> > -object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
> > -   bus_bsel, _abort);
> > -}
> > -
> > -return bsel_alloc;
> > -}
> > -
> > -static void acpi_set_pci_info(void)
> > -{
> > -PCIBus *bus 

Re: [Xen-devel] [PATCH v1 07/13] x86: implement set value flow for MBA

[Yi Sun]

On 17-08-18 11:32:08, Chao Peng wrote:
> 
> > +if ( feat->mba_info.linear )
> > +{
> > +unsigned int mod;
> > +
> > +if ( feat->mba_info.thrtl_max >= 100 )
> > +return false;
> 
> Can we do this check earlier, e.g. when it gets enumerated from CPUID?
> 
Ok, sound reasonable.

> > +
> > +mod = *thrtl % (100 - feat->mba_info.thrtl_max);
> > +*thrtl -= mod;
> > +}
> > +else
> > +{
> > +/* Not power of 2. */
> > +if ( *thrtl & (*thrtl - 1) )
> > +*thrtl = *thrtl & (1 << (flsl(*thrtl) - 1));
> > +}
> > +
> 
> Is it possible for *thrtl to be zero? Otherwise we need check that at
> the beginning.
> 
Yes, it could be 0. I missed this. Code should be:
if ( *thrtl && (*thrtl & (*thrtl - 1)) )

> >  
> > +/*
> > + * Because multiple features may co-exist, we need handle all
> > features to write
> > + * values of them into a COS register with new COS ID. E.g:
> > + * 1. L3 CAT and MBA co-exist.
> > + * 2. Dom1 and Dom2 share a same COS ID (2). The L3 CAT CBM of Dom1
> > is 0x1ff,
> > + *the MBA Thrtle of Dom1 is 0xa.
> > + * 3. User wants to change MBA Thrtl of Dom1 to be 0x14. Because COS
> > ID 2 is
> > + *used by Dom2 too, we have to pick a new COS ID 3. The original
> > values of
> > + *Dom1 on COS ID 3 may be below:
> > + *-
> > + *| COS 3 |
> > + *-
> > + *L3 CAT  | 0x7ff |
> > + *-
> > + *MBA | 0x0   |
> > + *-
> > + * 4. After setting, the L3 CAT CBM value of Dom1 should be kept and
> > the new MBA
> > + *Thrtl is set. So, the values on COS ID 3 should be below.
> > + *-
> > + *| COS 3 |
> > + *-
> > + *L3 CAT  | 0x1ff |
> > + *-
> > + *MBA | 0x14  |
> > + *-
> > + *
> > + * So, we should write all features values into their MSRs. That
> > requires the
> > + * feature array, feature properties array and value array are input.
> > + */
> 
> Although I understand them, I still have a feeling of the necessity to
> reword these comments.
> 
How about move comments into commit message?

> Chao

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

Re: [Xen-devel] [PATCH RFC] x86: enable RCU based table free when PARAVIRT

[Vitaly Kuznetsov]

Juergen Gross  writes:

> On 17/08/17 11:20, Vitaly Kuznetsov wrote:
>> On x86 software page-table walkers depend on the fact that remote TLB flush
>> does an IPI: walk is performed lockless but with interrupts disabled and in
>> case the pagetable is freed the freeing CPU will get blocked as remote TLB
>> flush is required. On other architecture which don't require an IPI to do
>> remote TLB flush we have an RCU-based mechanism (see
>> include/asm-generic/tlb.h for more details).
>> 
>> In virtualized environments we may want to override .flush_tlb_others hook
>> in pv_mmu_ops and use a hypercall asking the hypervisor to do remote TLB
>> flush for us. This breaks the assumption about IPI. Xen PV does this for
>> years and the upcoming remote TLB flush for Hyper-V will do it too. This
>> is not safe, software pagetable walkers may step on an already freed page.
>> 
>> Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
>> is selected in config. Testing with kernbench doesn't show any notable
>> performance impact:
>> 
>> 6-CPU host:
>> 
>> Average Half load -j 3 Run (std deviation):
>> CURRENT HAVE_RCU_TABLE_FREE
>> === ===
>> Elapsed Time 400.498 (0.179679) Elapsed Time 399.909 (0.162853)
>> User Time 1098.72 (0.278536)User Time 1097.59 (0.283894)
>> System Time 100.301 (0.201629)  System Time 99.736 (0.196254)
>> Percent CPU 299 (0) Percent CPU 299 (0)
>> Context Switches 5774.1 (69.2121)   Context Switches 5744.4 (79.4162)
>> Sleeps 87621.2 (78.1093)Sleeps 87586.1 (99.7079)
>> 
>> Average Optimal load -j 24 Run (std deviation):
>> CURRENT HAVE_RCU_TABLE_FREE
>> === ===
>> Elapsed Time 219.03 (0.652534)  Elapsed Time 218.959 (0.598674)
>> User Time 1119.51 (21.3284) User Time 1118.81 (21.7793)
>> System Time 100.499 (0.389308)  System Time 99.8335 (0.251423)
>> Percent CPU 432.5 (136.974) Percent CPU 432.45 (136.922)
>> Context Switches 81827.4 (78029.5)  Context Switches 81818.5 (78051)
>> Sleeps 97124.8 (9822.4) Sleeps 97207.9 (9955.04)
>> 
>> 6-CPU host:
>
> I guess this is wrong information ...

Oops, is was 16, not 6!  :-)

>
>> 
>> Average Half load -j 8 Run (std deviation):
>> CURRENT HAVE_RCU_TABLE_FREE
>> === ===
>> Elapsed Time 213.538 (3.7891)   Elapsed Time 212.5 (3.10939)
>> User Time 1306.4 (1.83399)  User Time 1307.65 (1.01364)
>> System Time 194.59 (0.864378)   System Time 195.478 (0.794588)
>> Percent CPU 702.6 (13.5388) Percent CPU 707 (11.1131)
>> Context Switches 21189.2 (1199.4)   Context Switches 21288.2 (552.388)
>> Sleeps 89390.2 (482.325)Sleeps 89677 (277.06)
>> 
>> Average Optimal load -j 64 Run (std deviation):
>> CURRENT HAVE_RCU_TABLE_FREE
>> === ===
>> Elapsed Time 137.866 (0.787928) Elapsed Time 138.438 (0.218792)
>> User Time 1488.92 (192.399) User Time 1489.92 (192.135)
>> System Time 234.981 (42.5806)   System Time 236.09 (42.8138)
>> Percent CPU 1057.1 (373.826)Percent CPU 1057.1 (369.114)
>
> ... as I suspect more than 100% usage per cpu are rather unlikely. :-)
>
>> Context Switches 187514 (175324)Context Switches 187358 (175060)
>> Sleeps 112633 (24535.5) Sleeps 111743 (23297.6)
>> 
>> Suggested-by: Peter Zijlstra 
>> Signed-off-by: Vitaly Kuznetsov 
>
> Acked-by: Juergen Gross 
>

Thanks!

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[Roger Pau Monné]

On Thu, Aug 17, 2017 at 06:43:46PM -0400, Annie Li wrote:
> If there is inflight I/O in any non-last queue, blkback returns -EBUSY
> directly, and never stops thread of remaining queue and processs them. When
> removing vbd device with lots of disk I/O load, some queues with inflight
> I/O still have blkback thread running even though the corresponding vbd
> device or guest is gone.
> And this could cause some problems, for example, if the backend device type
> is file, some loop devices and blkback thread always lingers there forever
> after guest is destroyed, and this causes failure of umounting repositories
> unless rebooting the dom0. So stop all threads properly and return -EBUSY
> if any queue has inflight I/O.
>
> Signed-off-by: Annie Li 
> Reviewed-by: Herbert van den Bergh 
> Reviewed-by: Bhavesh Davda 
> Reviewed-by: Adnan Misherfi 
> ---
>  drivers/block/xen-blkback/xenbus.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 792da68..2adb859 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
>  {
>   struct pending_req *req, *n;
>   unsigned int j, r;
> + bool busy = false;
>  
>   for (r = 0; r < blkif->nr_rings; r++) {
>   struct xen_blkif_ring *ring = >rings[r];
> @@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
>* don't have any discard_io or other_io requests. So, checking
>* for inflight IO is enough.
>*/
> - if (atomic_read(>inflight) > 0)
> - return -EBUSY;
> + if (atomic_read(>inflight) > 0) {
> + busy = true;
> + continue;
> + }

I guess I'm missing something, but I don't see how this is solving the
problem described in the description.

If the problem is that xen_blkif_disconnect returns without cleaning
all the queues, this patch keeps the current behavior, just that it
will try to remove more queues before returning, as opposed to
returning when finding the first busy queue.

Roger.

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

Re: [Xen-devel] [PATCHES v8 1/8] mm: Place unscrubbed pages at the end of pagelist

[Jan Beulich]

>>> On 16.08.17 at 20:33,  wrote:
> .. so that it's easy to find pages that need to be scrubbed (those pages are
> now marked with _PGC_need_scrub bit).
> 
> We keep track of the first unscrubbed page in a page buddy using first_dirty
> field. For now it can have two values, 0 (whole buddy needs scrubbing) or
> INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent patches
> will allow scrubbing to be interrupted, resulting in first_dirty taking any
> value.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Jan Beulich 
with one remark:

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -261,7 +261,11 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
>  #ifdef CONFIG_X86
>  const unsigned long *badpage = NULL;
>  unsigned int i, array_size;
> +
> +BUILD_BUG_ON(8 * sizeof(((struct page_info *)0)->u.free.first_dirty) <
> + MAX_ORDER + 1);
>  #endif
> +BUILD_BUG_ON(sizeof(((struct page_info *)0)->u) != sizeof(unsigned 
> long));

As I'm generally opposed to casts whenever one can get away
without, I dislike these as well. In the case here, short of a local
variable of suitable type, I'd suggest using frame_table instead
of the open-coded cast. If you're fine with that, this can easily
be done while committing.

Jan


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

Re: [Xen-devel] [PATCH RFC] x86: enable RCU based table free when PARAVIRT

[Juergen Gross]

On 17/08/17 11:20, Vitaly Kuznetsov wrote:
> On x86 software page-table walkers depend on the fact that remote TLB flush
> does an IPI: walk is performed lockless but with interrupts disabled and in
> case the pagetable is freed the freeing CPU will get blocked as remote TLB
> flush is required. On other architecture which don't require an IPI to do
> remote TLB flush we have an RCU-based mechanism (see
> include/asm-generic/tlb.h for more details).
> 
> In virtualized environments we may want to override .flush_tlb_others hook
> in pv_mmu_ops and use a hypercall asking the hypervisor to do remote TLB
> flush for us. This breaks the assumption about IPI. Xen PV does this for
> years and the upcoming remote TLB flush for Hyper-V will do it too. This
> is not safe, software pagetable walkers may step on an already freed page.
> 
> Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> is selected in config. Testing with kernbench doesn't show any notable
> performance impact:
> 
> 6-CPU host:
> 
> Average Half load -j 3 Run (std deviation):
> CURRENT HAVE_RCU_TABLE_FREE
> === ===
> Elapsed Time 400.498 (0.179679) Elapsed Time 399.909 (0.162853)
> User Time 1098.72 (0.278536)User Time 1097.59 (0.283894)
> System Time 100.301 (0.201629)  System Time 99.736 (0.196254)
> Percent CPU 299 (0) Percent CPU 299 (0)
> Context Switches 5774.1 (69.2121)   Context Switches 5744.4 (79.4162)
> Sleeps 87621.2 (78.1093)Sleeps 87586.1 (99.7079)
> 
> Average Optimal load -j 24 Run (std deviation):
> CURRENT HAVE_RCU_TABLE_FREE
> === ===
> Elapsed Time 219.03 (0.652534)  Elapsed Time 218.959 (0.598674)
> User Time 1119.51 (21.3284) User Time 1118.81 (21.7793)
> System Time 100.499 (0.389308)  System Time 99.8335 (0.251423)
> Percent CPU 432.5 (136.974) Percent CPU 432.45 (136.922)
> Context Switches 81827.4 (78029.5)  Context Switches 81818.5 (78051)
> Sleeps 97124.8 (9822.4) Sleeps 97207.9 (9955.04)
> 
> 6-CPU host:

I guess this is wrong information ...

> 
> Average Half load -j 8 Run (std deviation):
> CURRENT HAVE_RCU_TABLE_FREE
> === ===
> Elapsed Time 213.538 (3.7891)   Elapsed Time 212.5 (3.10939)
> User Time 1306.4 (1.83399)  User Time 1307.65 (1.01364)
> System Time 194.59 (0.864378)   System Time 195.478 (0.794588)
> Percent CPU 702.6 (13.5388) Percent CPU 707 (11.1131)
> Context Switches 21189.2 (1199.4)   Context Switches 21288.2 (552.388)
> Sleeps 89390.2 (482.325)Sleeps 89677 (277.06)
> 
> Average Optimal load -j 64 Run (std deviation):
> CURRENT HAVE_RCU_TABLE_FREE
> === ===
> Elapsed Time 137.866 (0.787928) Elapsed Time 138.438 (0.218792)
> User Time 1488.92 (192.399) User Time 1489.92 (192.135)
> System Time 234.981 (42.5806)   System Time 236.09 (42.8138)
> Percent CPU 1057.1 (373.826)Percent CPU 1057.1 (369.114)

... as I suspect more than 100% usage per cpu are rather unlikely. :-)

> Context Switches 187514 (175324)Context Switches 187358 (175060)
> Sleeps 112633 (24535.5) Sleeps 111743 (23297.6)
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: Juergen Gross 


Thanks,

Juergen

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

Re: [Xen-devel] [PATCH 12/12] xen-blkfront: Avoid that gcc 7 warns about fall-through when building with W=1

[Roger Pau Monn303251]

On Thu, Aug 17, 2017 at 04:23:11PM -0700, Bart Van Assche wrote:
> Signed-off-by: Bart Van Assche 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Roger Pau Monn303251 
> Cc: xen-de...@lists.xenproject.org
> ---
>  drivers/block/xen-blkfront.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 98e34e4c62b8..270019e3e5d8 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2456,7 +2456,7 @@ static void blkback_changed(struct xenbus_device *dev,
>   case XenbusStateClosed:
>   if (dev->state == XenbusStateClosed)
>   break;
> - /* Missed the backend's Closing state -- fallthrough */
> + /* fall through */

This is losing information present in the original comment. Would
splitting the comment into two make gcc happy?

Roger.

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

Re: [Xen-devel] [PATCH V2 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

[Lan Tianyu]

On 2017年08月18日 16:41, Jan Beulich wrote:
 On 18.08.17 at 02:22,  wrote:
>> This patch is to introduct an abstract layer for arch vIOMMU implementation
>> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
>> to perform create, destroy and query capabilities operation.
>>
>> Signed-off-by: Lan Tianyu 
> 
> What is this? It looks to be a standalone patch when there was
> a V2 series a couple of days ago with 1/25 titled "DOMCTL:
> Introduce new DOMCTL commands for vIOMMU support". I'm
> confused.
> 
> Jan
> 
Hi Jan:
Sorry. Missed this patch in this patchset and this should be the first
one. I will send v3 with some fixs.
-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH V2 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

[Jan Beulich]

>>> On 18.08.17 at 02:22,  wrote:
> This patch is to introduct an abstract layer for arch vIOMMU implementation
> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
> to perform create, destroy and query capabilities operation.
> 
> Signed-off-by: Lan Tianyu 

What is this? It looks to be a standalone patch when there was
a V2 series a couple of days ago with 1/25 titled "DOMCTL:
Introduce new DOMCTL commands for vIOMMU support". I'm
confused.

Jan


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

Re: [Xen-devel] [PATCH 10/12] xen-blkback: Fix indentation

[Hannes Reinecke]

On 08/18/2017 01:23 AM, Bart Van Assche wrote:
> Avoid that smatch reports the following warning when building with
> C=2 CHECK="smatch -p=kernel":
> 
> drivers/block/xen-blkback/blkback.c:710 xen_blkbk_unmap_prepare() warn: 
> inconsistent indenting
> 
> Signed-off-by: Bart Van Assche 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Roger Pau Monn303251 
> Cc: xen-de...@lists.xenproject.org
> ---
>  drivers/block/xen-blkback/blkback.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index fe7cd58c43d0..68157a84bf4d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -705,9 +705,9 @@ static unsigned int xen_blkbk_unmap_prepare(
>   GNTMAP_host_map, pages[i]->handle);
>   pages[i]->handle = BLKBACK_INVALID_HANDLE;
>   invcount++;
> -   }
> + }
>  
> -   return invcount;
> + return invcount;
>  }
>  
>  static void xen_blkbk_unmap_and_respond_callback(int result, struct 
> gntab_unmap_queue_data *data)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

Re: [Xen-devel] [PATCH 11/12] xen-blkback: Avoid that gcc 7 warns about fall-through when building with W=1

[Hannes Reinecke]

On 08/18/2017 01:23 AM, Bart Van Assche wrote:
> Signed-off-by: Bart Van Assche 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Roger Pau Monn303251 
> Cc: xen-de...@lists.xenproject.org
> ---
>  drivers/block/xen-blkback/blkback.c | 1 +
>  drivers/block/xen-blkback/xenbus.c  | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index 68157a84bf4d..5f3a813e7ae0 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -1251,6 +1251,7 @@ static int dispatch_rw_block_io(struct xen_blkif_ring 
> *ring,
>   break;
>   case BLKIF_OP_WRITE_BARRIER:
>   drain = true;
> + /* fall through */
>   case BLKIF_OP_FLUSH_DISKCACHE:
>   ring->st_f_req++;
>   operation = REQ_OP_WRITE;
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 792da683e70d..88eaea6475d7 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -810,7 +810,8 @@ static void frontend_changed(struct xenbus_device *dev,
>   xenbus_switch_state(dev, XenbusStateClosed);
>   if (xenbus_dev_is_online(dev))
>   break;
> - /* fall through if not online */
> + /* fall through */
> + /* if not online */
>   case XenbusStateUnknown:
>   /* implies xen_blkif_disconnect() via xen_blkbk_remove() */
>   device_unregister(>dev);
> 
Oh well, gcc again.

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 08/18/2017 10:17 AM, Takashi Sakamoto wrote:

On Aug 18 2017 14:56, Oleksandr Andrushchenko wrote:
Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


You mean that any alsa-lib or libpulse applications run on Dom0 as a
backend driver for the frontend driver on DomU?

No, the sound backend [1] is a user-space application (ALSA/PulseAudio 
client)

which runs as a Xen para-virtual backend in Dom0 and serves all the
frontends running in DomU(s).
Other ALSA/PulseAudio clients in Dom0 are also allowed to run at the
same time.


Regards

Takashi Sakamoto

Thank you,
Oleksandr

[1] https://github.com/xen-troops/snd_be

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

Re: [Xen-devel] [PATCH V2 4/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

On 2017年08月17日 19:19, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
>> +Now just suppport single vIOMMU for one VM and introduced domctls are 
>> compatible
>> +with multi-vIOMMU support.
> 
> Is this still true? 

Yes, the patchset just supports single vIOMMU for one VM.

> There is an ID field in the struct which can
> distinguish multiple viommus, right?

Yes, this is reserved for mult vIOMMU support.

> 
>> +
>> +xl vIOMMU configuration
>> +===
>> +viommu="type=intel_vtd,intremap=1,x2apic=1"
> 
> If there is provision to support multiple viommu please make this an
> array.

Ok. Will update.
-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

On Aug 18 2017 14:56, Oleksandr Andrushchenko wrote:
Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


You mean that any alsa-lib or libpulse applications run on Dom0 as a
backend driver for the frontend driver on DomU?


Regards

Takashi Sakamoto

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