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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 02d6f4ce0c84f2d7e9abfcde2e092a5701ff33c4
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  103 days
Failing since 65593  2015-12-08 23:44:51 Z  103 days  113 attempts
Testing same since86648  2016-03-19 14:22:42 Z1 days2 attempts


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

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



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

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

Explanation of these reports, and of osstest in general, is at

Re: [Xen-devel] List of projects for 4.7

[Juergen Gross]

On 18/03/16 13:07, Wei Liu wrote:
> Hi all
> 
> Today is that last posting day for new features. And we are two weeks
> away from the anticipated freeze date.
> 
> I've gone through the outstanding patch series on the list and ask for
> input from various core community members. I've enumerated a list
> here, which covers several areas of this release and can be used as a
> guideline.
> 
> Important and close patch, new features:
> 1. xSplice
> 2. CPUID levelling
> 3. ARM ACPI
> 4. COLO HA
> 5. RTDS per-vcpu parameter setting
> 6. Event driven RTDS
> 
> Important bug fixes:
> 1. Intel VT-d flush issue
> 2. SMEP / SMAP fix
> 3. QEMU hotplug script fix
> 
> Note, it is possible for bug fixes to go in after freeze.
> 
> Nice to have, not very complicated patch sets:
> 1. IOREQ server P2M type
> 2. QEMU-based PVUSB backend

qemu-parts: Gerd Hoffmann would apply the patches after a review of xen
folks - any volunteer? :-)

xen tools parts: V2 will be sent as soon as some last details regarding
V1 have been discussed

> 3. Oxenstored improvement
> 4. Load bios via toolstack

What about my pending "pin override" tools related patches? Hypervisor
parts are already committed.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linuxc2a20948484b0a4b20a930cbca8fd72f4da3784f
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  221 days
Failing since 60712  2015-08-15 18:33:48 Z  218 days  163 attempts
Testing same since86709  2016-03-20 04:28:46 Z1 days1 attempts

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

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

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 18, 2016 4:06 PM
> 
> >>> On 18.03.16 at 03:30,  wrote:
> > Any good idea? To be honest, I am very tired to at splitting things like
> > this :).
> 
> I understand that this is a tedious task; the code should have been
> propagating errors from the beginning.
> 
> The most natural way of splitting things would be to go function by
> function, top level ones first, and leaf ones last, one function per
> patch (maybe pairs of functions, as in the map/unmap case). Such
> model would be problematic (almost) only when there's recursion at
> some point, which I don't think would be the case anywhere here.
> As mentioned before, the __must_check annotation is a great help
> to not miss any callers - both to you as you put things together and
> to the reviewers to be ascertained that nothing was missed.
> 

Agree with this suggestion. It also allows different maintainers
to focus on changes they really need to care about.

Thanks
Kevin


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

[Xen-devel] [xen-4.6-testing baseline-only test] 44265: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44242
 build-armhf   3 host-install(3) broken REGR. vs. 44242
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44242

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels 
fail REGR. vs. 44242
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 44242
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44242
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44242
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 44242
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44242
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44242
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 44242

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

version targeted for testing:
 xen  8e89d43867922abaa67e894938c655a6fa82affe
baseline version:
 xen  e0493703a96c03aaafc8d179624b89b7cf600916

Last test of basis44242  2016-03-11 15:49:07 Z9 days
Testing same since44265  2016-03-20 14:05:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Vrabel 
  Jan Beulich 
  Kevin Tian 
  Ross Lagerwall 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen

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

[osstest service owner]

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

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  7dbcb26f7f67b9ff2bee47e6144763a3d729717e
  Bug not present: 8054706c3fad02e044297bc791cef1f92aee7e74
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/86762/


  commit 7dbcb26f7f67b9ff2bee47e6144763a3d729717e
  Author: Michal Privoznik 
  Date:   Sun Feb 14 11:38:37 2016 +0100
  
  nss: Implement _nss_libvirt_gethostbyname3_r
  
  The implementation is pretty straightforward. Moreover, because
  of the nature of things, gethostbyname_r and gethostbyname2_r can
  be implemented at the same time too.
  
  Signed-off-by: Michal Privoznik 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-armhf-libvirt.libvirt-build 
--summary-out=tmp/86777.bisection-summary --basis-template=86536 
--blessings=real,real-bisect libvirt build-armhf-libvirt libvirt-build
Searching for failure / basis pass:
 86710 fail [host=arndale-bluewater] / 86536 ok.
Failure / basis pass flights: 86710 / 86536
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c770472c481e4737bcf4058183d6d2eab17058b9 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
Basis pass 9a0c7f5f834185db9017c34aabc03ad99cf37bed 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
efc904263f483026672a5cdf3ccf9be8c4fdaa31
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#9a0c7f5f834185db9017c34aabc03ad99cf37bed-c770472c481e4737bcf4058183d6d2eab17058b9
 
git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-6cc32c63e80bc1a30c521b2f07f2b54909b59892
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e
 
git://xenbits.xen.org/xen.git#efc904263f483026672a5cdf3ccf9be8c4fdaa31-a6f2cdb633bf519244a16674031b8034b581ba7f
Loaded 2002 nodes in revision graph
Searching for test results:
 86516 [host=cubietruck-metzinger]
 86558 [host=arndale-metrocentre]
 86536 pass 9a0c7f5f834185db9017c34aabc03ad99cf37bed 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
efc904263f483026672a5cdf3ccf9be8c4fdaa31
 86689 pass 9a0c7f5f834185db9017c34aabc03ad99cf37bed 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
efc904263f483026672a5cdf3ccf9be8c4fdaa31
 86625 fail 2dabe2e03e2ebd7ef28f2c61a019330a172b43a7 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86736 fail 2dabe2e03e2ebd7ef28f2c61a019330a172b43a7 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86739 pass efb5e46b6c2ee157fee90bfb65ca60dce13056a2 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86741 pass 8054706c3fad02e044297bc791cef1f92aee7e74 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86744 fail 38e32d4ac134aa6da411b0093e788bce35775d09 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86754 pass 8054706c3fad02e044297bc791cef1f92aee7e74 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86745 fail 7dbcb26f7f67b9ff2bee47e6144763a3d729717e 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86748 pass 8054706c3fad02e044297bc791cef1f92aee7e74 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86710 fail c770472c481e4737bcf4058183d6d2eab17058b9 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 86762 fail 7dbcb26f7f67b9ff2bee47e6144763a3d729717e 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
316a862e5534249a6e6d876b4e203342d3fb870e 

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

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, March 18, 2016 8:22 PM
> 
> > > +int dev_invalidate_iotlb_sync(struct iommu *iommu, u16 did,
> > > +  u16 seg, u8 bus, u8 devfn) {
> > > +struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
> > > +int rc = 0;
> > > +
> > > +if ( qi_ctrl->qinval_maddr )
> > > +{
> > > +rc = queue_invalidate_wait(iommu, 0, 1, 1);
> > > +if ( rc == -ETIMEDOUT )
> > > +dev_invalidate_iotlb_timeout(iommu, did, seg, bus, devfn);
> > > +}
> > > +
> > > +return rc;
> > > +}
> > > +
> >
> > Is this function a temporary one which will be removed later once we can
> > handle timeout for all types of flushes (at that time suppose this logic 
> > will be
> > reflected in invalidate_sync directly)?
> >
> No, it's not a temporary one.
> dev_invalidate_iotlb_sync -- for Device-TLB invalidation sync, as we need 
> SBDF to indicate
> which device flush timed out.
> invalidate_sync -- for VT-d iotlb/iec/context invalidation sync.

Thanks. I recalled it. Once you defined some INVALID seg/bus/devfn to
reuse same interface, and then the suggestion is to go with different
interfaces.:-)

> 
> 
> > >  static void queue_invalidate_iec(struct iommu *iommu, u8 granu, u8
> > > im, u16 iidx)  {
> > >  unsigned long flags;
> > > @@ -342,8 +393,6 @@ static int flush_iotlb_qi(
> > >
> > >  if ( qi_ctrl->qinval_maddr != 0 )
> > >  {
> > > -int rc;
> > > -
> > >  /* use queued invalidation */
> > >  if (cap_write_drain(iommu->cap))
> > >  dw = 1;
> > > @@ -353,11 +402,17 @@ static int flush_iotlb_qi(
> > >  queue_invalidate_iotlb(iommu,
> > > type >>
> > DMA_TLB_FLUSH_GRANU_OFFSET, dr,
> > > dw, did, size_order, 0, addr);
> > > +
> > > +/*
> > > + * Before Device-TLB invalidation we need to synchronize
> > > + * invalidation completions with hardware.
> > > + */
> > > +ret = invalidate_sync(iommu);
> > > +if ( ret )
> > > + return ret;
> > > +
> > >  if ( flush_dev_iotlb )
> > >  ret = dev_invalidate_iotlb(iommu, did, addr, size_order, 
> > > type);
> > > -rc = invalidate_sync(iommu);
> > > -if ( !ret )
> > > -ret = rc;
> >
> > Current change looks not consistent. For IOMMU iotlb flush, we have
> > invalidate_sync out of invalidate operation, however below...
> >
> 
> Now, does it still look not consistent?
> 

Yes, still inconsistent. As I said, you put invalidation sync within 
dev_invalidate_iotlb, while for all other IOMMU invalidations the
sync is put after. Below would be consistent then:

if ( flush_dev_iotlb )
ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
rc = dev_invalidate_iotlb_sync(...);
if ( !ret )
ret = rc;

Thanks
Kevin

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

[Xen-devel] [xen-4.3-testing test] 86673: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  4db81940ee9eb82b3b3895c449ccbbab4a7147a4
baseline version:
 xen  ccc7adf9cff5d5f93720afcc1d0f7227d50feab2

Last test of basis83004  2016-02-18 14:47:44 Z   31 days
Failing since 84923  2016-03-01 13:41:07 Z   19 days   23 attempts
Testing same since85979  2016-03-11 05:16:24 Z9 days   12 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  fail
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  fail
 test-armhf-armhf-xl-cubietruck   

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 86536

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  c770472c481e4737bcf4058183d6d2eab17058b9
baseline version:
 libvirt  9a0c7f5f834185db9017c34aabc03ad99cf37bed

Last test of basis86536  2016-03-18 04:25:19 Z2 days
Failing since 86625  2016-03-19 04:23:22 Z1 days2 attempts
Testing same since86710  2016-03-20 04:28:04 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Jim Fehlig 
  John Ferlan 
  Martin Kletzander 
  Michal Privoznik 

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



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

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

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

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


Not pushing.


commit c770472c481e4737bcf4058183d6d2eab17058b9
Author: Cole Robinson 
Date:   Fri Mar 18 18:33:05 2016 -0400

bhyve: caps: Log error message when CPU init fails

virBhyveCapsInitCPU will raise a libvirt error; even though we treat
it as non-fatal we should log the actual message.

commit 2dabe2e03e2ebd7ef28f2c61a019330a172b43a7
Author: Cole Robinson 
Date:   Wed Jan 6 15:44:30 2016 -0500

domain: Remove controller/net address whitelists

Judging by how the whitelist has skewed quite far from the original
error message, I think it's better to just drop these.

If someone wants to revive 

Re: [Xen-devel] Xen components.

[Daniele Palumbo]

Il giorno 20/mar/2016, alle ore 20:11, Jason Long  ha 
scritto:
> any idea?

FAQ?



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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  11 guest-startfail in 86587 pass in 86654
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 86587 pass 
in 86654
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 86587

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 86587 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 86587 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux7f30737678023b5becaf0e2e012665f71b886a7d
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   96 days
Failing since 78925  2016-01-24 13:50:39 Z   56 days   60 attempts
Testing same since86587  2016-03-18 16:11:01 Z2 days2 attempts


494 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] Xen components.

[Jason Long]

any idea?



On Saturday, March 19, 2016 9:58 AM, Jason Long  wrote:
Hello all.
Can anyone tell me about Xen components? For example, It consist of Dom0, DomU, 
Qemu and...

Thank you. 

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

Re: [Xen-devel] Interested to participate in Outreachy Program

[sabiya kazi]

Hi Doug,
 I am done with building of xen source.Now, I have started looking
at source files and identifying changes required for given task.

   As you suggested, I went through virsh command source to get idea how
escape sequence char option is implemented. Based on that,I came up with
following findings:
*To complete this task, Steps will be*


   1. Do help related change in libxl/xl_cmdtable.c
   2. Add handling of one more option for command 'xl console' in file
   xl_cmdimpl.c in method  main_console.  From this method, call is delegated
   to libxl_console_exec() in libxl.c
   3. libxl_console_exec delegates to execl(), Do some changes in this
   method.


*Question/Doubts:*

   -  Where I need to use this escape char?
   -  libxl_console_exec() is called by many methods Will it affect other
   flows as well?
   - Could not find execl method implementation where it actually prints
   data
   - Changes for handling escape char are not cleared

Can you please help me on this?
Regards,
-Sabiya



On Sat, Mar 19, 2016 at 11:31 PM, sabiya kazi  wrote:

> Hi Doug,
> I have started building xen source.
> Can you help me on issue of creating guest domain?
>
>
> Regards,
> -Sabiya
>
> On Fri, Mar 18, 2016 at 1:18 AM, sabiya kazi  wrote:
>
>> Hi Doug,
>>
>> I have proceeded on xen installation. I have configured grub to use xen,
>> I could see xl command and tried it's few options.
>>
>> However, I am getting failure while creating a Debian PV Guest using
>>
>> xen-create-image --hostname=tutorial-pv-guest \
>>   --memory=512mb \
>>   --vcpus=2 \
>>   --lvm=vg0 \
>>   --dhcp \
>>   --pygrub \
>>   --dist=wheezy
>>
>> I have attached logs for reference.
>>  Before this step, I could not setup Linux Bridge Network for Guest
>> networking.
>> I am using my router for internet connection.Can this will be problem?
>> Can you please have a look and let me know.
>>Now, One more question to make changes for "Xl command" I need to
>> check it's source, I have checked out source from xen repository.
>> Can you share path of xl and virsh command source, I can start looking at
>> source..
>>
>> Rega
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   3 host-install(3) broken REGR. vs. 86491
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail REGR. vs. 86491
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
86491

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

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

version targeted for testing:
 xen  829e03ca0ef757350546df8546a6575ca3d0e8da
baseline version:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f

Last test of basis86491  2016-03-17 15:24:59 Z3 days
Failing since 86560  2016-03-18 10:56:34 Z2 days2 attempts
Testing same since86645  2016-03-19 12:55:56 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chunyan Liu 
  Dagaen Golomb 
  David Vrabel 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Paul Durrant 
  Shannon Zhao 
  Simon Cao 
  Tianyang Chen 
  Wei Liu 
  Wen Congyang 

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 02d6f4ce0c84f2d7e9abfcde2e092a5701ff33c4
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  103 days
Failing since 65593  2015-12-08 23:44:51 Z  102 days  112 attempts
Testing same since86648  2016-03-19 14:22:42 Z1 days1 attempts


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

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



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

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

Explanation of these reports, and of osstest in general, is at

[Xen-devel] [PATCH 10/16] xen: sched: improve credit2 bootparams' scope, placement and signedness

[Dario Faggioli]

From: Uma Sharma 

and, while we are adjusting signedness of opt_load_window_shift,
make also prv->load_window_shift unsigned, as approapriate.

Signed-off-by: Uma Sharma 
Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Juergen Gross 
Cc: Jan Beulich 
---
Patch has changed, so I'm not sticking any tag v1 received
(namely, Juergen's Reviewed-by:).
---
Changes from v1:
 * improve signedness as well, as requested during review.
---
 xen/common/sched_credit2.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 64fb028..2fd4175 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -162,7 +162,7 @@
 #define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
 
 
-int opt_migrate_resist=500;
+static unsigned int __read_mostly opt_migrate_resist = 500;
 integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
 
 /*
@@ -185,12 +185,12 @@ integer_param("sched_credit2_migrate_resist", 
opt_migrate_resist);
  *   to a load of 1.
  */
 #define LOADAVG_GRANULARITY_SHIFT (10)
-int opt_load_window_shift=18;
+static unsigned int __read_mostly opt_load_window_shift = 18;
 #define  LOADAVG_WINDOW_SHIFT_MIN 4
 integer_param("credit2_load_window_shift", opt_load_window_shift);
-int opt_underload_balance_tolerance=0;
+static int __read_mostly opt_underload_balance_tolerance = 0;
 integer_param("credit2_balance_under", opt_underload_balance_tolerance);
-int opt_overload_balance_tolerance=-3;
+static int __read_mostly opt_overload_balance_tolerance = -3;
 integer_param("credit2_balance_over", opt_overload_balance_tolerance);
 
 /*
@@ -227,7 +227,7 @@ struct csched2_private {
 cpumask_t active_queues; /* Queues which may have active cpus */
 struct csched2_runqueue_data rqd[NR_CPUS];
 
-int load_window_shift;
+unsigned int load_window_shift;
 };
 
 /*


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

[Xen-devel] [xen-4.5-testing baseline-only test] 44263: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   3 host-install(3) broken REGR. vs. 44237
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44237
 test-amd64-amd64-xl  19 guest-start/debian.repeat fail REGR. vs. 44237
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 44237

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44237
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 44237
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10   fail like 44237

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  3f802a5aba68026a3b61310dcf05a6c270272fe9
baseline version:
 xen  1fac32bd60db4fbd2a14d95c1601db55666f4fb1

Last test of basis44237  2016-03-10 11:48:17 Z   10 days
Testing same since44263  2016-03-20 09:21:58 Z0 days1 attempts


People who touched revisions under test:
  David Vrabel 
  Kevin Tian 
  Ross Lagerwall 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  fail
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 

Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Bob Liu]

On 03/16/2016 10:32 PM, David Vrabel wrote:
> On 16/03/16 13:59, Bob Liu wrote:
>>
>> But we'd like to get the VPD information(of underlying storage device) also 
>> in Linux blkfront, even blkfront is not a SCSI device.
> 
> Why does blkback/blkfront need to involved here?  This is just some
> xenstore keys that can be written by the toolstack and directly read by
> the relevant application in the guest.
> 

Exactly, let me check if they can direct read this xenstore node.

-- 
Regards,
-Bob

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

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

[Shannon Zhao]

From: Shannon Zhao 

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

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

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



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

[Xen-devel] [PATCH 1/3 v2] xenalyze: handle DOM0 operations events

[Dario Faggioli]

(i.e., domain creation and destruction) so the
trace will show properly decoded info, rather
than just a bunch of hex codes.

Signed-off-by: Dario Faggioli 
---
Changes from v2:
 * fix typo in subject;
 * add missing S-o-b.

Changes from v1:
 * new patch in the series.

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index d4a5b0c..353bed7 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -8388,6 +8388,30 @@ void hw_process(struct pcpu_info *p)
 }
 
 }
+
+#define TRC_DOM0_SUB_DOMOPS 1
+void dom0_process(struct pcpu_info *p)
+{
+struct record_info *ri = >ri;
+
+switch(ri->evt.sub)
+{
+case TRC_DOM0_SUB_DOMOPS:
+if(opt.dump_all) {
+struct {
+unsigned int domid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s %s domain d%u\n", ri->dump_header,
+   ri->event == TRC_DOM0_DOM_ADD ? "creating" : "destroying",
+   r->domid);
+}
+break;
+default:
+process_generic(>ri);
+}
+}
+
 /*  Base - */
 void dump_generic(FILE * f, struct record_info *ri)
 {
@@ -9224,6 +9248,8 @@ void process_record(struct pcpu_info *p) {
 hw_process(p);
 break;
 case TRC_DOM0OP_MAIN:
+dom0_process(p);
+break;
 default:
 process_generic(ri);
 }


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

Re: [Xen-devel] [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu

[George Dunlap]

On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross  wrote:
> Add a new pvusb backend type "qusb" which is provided by qemu. It can
> be selected either by specifying the type directly in the configuration
> or it is selected automatically by libxl in case there is no "usbback"
> driver loaded.
>
> Signed-off-by: Juergen Gross 

It would be awesome if we could get a patch like this in for 4.7.

However...

> ---
>  docs/man/xl.cfg.pod.5|  11 +++-
>  tools/libxl/libxl_device.c   |   3 +-
>  tools/libxl/libxl_dm.c   |   8 +++
>  tools/libxl/libxl_internal.h |   1 +
>  tools/libxl/libxl_pvusb.c| 102 
> +++
>  tools/libxl/libxl_types.idl  |   1 +
>  tools/libxl/libxl_types_internal.idl |   1 +
>  7 files changed, 101 insertions(+), 26 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 1dde66b..06eeb42 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -737,8 +737,15 @@ Possible Bs are:
>
>  =item 

Re: [Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Re: [PATCH v11 20/27] Support colo mode for qemu 
disk"):
> On Fri, Mar 04, 2016 at 05:52:09PM +, Ian Jackson wrote:
> > How can this be made to work with PV guests ?
> 
> QEMU can also serve PV guests (qdisk).

Yes.

> I think your question is more of - what about making this work with
> PV block backend?

Yes.

> > What if an HVM guest has PV-on-HVM drivers ?  In this case there might
> > be two relevant qemus, one for the qdisk Xen PV block backend, and one
> > for the emulated IDE.
> 
> In both cases QEMU would use the same underlaying API to actually write/read
> out the blocks. That API would then use NBD, etc to replicate writes.
> 
> Maybe a little ASCII art?
> 
>   qdisk  ide
> \/
>  \  /
>  block API
>   |
>  QCOW2
>   |
>  NBD

Except that currently libxl may launch two qemus: one to serve
emulated ide requests, and one to service PV qdisk.

Ian.

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

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

[Shannon Zhao]

From: Shannon Zhao 

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

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

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

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



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

[Xen-devel] [PATCH 12/16] xen: sched: fix per-socket runqueue creation in credit2

[Dario Faggioli]

The credit2 scheduler tries to setup runqueues in such
a way that there is one of them per each socket. However,
that does not work. The issue is described in bug #36
"credit2 only uses one runqueue instead of one runq per
socket" (http://bugs.xenproject.org/xen/bug/36), and a
solution has been attempted by an old patch series:

 http://lists.xen.org/archives/html/xen-devel/2014-08/msg02168.html

Here, we take advantage of the fact that now initialization
happens (for all schedulers) during CPU_STARTING, so we
have all the topology information available when necessary.

This is true for all the pCPUs _except_ the boot CPU. That
is not an issue, though. In fact, no runqueue exists yet
when the boot CPU is initialized, so we can just create
one and put the boot CPU in there.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Justin Weaver 
---
 xen/common/sched_credit2.c |   59 
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 4ff26c9..456b9ea 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -53,7 +53,6 @@
  *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Multiple sockets
- *  - Detect cpu layout and make runqueue map, one per L2 (make_runq_map())
  *  - Simple load balancer / runqueue assignment
  *  - Runqueue load measurement
  *  - Load-based load balancer
@@ -1972,6 +1971,48 @@ static void deactivate_runqueue(struct csched2_private 
*prv, int rqi)
 cpumask_clear_cpu(rqi, >active_queues);
 }
 
+static unsigned int
+cpu_to_runqueue(struct csched2_private *prv, unsigned int cpu)
+{
+struct csched2_runqueue_data *rqd;
+unsigned int rqi;
+
+for ( rqi = 0; rqi < nr_cpu_ids; rqi++ )
+{
+unsigned int peer_cpu;
+
+/*
+ * As soon as we come across an uninitialized runqueue, use it.
+ * In fact, either:
+ *  - we are initializing the first cpu, and we assign it to
+ *runqueue 0. This is handy, especially if we are dealing
+ *with the boot cpu (if credit2 is the default scheduler),
+ *as we would not be able to use cpu_to_socket() and similar
+ *helpers anyway (they're result of which is not reliable yet);
+ *  - we have gone through all the active runqueues, and have not
+ *found anyone whose cpus' topology matches the one we are
+ *dealing with, so ativating a new runqueue is what we want.
+ */
+if ( prv->rqd[rqi].id == -1 )
+break;
+
+rqd = prv->rqd + rqi;
+BUG_ON(cpumask_empty(>active));
+
+peer_cpu = cpumask_first(>active);
+BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID ||
+   cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
+
+if ( cpu_to_socket(cpumask_first(>active)) == cpu_to_socket(cpu) )
+break;
+}
+
+/* We really expect to be able to assign each cpu to a runqueue. */
+BUG_ON(rqi >= nr_cpu_ids);
+
+return rqi;
+}
+
 /* Returns the ID of the runqueue the cpu is assigned to. */
 static unsigned
 init_pdata(struct csched2_private *prv, unsigned int cpu)
@@ -1983,21 +2024,7 @@ init_pdata(struct csched2_private *prv, unsigned int cpu)
 ASSERT(!cpumask_test_cpu(cpu, >initialized));
 
 /* Figure out which runqueue to put it in */
-rqi = 0;
-
-/* Figure out which runqueue to put it in */
-/* NB: cpu 0 doesn't get a STARTING callback, so we hard-code it to 
runqueue 0. */
-if ( cpu == 0 )
-rqi = 0;
-else
-rqi = cpu_to_socket(cpu);
-
-if ( rqi == XEN_INVALID_SOCKET_ID )
-{
-printk("%s: cpu_to_socket(%d) returned %d!\n",
-   __func__, cpu, rqi);
-BUG();
-}
+rqi = cpu_to_runqueue(prv, cpu);
 
 rqd = prv->rqd + rqi;
 


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

[Xen-devel] [xen-4.6-testing test] 86632: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 10 guest-start fail in 86551 pass in 86632
 test-armhf-armhf-xl-rtds 11 guest-startfail in 86551 pass in 86632
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install fail pass in 86551

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 86551 like 85893
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85893
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85893
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85893
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85893
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 85893

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

version targeted for testing:
 xen  8e89d43867922abaa67e894938c655a6fa82affe
baseline version:
 xen  e0493703a96c03aaafc8d179624b89b7cf600916

Last test of basis85893  2016-03-10 09:22:52 Z   10 days
Testing same since86551  2016-03-18 07:42:41 Z2 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Vrabel 
  Jan Beulich 
  Kevin Tian 
  Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v3 07/28] xen/x86: Annotate special features

[Konrad Rzeszutek Wilk]

On Tue, Mar 15, 2016 at 03:35:03PM +, Andrew Cooper wrote:
> Some bits in a featureset are not simple a indication of new functionality,
> and require special handling.
> 
> APIC, OSXSAVE and OSPKE are fast-forwards of other pieces of state;
> IA32_APIC_BASE.EN, CR4.OSXSAVE and CR4.OSPKE.  Xen will take care of filling
> these appropriately at runtime.
> 
> FDP_EXCP_ONLY and NO_FPU_SEL are bits indicating reduced functionality in the
> x87 pipeline.  The effects of these cannot be hidden from the guest, so the
> host values will always be provided.
> 
> HTT and CMP_LEGACY indicate how to interpret other cpuid leaves.  In most
> cases, the toolstack value will be used (with the expectation that these flags
> will match the other provided topology information).  However with cpuid
> masking, the host values are presented as masking cannot influence what the
> guest sees in the dependent leaves.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] (no subject)

[Safa Hamza]

i solve the problem

On Thu, Mar 17, 2016 at 1:20 PM, Safa Hamza  wrote:

> i'm trying to run xen on omap5 and installing some guests ..  it seems it
> works and a xen boot dom0 as shown the screen shot
> but with this arago project i can't download any package ..all commands
> such as apt-get ,update ... are not found
> i tried to have another file system but its not working ..
> can you help me .. with which file system can i work
> thanks
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v10]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

The current RTDS code has several problems:
 - The scheduler, although the algorithm is event driven by
   nature, follows a time driven model (is invoked periodically!),
   making the code looks unnatural;
 - Budget replenishment logic, budget enforcement logic and scheduling
   decisions are mixed and entangled, making the code hard to understand;
 - The various queues of vcpus are scanned various times, making the
   code inefficient;

This patch separates budget replenishment and enforcement by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.

A replenishment queue has been added to keep track of all vcpus that
are runnable.

In the main scheduling function, we now return when a scheduling
decision should be made next time, such as when the budget of the
currently running vcpu runs out.

Finally, when waking up a vcpu, it tickles various vcpus appropriately,
like all other schedulers do.

Signed-off-by: Tianyang Chen 
Signed-off-by: Meng Xu 
Signed-off-by: Dagaen Golomb 
---
changes since v9:
Re-worded some of the comments
Fixed the wrong returned value from rt_schedule().

changes since v8:
Replaced spin_lock_irqsave with spin_lock_irq.
Bug fix in burn_budget() where budget == 0.
Removed unnecessary tickling in the timer handler when
vcpus have the same deadline.

changes since v7:
Coding sytle.
Added a flag to indicate that a vcpu was depleted.
Added a local list including updated vcpus in the
timer handler. It is used to decide which vcpu should
tickle.

changes since v6:
Removed unnecessary vcpu_on_q() checks for runq_insert()
Renamed replenishment queue related functions without
underscores
New replq_reinsert() function for rt_vcpu_wake()

changes since v5:
Removed unnecessary vcpu_on_replq() checks
deadline_queue_insert() returns a flag to indicate if it's
needed to re-program the timer
Removed unnecessary timer checks
Added helper functions to remove vcpus from queues
coding style

Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_remove() to all cases in vcpu_sleep()
used _deadline_queue_insert() helper function for both queues
_replq_insert() and _replq_remove() program timer internally

Changes since v3:
removed running queue.
added repl queue to keep track of repl events.
timer is now per scheduler.
timer is init on a valid cpu in a cpupool.
---
 xen/common/sched_rt.c |  431 ++---
 1 file changed, 335 insertions(+), 96 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index bfed2e2..a43b8b8 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -3,7 +3,10 @@
  * EDF scheduling is a real-time scheduling algorithm used in embedded field.
  *
  * by Sisu Xi, 2013, Washington University in Saint Louis
- * and Meng Xu, 2014, University of Pennsylvania
+ * Meng Xu, 2014-2016, University of Pennsylvania
+ *
+ * Conversion toward event driven model by Tianyang Chen
+ * and Dagaen Golomb, 2016, University of Pennsylvania
  *
  * based on the code of credit Scheduler
  */
@@ -16,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,7 +91,7 @@
 #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
 
 #define UPDATE_LIMIT_SHIFT  10
-#define MAX_SCHEDULE(MILLISECS(1))
+
 /*
  * Flags
  */
@@ -115,6 +119,16 @@
 #define RTDS_delayed_runq_add (1<<__RTDS_delayed_runq_add)
 
 /*
+ * RTDS_depleted: Does this vcp run out of budget?
+ * This flag is
+ * + set in burn_budget() if a vcpu has zero budget left;
+ * + cleared and checked in the repenishment handler,
+ *   for the vcpus that are being replenished.
+ */
+#define __RTDS_depleted 3
+#define RTDS_depleted (1<<__RTDS_depleted)
+
+/*
  * rt tracing events ("only" 512 available!). Check
  * include/public/trace.h for more details.
  */
@@ -142,6 +156,13 @@ static cpumask_var_t *_cpumask_scratch;
  */
 static unsigned int nr_rt_ops;
 
+static void repl_timer_handler(void *data);
+
+#define deadline_runq_insert(...) \
+  deadline_queue_insert(&__q_elem, ##__VA_ARGS__)
+#define deadline_replq_insert(...) \
+  deadline_queue_insert(_elem, ##__VA_ARGS__)
+
 /*
  * Systme-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
@@ -152,7 +173,9 @@ struct rt_private {
 struct list_head sdom;  /* list of availalbe domains, used for dump */
 struct list_head runq;  /* ordered list of runnable vcpus */
 struct list_head depletedq; /* unordered list of depleted vcpus */
+struct list_head replq; /* ordered list of vcpus that need 
replenishment */
 cpumask_t tickled;  /* cpus been tickled */
+struct timer *repl_timer;   /* replenishment timer */
 };
 

Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Ian Jackson]

David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document 
scsi/0x12/0x83 node"):
> On 17/03/16 11:12, Ian Jackson wrote:
> > David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document 
> > scsi/0x12/0x83 node"):
> >> On 16/03/16 13:59, Bob Liu wrote:
> >>> But we'd like to get the VPD information(of underlying storage device) 
> >>> also in Linux blkfront, even blkfront is not a SCSI device.
> >>
> >> Why does blkback/blkfront need to involved here?  This is just some
> >> xenstore keys that can be written by the toolstack and directly read by
> >> the relevant application in the guest.
> > 
> > I'm getting rather a different picture here than at first.  Previously
> > I thought you had some 3rd-party application, not under your control,
> > which expected to see this VPD data.
> 
> Bob != David?

Sorry, yes, the "you" I refer to above is Bob, not David.  I replied
to David's message because it seemd to give the best context.

Ian.

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

[Xen-devel] [PATCH v6 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn

[Shannon Zhao]

From: Shannon Zhao 

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/xlate_mmu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, 
void **virt,
void *vaddr;
int rc;
unsigned int i;
+   unsigned long nr_pages;
+   xen_pfn_t xen_pfn = 0;
 
BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+   pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t 
**gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
+   pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
+   for (i = 0; i < nr_grant_frames; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0)
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   pfns[i] = pfn_to_gfn(xen_pfn++);
+   }
 
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
+   pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
+   free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
-- 
2.0.4



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

[Xen-devel] [PATCH v6 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Hanjun Guo 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.
 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)
 *   and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
-- 
2.0.4



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

[Xen-devel] [GRUB2 PATCH v5 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,6 +755,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
   grub_fill_multiboot_mmap (tag);
@@ -776,6 +777,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_basic_meminfo *tag
= (struct multiboot_tag_basic_meminfo *) ptrorig;
@@ -886,21 +888,17 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
+if (!keep_bs)
+  {
tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
tag->size = sizeof (*tag) + efi_mmap_size;
 
-if (!keep_bs)
err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
 _desc_size, _desc_version);
-else
-  {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
-  }
+
if (err)
  return err;
+
tag->descr_size = efi_desc_size;
tag->descr_vers = efi_desc_version;
tag->size = sizeof (*tag) + efi_mmap_size;
@@ -908,6 +906,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
  / sizeof (grub_properly_aligned_t);
   }
+  }
 
   if (keep_bs)
 {
-- 
1.7.10.4


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

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

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 17, 2016 3:59 PM
> 
> >>> On 17.03.16 at 08:32,  wrote:
> >>  From: Xu, Quan
> >> Sent: Thursday, March 17, 2016 2:55 PM
> >> --- a/xen/drivers/passthrough/vtd/x86/vtd.c
> >> +++ b/xen/drivers/passthrough/vtd/x86/vtd.c
> >> @@ -140,8 +140,11 @@ void __hwdom_init vtd_set_hwdom_mapping(struct domain
> *d)
> >>
> >>  tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
> >>  for ( j = 0; j < tmp; j++ )
> >> -iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
> >> -   IOMMUF_readable|IOMMUF_writable);
> >> +if ( iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
> >> +IOMMUF_readable|IOMMUF_writable) )
> >> +printk(XENLOG_G_ERR
> >> +   "IOMMU: Map page gfn: 0x%lx(mfn: 0x%lx) failed.\n",
> >> +   pfn * tmp + j, pfn * tmp + j);
> >>
> >>  if (!(i & (0xf >> (PAGE_SHIFT - PAGE_SHIFT_4K
> >>  process_pending_softirqs();
> >
> > Hi, Quan, this patch looks good to me in general. Just double confirm one
> > thing. Above doesn't handle error from iommu_map_page, while only
> > throwing out warning. Not sure whether it has been discussed before
> > as the agreement or not.
> 
> For code paths involved in preparing the hardware domain only
> I had specifically asked to handle such in a best effort manner,
> instead of explicitly rendering a system unbootable.
> 

OK, good to know that.

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

Re: [Xen-devel] [PATCH v4 0/2] Make the pcidevs_lock a recursive one

[Dario Faggioli]

On Thu, 2016-03-17 at 01:39 +, Xu, Quan wrote:
> On March 16, 2016 6:45pm,  wrote:
> > 
> > Quan - before sending such pings, please be sure to actually check
> > the staging
> > branch. And generally Dario is right - if anything, you should have
> > pinged
> > Suravee for his missing ack, and not everyone (i.e. the list).
> > 
> Yes, you are right. I will follow it.
> Before I send out pings, I have checked it on the http://xenbits.xen.
> org/gitweb/?p=xen.git;a=summary,
> and I can't find this patch set.
> 
Right, but that is the 'master' branch.

As you probably know, patches are not committed to master, they're
committed to 'staging', and then move to 'master' when they pass
OSSTest's gate.

As you said yourself in your ping request, what you wanted to know was
whether the patches were already in the 'staging' branch, which, if you
want to use the web interface, is here:

http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/staging

(and has the patches).

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [SeaBIOS] Xen PV block device support in Seabios

[Jan Beulich]

>>> On 16.03.16 at 14:15,  wrote:
> On Wed, Mar 16, 2016 at 12:22:32PM +, Ian Campbell wrote:
>> On Wed, 2016-03-16 at 20:13 +0800, Shannon Zhao wrote:
>> > 
>> > On 2016/3/16 19:20, Ian Campbell wrote:
>> > > 
>> > > (nb, my citrix.com email is no longer valid)
>> > > On Wed, 2016-03-16 at 11:33 +0800, Shannon Zhao wrote:
>> > > > 
>> > > > > 
>> > > > > Hi,
>> > > > > 
>> > > > > I noticed there are some efforts to add Xen PV block device support 
>> > > > > in
>> > > > > Seabios in a GSoC project and there is a wiki page [1] for it. I 
>> > > > > found
>> > > > > some patches [2] to add Xenstore R/W support for Seabios. But I 
>> > > > > didn't
>> > > > > find the patches to add PV block device driver in Seabios.
>> > > > > 
>> > > > > If you know please tell me where I can find these patches. And I 
>> > > > > noticed
>> > > > > that the patches [2] and this GSoC project work didn't get applied to
>> > > > > Seabios eventually, is there any reason? Does it mean that there are
>> > > > > some difficulties to support Xen PV block device in Seabios?
>> > > This work was never finished, IIRC (and it was a long time ago so this
>> > > might be a faulty recollection) the main stumbling block was that there
>> > > is no reasonable BIOS level event which could be used to tear down the
>> > > PV interfaces in order to hand them over to the OS (unlike, say, EFI
>> > > where there is ExitBootServices).
>> > > 
>> > Ian, thanks for your reply! It looks like the problem is how and when to
>> > clear PV resources in seabios before handing over to guest. But I wonder
>> > why virtio works in seabios. Does seabios using virtio need to clear
>> > things like vrings? Or seabios doesn't clear the things and guest just
>> > covers the configuration with new values?
>> 
>> I think virtio covered this use case from day 1 by having the reset,
>> but also by not having a xenstore ring etc.
>> 
>> > > So making this work would require something like a complete set of
>> > > parallel PV infrastructure (devices, corresponding xenstore nodes,
>> > > grant table) for the use of the BIOS firmware, or perhaps a (tricky
>> > > to
>> > > retrofit in a backwards compatible manner) PV facility for the
>> > > guest to
>> > > reset everything before starting to use them.
>> > > 
>> > Like guest front-end driver checks if the backend state is
>> > XenbusStateInitWait, if not, tell the backend to reset to
>> > XenbusStateInitWait state?
>> 
>> Before it can do this the guest needs to recover the xenbus ring (which
>> was used by SeaBIOS) into a usable state -- so you need to be thinking
>> at least one layer further down before you can start to think about
>> individual devices, and don't forget the grant table (which may have in
>> use entries from the BIOS) and event channels (which the BIOS may have
>> setup).
>> 
>> I'm afraid I don't have any concrete answer for what exactly needs to
>> be done to make this work, but I do know that it is a (IMHO very) non-
>> trivial amount of investigation, prototyping and coding.
> 
> But it does work with OVMF. That is it implements the full PV driver
> for block. So it surely is possible.

And grub2, iirc.

Jan


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

Re: [Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

[Konrad Rzeszutek Wilk]

> I'll do that. I'm using to many BUG_ON in this code.
> 
> > > +{
> > > +BUG_ON(!modlist[i].paddr || modlist[i].paddr > UINT_MAX ||
> > > +   modlist[i].size > UINT_MAX);
> > 
> > To be fair all of those values are in spec..Perhaps you should mention
> > that the libxc code would never put those there and neermind the spec?
> 
> Yes, there is just this mention in the spec: "However Xen will always try
> to place all modules below the 4GiB boundary."
> 
> But it actualy would be a bug if the blob would be abrove 4GiB, since
> hvmloader can not read that far, right? I can add a comment.

Well no. It says that the hypervisor will 'try', not that it 'MUST'.

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

Re: [Xen-devel] [PATCH v3 1/4] x86: move cached CR4 value to struct cpu_info

[Andrew Cooper]

On 17/03/16 08:02, Jan Beulich wrote:
> This not only eases using the cached value in assembly code, but also
> improves the generated code resulting from such reads in C.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: fix the TLB flush hypercall

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 March 2016 13:32
> To: Paul Durrant
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH] x86/hvm/viridian: fix the TLB flush hypercall
> 
> >>> On 16.03.16 at 14:00,  wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -2576,12 +2576,9 @@ int hvm_vcpu_initialise(struct vcpu *v)
> >  if ( rc != 0 )
> >  goto fail6;
> >
> > -if ( is_viridian_domain(d) )
> > -{
> > -rc = viridian_vcpu_init(v);
> > -if ( rc != 0 )
> > -goto fail7;
> > -}
> > +rc = viridian_vcpu_init(v);
> > +if ( rc != 0 )
> > +goto fail7;
> 
> Well, it's only a CPU mask (i.e. right now at most 512 bytes), but
> anyway - why can't this be done conditionally here as well as
> when HVM_PARAM_VIRIDIAN gets set to a non-zero value?

That would also work but as you say, it is only 512 bytes.

> I
> know you are of the opinion that the Viridian flag could (should)
> always be set for HVM guests, but you also know that I disagree
> (and Don't VMware patches, should they ever go in, would
> support me, since iirc VMware and Viridian are exclusive of one
> another).
> 
> That said, I now wonder anyway why this is a per-vCPU mask
> instead of a per-pCPU one: There's no need for every vCPU in
> the system to have its own afaics.
> 

Given that it only needs to be valid during the hypercall then yes, a per-pCPU 
would be sufficient.

> > @@ -658,6 +658,8 @@ int viridian_hypercall(struct cpu_user_regs *regs)
> >  if ( !cpumask_empty(pcpu_mask) )
> >  flush_tlb_mask(pcpu_mask);
> >
> > +output.rep_complete = input.rep_count;
> 
> So why would this not be necessary for the other hypercalls?

As far as I can tell from my spec. (which Microsoft have helpfully removed from 
MSDN now) HvFlushVirtualAddressList is the only hypercall of the 3 we now 
support that is a rep op.

> And what does a repeat count mean here in the first place?
> Surely there isn't any expectation to do more then one flush?

HvFlushVirtualAddressList specifies a list of individual VA ranges to flush. We 
can't deal with that level of granularity so yes, we only do a single flush.

  Paul

> 
> Jan


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

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

[Rafael J. Wysocki]

On Thu, Mar 17, 2016 at 10:57 AM, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> Signed-off-by: Shannon Zhao 
> ---
> CC: "Rafael J. Wysocki"  (supporter:ACPI)
> CC: Len Brown  (supporter:ACPI)
> CC: linux-a...@vger.kernel.org (open list:ACPI)
> ---
>  drivers/acpi/scan.c | 63 
> +
>  1 file changed, 63 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..55ceb69 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>  DEFINE_MUTEX(acpi_device_lock);
>  LIST_HEAD(acpi_wakeup_device_list);
>  static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
>  struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device 
> **child,
> return 0;
>  }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> +   void *context)
> +{
> +   struct resource *res = context;
> +
> +   if (acpi_dev_resource_memory(ares, res))
> +   return AE_CTRL_TERMINATE;
> +
> +   return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> +   acpi_status status;
> +   struct resource res;
> +
> +   /* Check if it should ignore the UART device */
> +   if (spcr_uart_addr != 0) {
> +   if (!acpi_has_method(handle, METHOD_NAME__CRS))
> +   return false;
> +
> +   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +acpi_get_resource_memory, );
> +   if (ACPI_FAILURE(status))
> +   return false;
> +
> +   if (res.start == spcr_uart_addr) {
> +   printk(KERN_INFO PREFIX "The UART device in SPCR 
> table will be hidden\n");
> +   return true;
> +   }
> +   }
> +
> +   return false;
> +}
> +
>  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
>  {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
> int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> +   if (acpi_device_should_be_hidden(handle))
> +   return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1919,6 +1958,8 @@ static int acpi_bus_scan_fixed(void)
>  int __init acpi_scan_init(void)
>  {
> int result;
> +   acpi_status status;
> +   struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1975,28 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(_device_handler);
>
> +   /*
> +* If there is STAO table, check whether it needs to ignore the UART
> +* device in SPCR table.
> +*/
> +   status = acpi_get_table(ACPI_SIG_STAO, 0,
> +   (struct acpi_table_header **)_ptr);
> +   if (ACPI_SUCCESS(status)) {
> +   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> +   printk(KERN_INFO PREFIX "STAO Name List not yet 
> supported.");
> +
> +   if (stao_ptr->ignore_uart) {
> +   struct acpi_table_spcr *spcr_ptr;
> +
> +   status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +   (struct acpi_table_header 
> **)_ptr);
> +   if (ACPI_SUCCESS(status))
> +   spcr_uart_addr = 
> spcr_ptr->serial_port.address;
> +   else
> +   printk(KERN_WARNING PREFIX "STAO table 
> present, but SPCR is missing\n");
> +   }
> +   }

I'd put the above part into a separate function and call that from
here.  You'd be able to reduce the indentation level then slightly
without using gotos.

Apart from this minor point the patch is fine by me.

> +
> mutex_lock(_scan_lock);
> /*
>  * Enumerate devices in the ACPI namespace.
> --

Thanks,
Rafael

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  3f802a5aba68026a3b61310dcf05a6c270272fe9
baseline version:
 xen  1fac32bd60db4fbd2a14d95c1601db55666f4fb1

Last test of basis85821  2016-03-09 16:14:24 Z   10 days
Testing same since86552  2016-03-18 07:42:01 Z2 days2 attempts


People who touched revisions under test:
  David Vrabel 
  Kevin Tian 
  Ross Lagerwall 

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang]

Hi Jan and Konrad,

On 03/04/16 15:30, Haozhong Zhang wrote:
> Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
> or files on NVDIMM. We can move that work to toolstack and pass SPA
> ranges got by toolstack to qemu. In this way, no privileged operations
> (mmap/mlock/...) are needed in QEMU and non-root QEMU should be able to
> work even with vNVDIMM hotplug in future.
> 

As I'm going to let toolstack to get NVDIMM SPA ranges. This can be
done via dom0 kernel interface and xen hypercalls, and can be
implemented in different ways. I'm wondering which of the following
ones is preferred by xen.

1. Given
* a file descriptor of either a NVDIMM device or a file on NVDIMM, and
* domain id and guest MFN where vNVDIMM is going to be.
   xen toolstack (1) gets it SPA ranges via dom0 kernel interface
   (e.g. sysfs and ioctl FIEMAP), and (2) calls a hypercall to map
   above SPA ranges to the given guest MFN of the given domain.

2. Or, given the same inputs, we may combine above two steps into a new
   dom0 system call that (1) gets the SPA ranges, (2) calls xen
   hypercall to map SPA ranges, and, one step further, (3) returns SPA
   ranges to userspace (because QEMU needs these addresses to build ACPI).

The first way does not need to modify dom0 linux kernel, while the
second requires a new system call. I'm not sure whether xen toolstack
as a userspace program is considered to be safe to pass the host physical
address to hypervisor. If not, maybe the second one is better?

Thanks,
Haozhong

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

Re: [Xen-devel] [PATCH 4/6] xentrace: ARM platform DOMID_XEN mapping support

[Julien Grall]

Hello Benjamin,

Thank you for the patch.

On 16/03/16 20:51, Benjamin Sanda wrote:

From: bensanda 

Modified xenmem_add_to_physmap_one() to provide support for xentrace on the ARM 
platform. Checks for DOMID_XEN added via new function, get_pg_owner, ported 
from x86 code base. This provides correct calls to rcu_lock_domain() when 
DOMID_XEN is requested. DOMID_XEN checks also adde to skip page to MFN 
translation (xentrace sends a MFN dirrectly and so does not need to be 
translated).


A line in the commit message should not be longer than 72 characters.



Signed-off-by: Benjamin Sanda 
---
  xen/arch/arm/mm.c | 56 +--
  1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 81f9e2e..b1d834f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -41,6 +41,7 @@
  #include 

  struct domain *dom_xen, *dom_io, *dom_cow;
+static struct domain *get_pg_owner(domid_t domid);


I would rather avoid to forward declare a function if there is no strict 
dependency on other functions. Instead, I would add the function before 
the caller.




  /* Static start-of-day pagetables that we use before the allocators
   * are up. These are used by all CPUs during bringup before switching
@@ -1099,7 +1100,8 @@ int xenmem_add_to_physmap_one(
  {
  struct domain *od;
  p2m_type_t p2mt;
-od = rcu_lock_domain_by_any_id(foreign_domid);
+od = get_pg_owner(foreign_domid);
+
  if ( od == NULL )
  return -ESRCH;

@@ -1132,7 +1134,17 @@ int xenmem_add_to_physmap_one(
  return -EINVAL;
  }

-mfn = page_to_mfn(page);
+/* If DOMID_XEN then no page to MFN translation is
+needed as we already have the MFN directly */
+if(DOMID_XEN !=od->domain_id)
+{
+mfn = page_to_mfn(page);
+}
+else
+{
+mfn = idx;
+}
+


Please avoid to spread the DOMID_ID specific case everywhere. The cost 
to calculate the MFN of a page is very limited.



  t = p2m_map_foreign;

  rcu_unlock_domain(od);
@@ -1312,6 +1324,46 @@ void clear_and_clean_page(struct page_info *page)
  unmap_domain_page(p);
  }

+/* Ported from x86 architecture: checks for special domain requests for
+DOMID_XEN or DOMID_IO which must be handled differently then guest domain
+requests */
+static struct domain *get_pg_owner(domid_t domid)


This function is very similar to the x86 one. I think it would benefit 
to implement get_pg_owner in the common code and add arch specific 
helper when it's necessary.


Also, please introduce the helper put_pg_owner to stay consistent.


+{
+struct domain *pg_owner = NULL, *curr = current->domain;
+
+if ( likely(domid == DOMID_SELF) )
+{
+pg_owner = rcu_lock_current_domain();
+goto out;
+}
+
+if ( unlikely(domid == curr->domain_id) )
+{
+goto out;
+}
+
+/* check for special domain cases of DOMID_IO or DOMID_XEN which
+must use rcu_lock_domain() and dom_xen/dom_io as the domid_t */
+switch ( domid )
+{
+case DOMID_IO:
+pg_owner = rcu_lock_domain(dom_io);
+break;
+case DOMID_XEN:
+pg_owner = rcu_lock_domain(dom_xen);
+break;
+default:
+if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
+{
+break;
+}
+break;
+}
+
+ out:
+return pg_owner;
+}
+
  /*
   * Local variables:
   * mode: C



Regards,

--
Julien Grall

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

[Xen-devel] [PATCH v3 0/2] x86/hvm/viridian: APIC assist

[Paul Durrant]

This patch series enables use of the 'APIC assist' enlightenment in Xen.

See section 13.3.4.1 of the Microsoft Hypervisor Top Level Function
Specification v4.0b at:

https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/tlfs

for more information.

Patch #1 modifies the viridian code to keep the guest APIC assist pages
mapped for the lifetime of the domain (and incorporates a straightforward
data-structure change).

Patch #2 adds a new viridian code and a configuration option to the
toolstack that, when enabled, allows the local APIC emulation to make use
the APIC assist pages.


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

Re: [Xen-devel] [PATCH v4 1/2] x86/hvm/viridian: keep APIC assist page mapped...

[Jan Beulich]

>>> On 17.03.16 at 09:37,  wrote:
> +static void teardown_apic_assist(struct vcpu *v)
> +{
> +struct page_info *page = v->arch.hvm_vcpu.viridian.apic_assist.page;
> +void *va = v->arch.hvm_vcpu.viridian.apic_assist.va;
>  
> +if ( !va )
> +return;
> +
> +v->arch.hvm_vcpu.viridian.apic_assist.va = NULL;
> +v->arch.hvm_vcpu.viridian.apic_assist.page = NULL;
> +
> +unmap_domain_page_global(va);
>  put_page_and_type(page);
>  }

The apic_assist.page field is needed only here, and is redundant
with the va being stored (from which it can be derived via
domain_page_map_to_mfn()). Please let's avoid needlessly
growing struct vcpu.

Jan


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

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

[Dario Faggioli]

On Fri, 2016-03-18 at 03:29 -0600, Jan Beulich wrote:
> > 
> Not sure what exactly you're asking for: As said, we first need to
> settle on an abstract model. Do we want IOMMU mapping failures
> to be fatal to the domain (perhaps with the exception of the
> hardware one)? I think we do, and for the hardware domain we'd
> do things on a best effort basis (always erring on the side of
> unmapping). Which would probably mean crashing the domain
> could be centralized in iommu_{,un}map_page(). How much roll
> back would then still be needed in callers of these functions for
> the hardware domain's sake would need to be seen.
> 
> So before you start coing, give others (namely but not limited to
> VT-d, AMD IOMMU, other x86, and x86/mm maintainers) a chance
> to voice differing opinions.
>
I'm nothing of the above but, FWIW, the behavior Jan described
(crashing the domain for all domains but the hardware domain) was
indeed the intended plan for this series, as far as I understood from
talking to people and looking at previous email conversations and
submissions.

And it looks to me like it is a sane plan.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 27/34] libxl: info: Display build_id of the hypervisor using XEN_VERSION_OP_build_id

[Wei Liu]

On Tue, Mar 15, 2016 at 01:56:49PM -0400, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] xen/events: Mask a moving irq

[David Vrabel]

On 17/03/16 16:53, Boris Ostrovsky wrote:
> On 03/17/2016 12:03 PM, David Vrabel wrote:
>> On 17/03/16 12:45, Boris Ostrovsky wrote:
>>> Moving an unmasked irq may result in irq handler being invoked on both
>>> source and target CPUs.
>>>
>>> With 2-level this can happen as follows:
>>>
>>> On source CPU:
>>>  evtchn_2l_handle_events() ->
>>>  generic_handle_irq() ->
>>>  handle_edge_irq() ->
>>> eoi_pirq():
>>> irq_move_irq(data);
>>>
>>> /* WE ARE HERE */
>>>
>>> if (VALID_EVTCHN(evtchn))
>>> clear_evtchn(evtchn);
>>>
>>> If at this moment target processor is handling an unrelated event in
>>> evtchn_2l_handle_events()'s loop it may pick up our event since target's
>>> cpu_evtchn_mask claims that this event belongs to it *and* the event is
>>> unmasked and still pending. At the same time, source CPU will continue
>>> executing its own handle_edge_irq().
>>>
>>> With FIFO interrupt the scenario is similar: irq_move_irq() may result
>>> in a EVTCHNOP_unmask hypercall which, in turn, may make the event
>>> pending on the target CPU.
>>>
>>> We can avoid this situation by moving and clearing the event while
>>> keeping event masked.
>> Can you do:
>>
>> if (unlikely(irqd_is_setaffinity_pending(data))) {
>> masked = test_and_set_mask()
>>
>> clear_evtchn()
>> irq_move_masked_irq()
> 
> I did think about this but then I wasn't sure whether this might open
> some other window for things to sneak in. It shouldn't but these things
> are rather subtle so I'd rather leave the order of how operations are
> done unchanged.

This is the order your patch has though.  I'm confused.

> But I should indeed use irq_move_masked_irq() instead of irq_move_irq().

David

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

Re: [Xen-devel] [PATCH] xen/events: Mask a moving irq

[Boris Ostrovsky]

On 03/17/2016 12:03 PM, David Vrabel wrote:

On 17/03/16 12:45, Boris Ostrovsky wrote:

Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.

With 2-level this can happen as follows:

On source CPU:
 evtchn_2l_handle_events() ->
 generic_handle_irq() ->
 handle_edge_irq() ->
eoi_pirq():
irq_move_irq(data);

/* WE ARE HERE */

if (VALID_EVTCHN(evtchn))
clear_evtchn(evtchn);

If at this moment target processor is handling an unrelated event in
evtchn_2l_handle_events()'s loop it may pick up our event since target's
cpu_evtchn_mask claims that this event belongs to it *and* the event is
unmasked and still pending. At the same time, source CPU will continue
executing its own handle_edge_irq().

With FIFO interrupt the scenario is similar: irq_move_irq() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.

We can avoid this situation by moving and clearing the event while
keeping event masked.

Can you do:

if (unlikely(irqd_is_setaffinity_pending(data))) {
masked = test_and_set_mask()

clear_evtchn()
irq_move_masked_irq()


I did think about this but then I wasn't sure whether this might open 
some other window for things to sneak in. It shouldn't but these things 
are rather subtle so I'd rather leave the order of how operations are 
done unchanged.


But I should indeed use irq_move_masked_irq() instead of irq_move_irq().

-boris



unmask(masked);
} else
clear_evtchn()





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

[Xen-devel] [PATCH v2] docs: update FLASK cmd line instructions

[Doug Goldstein]

The command line instructions for FLASK include a note on how to compile
Xen with FLASK but the note was out of date after the change to Kconfig.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
CC: Konrad Rzeszutek Wilk 
CC: Daniel De Graaf 

change since v1:
- add menuconfig and config entries as suggested by Konrad
- caught another place mentioning XSM_ENABLE
---
 docs/misc/xen-command-line.markdown | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index ca77e3b..e4e4437 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -665,8 +665,10 @@ to use the default.
 > Default: `permissive`
 
 Specify how the FLASK security server should be configured.  This option is 
only
-available if the hypervisor was compiled with XSM support (which can be enabled
-by setting XSM\_ENABLE = y in .config).
+available if the hypervisor was compiled with FLASK support.  This can be
+enabled by running either:
+- make -C xen config and enabling XSM and FLASK.
+- make -C xen menuconfig and enabling 'FLux Advanced Security Kernel support' 
and 'Xen Security Modules support'
 
 * `permissive`: This is intended for development and is not suitable for use
   with untrusted guests.  If a policy is provided by the bootloader, it will be
@@ -805,7 +807,7 @@ Paging (HAP).
 Enable late hardware domain creation using the specified domain ID.  This is
 intended to be used when domain 0 is a stub domain which builds a disaggregated
 system including a hardware domain with the specified domain ID.  This option 
is
-supported only when compiled with XSM\_ENABLE=y on x86.
+supported only when compiled with XSM on x86.
 
 ### hest\_disable
 > ` = `
-- 
2.7.3


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

[Xen-devel] [PATCH v2 2/2] xsm: move FLASK_AVC_STATS to Kconfig

[Doug Goldstein]

Have Kconfig set CONFIG_FLASK_AVC_STATS and prefix all uses with CONFIG_
to use the Kconfig variable.

Signed-off-by: Doug Goldstein 
Acked-by: Daniel De Graaf 
---
CC: Daniel De Graaf 
---
 xen/common/Kconfig  | 6 ++
 xen/include/xen/config.h| 5 -
 xen/xsm/flask/avc.c | 4 ++--
 xen/xsm/flask/flask_op.c| 4 ++--
 xen/xsm/flask/include/avc.h | 2 +-
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3522ecb..ad9f7bf 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -23,6 +23,12 @@ config FLASK
 
  If unsure, say N.
 
+config FLASK_AVC_STATS
+   def_bool y
+   depends on FLASK
+   ---help---
+ Maintain statistics on the access vector cache
+
 # Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
bool
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 3f8c53d..ef6e5ee 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -78,11 +78,6 @@
 #define __STR(...) #__VA_ARGS__
 #define STR(...) __STR(__VA_ARGS__)
 
-#ifdef CONFIG_FLASK
-/* Maintain statistics on the access vector cache */
-#define FLASK_AVC_STATS 1
-#endif
-
 /* allow existing code to work with Kconfig variable */
 #define NR_CPUS CONFIG_NR_CPUS
 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 31bc702..7764379 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -56,7 +56,7 @@ const struct selinux_class_perm selinux_class_perm = {
 #define AVC_DEF_CACHE_THRESHOLD512
 #define AVC_CACHE_RECLAIM16
 
-#ifdef FLASK_AVC_STATS
+#ifdef CONFIG_FLASK_AVC_STATS
 #define avc_cache_stats_incr(field) \
 do {\
 __get_cpu_var(avc_cache_stats).field++;\
@@ -101,7 +101,7 @@ struct avc_callback_node {
 /* Exported via Flask hypercall */
 unsigned int avc_cache_threshold = AVC_DEF_CACHE_THRESHOLD;
 
-#ifdef FLASK_AVC_STATS
+#ifdef CONFIG_FLASK_AVC_STATS
 DEFINE_PER_CPU(struct avc_cache_stats, avc_cache_stats);
 #endif
 
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index f4f5dd1..3c9c99e 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -469,7 +469,7 @@ static int flask_security_make_bools(void)
 return ret;
 }
 
-#ifdef FLASK_AVC_STATS
+#ifdef CONFIG_FLASK_AVC_STATS
 
 static int flask_security_avc_cachestats(struct xen_flask_cache_stats *arg)
 {
@@ -761,7 +761,7 @@ ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) 
u_flask_op)
 rv = avc_get_hash_stats(_stats);
 break;
 
-#ifdef FLASK_AVC_STATS
+#ifdef CONFIG_FLASK_AVC_STATS
 case FLASK_AVC_CACHESTATS:
 rv = flask_security_avc_cachestats(_stats);
 break;
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 4283562..729856e 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -108,7 +108,7 @@ struct xen_flask_hash_stats;
 int avc_get_hash_stats(struct xen_flask_hash_stats *arg);
 extern unsigned int avc_cache_threshold;
 
-#ifdef FLASK_AVC_STATS
+#ifdef CONFIG_FLASK_AVC_STATS
 DECLARE_PER_CPU(struct avc_cache_stats, avc_cache_stats);
 #endif
 
-- 
2.7.3


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

Re: [Xen-devel] [PATCH v4 1/2] x86/hvm/viridian: keep APIC assist page mapped...

[Andrew Cooper]

On 17/03/16 08:37, Paul Durrant wrote:
> ... for the lifetime of the domain.
>
> If Xen is to make use of the APIC assist enlightenment then a persistent
> mapping needs to be kept, rather than the temporary one which is currently
> used only to initialize the page content.
>
> This patch also adds a comment block at the top of the source with
> information on the latest version of the spec. from Microsoft and the
> current URL where it may be found.
>
> Signed-off-by: Paul Durrant 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 

By the looks of it, this patch textually depends on your Viridian TLB fixes?

Reviewed-by: Andrew Cooper 

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

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

[osstest service owner]

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

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu4829e0378dfb91d55af9dfd741bd09e8f2c4f91a
baseline version:
 qemuud1f8764099022bc1173f2413331b26d4ff609a0c

Last test of basis86454  2016-03-17 06:01:30 Z3 days
Failing since 86547  2016-03-18 07:12:41 Z2 days2 attempts
Testing same since86628  2016-03-19 04:51:17 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Daniel P. Berrange 
  David Gibson 
  Eduardo Habkost 
  Eric Blake 
  Jeff Cody 
  Kevin Wolf 
  Marcel Apfelbaum 
  Markus Armbruster 
  Matthew Fortune 

Re: [Xen-devel] [PATCH v11 19/27] COLO: introduce new API to prepare/start/do/get_error/stop replication

[Changlong Xie]

On 03/05/2016 01:26 AM, Ian Jackson wrote:

Changlong Xie writes ("[PATCH v11 19/27] COLO: introduce new API to 
prepare/start/do/get_error/stop replication"):

From: Wen Congyang 

We will use qemu block replication, and qemu provides some qmp commands
to prepare replication, start replication, get replication error, and
stop replication. Introduce new API to execute these qmp commands.


How will this work if in future we want to support HVM (or
hvm-lite-ng) guests ?


Sorry for bad english, what does "hvm-lite-ng" mean? I can't figure out 
this abbr.





diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5160939..8cb9f19 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1771,6 +1771,26 @@ _hidden int
libxl__qmp_set_global_dirty_log(libxl__gc ...
+_hidden int libxl__qmp_nbd_server_add(libxl__gc *gc, int domid, const char 
*disk);


It's a tiny nit, but can I grumble about the long lines here ?  Less
than ~70-75 characters is best.

Thanks,
Ian.


.





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

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

[Shannon Zhao]

From: Shannon Zhao 

Map all other tables to Dom0 using 1:1 mappings.

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

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



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

Re: [Xen-devel] List of projects for 4.7

[Jan Beulich]

>>> On 18.03.16 at 13:07,  wrote:
> Important bug fixes:
> 1. Intel VT-d flush issue
> 2. SMEP / SMAP fix
> 3. QEMU hotplug script fix

4. XSAVES

Jan


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

[Xen-devel] [PATCH 6/7] oxenstored: replay transaction upon conflict

[Jonathan Davies]

The existing transaction merge algorithm keeps track of the least upper bound
(longest common prefix) of all the nodes which have been read and written, and
will re-combine two stores which have disjoint upper bounds. This works well for
small transactions but causes unnecessary conflicts for ones that span a large
subtree, such as the following ones used by the xapi toolstack:

 * VM start: creates /vm/... /vss/... /local/domain/...
   The least upper bound of this transaction is / and so all
   these transactions conflict with everything.

 * Device hotplug: creates /local/domain/0/... /local/domain/n/...
   The least upper bound of this transaction is /local/domain so
   all these transactions conflict with each other.

If the existing merge algorithm cannot merge and commit, we attempt
a /replay/ of the failed transaction against the new store.

When we replay the requests we check whether the response sent to the client is
the same as during the first attempt at the transaction. If the responses are
all the same then the transaction replay can be committed. If any differ then
the transaction replay must be aborted and the client must retry.

This algorithm uses the intuition that the transactions made by the toolstack
are designed to be for separate domains, and should fundamentally not conflict
in the sense that they don't read or write any shared keys. By replaying the
transaction on the server side we do what the client would have to do anyway,
only we can do it quickly without allowing any other requests to interfere.

Performing 300 parallel simulated VM start and shutdowns without this code:

300 parallel starts and shutdowns: 268.92

Performing 300 parallel simulated VM start and shutdowns with this code:

300 parallel starts and shutdowns: 3.80

Signed-off-by: Dave Scott 
Signed-off-by: Jonathan Davies 
Reviewed-by: Andrew Cooper 
Reviewed-by: Jon Ludlam 
Reviewed-by: Euan Harris 
---
 tools/ocaml/xenstored/connection.ml |5 -
 tools/ocaml/xenstored/process.ml|   33 +
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/tools/ocaml/xenstored/connection.ml 
b/tools/ocaml/xenstored/connection.ml
index 0a2c481..b18336f 100644
--- a/tools/ocaml/xenstored/connection.ml
+++ b/tools/ocaml/xenstored/connection.ml
@@ -233,7 +233,10 @@ let end_transaction con tid commit =
let trans = Hashtbl.find con.transactions tid in
Hashtbl.remove con.transactions tid;
Logging.end_transaction ~tid ~con:(get_domstr con);
-   if commit then Transaction.commit ~con:(get_domstr con) trans else true
+   match commit with
+   | None -> true
+   | Some transaction_replay_f ->
+   Transaction.commit ~con:(get_domstr con) trans || 
transaction_replay_f con trans
 
 let get_transaction con tid =
Hashtbl.find con.transactions tid
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index 39ae71b..6d1f551 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -281,6 +281,38 @@ let input_handle_error ~cons ~doms ~fct ~con ~t ~req =
| (Failure "int_of_string")-> reply_error "EINVAL"
| Define.Unknown_operation -> reply_error "ENOSYS"
 
+(* Replay a stored transaction against a fresh store, check the responses are
+   all equivalent: if so, commit the transaction. Otherwise send the abort to
+   the client. *)
+let transaction_replay c t doms cons =
+   match t.Transaction.ty with
+   | Transaction.No ->
+   error "attempted to replay a non-full transaction";
+   false
+   | Transaction.Full(id, oldroot, cstore) ->
+   let tid = Connection.start_transaction c cstore in
+   let new_t = Transaction.make tid cstore in
+   let con = sprintf "r(%d):%s" id (Connection.get_domstr c) in
+   let perform_exn (request, response) =
+   let fct = function_of_type_simple_op request.Packet.ty 
in
+   let response' = input_handle_error ~cons ~doms ~fct 
~con:c ~t:new_t ~req:request in
+   if not(Packet.response_equal response response') then 
raise Transaction_again in
+   finally
+   (fun () ->
+   try
+   Logging.start_transaction ~con ~tid;
+   List.iter perform_exn 
(Transaction.get_operations t);
+   Logging.end_transaction ~con ~tid;
+
+   Transaction.commit ~con new_t
+   with e ->
+   info "transaction_replay %d caught: %s" tid 
(Printexc.to_string e);
+   false
+   )
+   (fun () ->
+   

[Xen-devel] [PATCH v2 3/6] x86/mtrr: Fix Xorg crashes in Qemu sessions

[Toshi Kani]

A Xorg failure on qemu32 was reported as a regression caused
by 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is
disabled")'. [1]  This patch fixes the regression.

Negative effects of this regression were two failures in Xorg
on qemu32 env, which were triggered by the fact that its virtual
CPU does not support MTRR. [2]

 #1. copy_process() failed in the check in reserve_pfn_range()

copy_process
 copy_mm
  dup_mm
   dup_mmap
copy_page_range
 track_pfn_copy
  reserve_pfn_range

 #2. error path in copy_process() then hit WARN_ON_ONCE in
 untrack_pfn().

 x86/PAT: Xorg:509 map pfn expected mapping type uncached-
 minus for [mem 0xfd00-0xfdff], got write-combining
  Call Trace:
 dump_stack+0x58/0x79
 warn_slowpath_common+0x8b/0xc0
 ? untrack_pfn+0x9f/0xb0
 ? untrack_pfn+0x9f/0xb0
 warn_slowpath_null+0x22/0x30
 untrack_pfn+0x9f/0xb0
 ? __kunmap_atomic+0x54/0x110
 unmap_single_vma+0x56f/0x580
 ? pagevec_move_tail_fn+0xa0/0xa0
 unmap_vmas+0x43/0x60
 exit_mmap+0x5f/0xf0
 mmput+0x2d/0xa0
 copy_process.part.47+0x1229/0x1430
 _do_fork+0xb4/0x3b0
 SyS_clone+0x2c/0x30
 do_syscall_32_irqs_on+0x54/0xb0
 entry_INT80_32+0x2a/0x2a

These negative effects are caused by two separate bugs, but they
can be dealt in lower priority.  Fixing the pat_init() issue below
avoids Xorg to hit these cases.

When the CPU does not support MTRR, MTRR does not call pat_init(),
which leaves PAT enabled without initializing PAT.  This pat_init()
issue is a long-standing issue, but manifested as issue #1 (and then
hit issue #2) with the commit because the memtype now tracks cache
attribute with 'page_cache_mode'.  A WC map request is tracked as WC
in memtype, but sets a PTE as UC (pgprot) per __cachemode2pte_tbl[].
This caused the error in reserve_pfn_range() when it was called from
track_pfn_copy(), which obtained pgprot from a PTE.  It converts
pgprot to page_cache_mode, which does not necessarily result in
the original page_cache_mode since __cachemode2pte_tbl[] redirects
multiple types to UC.  This is a separate issue in reserve_pfn_range().

This pat_init() issue existed before the commit, but we used pgprot
in memtype.  Hence, we did not have issue #1 before.  But WC request
resulted in WT in effect because WC pgrot is actually WT when PAT
is not initialized.  This is not how it was designed to work.  When
PAT is set to disable properly, WC is converted to UC.  The use of
WT can result in a system crash if the target range does not support
WT.  Fortunately, nobody ran into such issue before.

To fix this pat_init() issue, PAT code has been enhanced to provide
pat_disable() interface, which disables the OS to initialize PAT MSR,
and sets PAT table to the BIOS handoff state.  This patch changes
MTRR code to call pat_disable() when MTRR is disabled as PAT cannot
be initialized in this case.  This sets PAT to disable properly, and
makes PAT code to bypass the memtype check.  This avoids issue #1
(which can be dealt in lower priority).

[1]: https://lkml.org/lkml/2016/3/3/828
[2]: https://lkml.org/lkml/2016/3/4/775
Signed-off-by: Toshi Kani 
Cc: Borislav Petkov 
Cc: Luis R. Rodriguez 
Cc: Juergen Gross 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
---
 arch/x86/include/asm/mtrr.h |6 +-
 arch/x86/kernel/cpu/mtrr/main.c |   10 +-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index b94f6f6..634c593 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -24,6 +24,7 @@
 #define _ASM_X86_MTRR_H
 
 #include 
+#include 
 
 
 /*
@@ -83,9 +84,12 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
end_pfn)
 static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
 {
 }
+static inline void mtrr_bp_init(void)
+{
+   pat_disable("Skip PAT initialization");
+}
 
 #define mtrr_ap_init() do {} while (0)
-#define mtrr_bp_init() do {} while (0)
 #define set_mtrr_aps_delayed_init() do {} while (0)
 #define mtrr_aps_init() do {} while (0)
 #define mtrr_bp_restore() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 10f8d47..2d7d8d7 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -759,8 +759,16 @@ void __init mtrr_bp_init(void)
}
}
 
-   if (!mtrr_enabled())
+   if (!mtrr_enabled()) {
pr_info("MTRR: Disabled\n");
+
+   /*
+* PAT initialization relies on MTRR's rendezvous handler.
+* Skip PAT init until the handler can initialize both
+* features independently.
+*/
+   pat_disable("Skip PAT initialization");
+   }
 }
 
 void 

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

[Shannon Zhao]

From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/gic-v2.c | 34 ++
 xen/arch/arm/gic-v3.c | 47 +++
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  3 +++
 4 files changed, 89 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 0fcb894..02db5f2 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -685,6 +685,35 @@ static void __init gicv2_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static u32 gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+u32 i, size, table_len = 0;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+panic("Can't get GICC entry");
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+
+size = sizeof(struct acpi_madt_generic_interrupt);
+/* Add Generic Interrupt */
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -776,6 +805,10 @@ static void __init gicv2_acpi_init(void)
 }
 #else
 static void __init gicv2_acpi_init(void) { }
+static u32 gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+return 0;
+}
 #endif
 
 static int __init gicv2_init(void)
@@ -868,6 +901,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_vmcr_priority  = gicv2_read_vmcr_priority,
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
+.make_hwdom_madt = gicv2_make_hwdom_madt,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f83fd88..d9fce4b 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1236,6 +1236,48 @@ static void __init gicv3_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static u32 gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+struct acpi_madt_generic_redistributor *gicr;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+u32 i, table_len = 0, size;
+
+/* Add Generic Interrupt */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+panic("Can't get GICC entry");
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+
+size = sizeof(struct acpi_madt_generic_interrupt);
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+table_len += size;
+}
+
+/* Add Generic Redistributor */
+size = sizeof(struct acpi_madt_generic_redistributor);
+for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+{
+gicr = (struct acpi_madt_generic_redistributor *)(base_ptr + 
table_len);
+gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+gicr->header.length = size;
+gicr->base_address = d->arch.vgic.rdist_regions[i].base;
+gicr->length = d->arch.vgic.rdist_regions[i].size;
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1380,6 +1422,10 @@ static void __init gicv3_acpi_init(void)
 }
 #else
 static void __init gicv3_acpi_init(void) { }
+static u32 gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+return 0;
+}
 #endif
 
 /* Set up the GIC */
@@ -1474,6 +1520,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .read_apr= gicv3_read_apr,
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
+.make_hwdom_madt = gicv3_make_hwdom_madt,
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void 
*data)
diff --git a/xen/arch/arm/gic.c 

[Xen-devel] [PATCH v3 2/3] tmem: drop direct usage of opt_tmem

[Doug Goldstein]

Most callers of tmem_freeable_pages() checked to see if by checking
opt_tmem before calling tmem_freeable_pages() but not all of them did. This
seemed like an oversight and to avoid similar situations like that,
stick the check of tmem into tmem_freeable_pages(). Similarly other
places should not directly check opt_tmem but instead use the
tmem_enabled() helper function.

Signed-off-by: Doug Goldstein 
Acked-by: Jan Beulich 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Konrad Rzeszutek Wilk 

change since v2:
- merged commit message from patch 2 and 3
change since v1:
- merged patch 2 and 3
---
 xen/arch/x86/setup.c| 2 +-
 xen/common/memory.c | 2 +-
 xen/common/page_alloc.c | 8 
 xen/common/tmem.c   | 3 +++
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5011930..c5c332d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1272,7 +1272,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 init_domheap_pages(s, e);
 }
 
-if ( opt_tmem )
+if ( tmem_enabled() )
 {
printk(XENLOG_WARNING
   "TMEM physical RAM limit exceeded, disabling TMEM\n");
diff --git a/xen/common/memory.c b/xen/common/memory.c
index ef57219..c7fca96 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -202,7 +202,7 @@ static void populate_physmap(struct memop_args *a)
 
 if ( unlikely(!page) )
 {
-if ( !opt_tmem || a->extent_order )
+if ( !tmem_enabled() || a->extent_order )
 gdprintk(XENLOG_INFO,
  "Could not allocate order=%u extent: id=%d 
memflags=%#x (%u of %u)\n",
  a->extent_order, d->domain_id, a->memflags,
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 22e8feb..98e30e5 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -652,7 +652,7 @@ static void __init setup_low_mem_virq(void)
 static void check_low_mem_virq(void)
 {
 unsigned long avail_pages = total_avail_pages +
-(opt_tmem ? tmem_freeable_pages() : 0) - outstanding_claims;
+tmem_freeable_pages() - outstanding_claims;
 
 if ( unlikely(avail_pages <= low_mem_virq_th) )
 {
@@ -738,7 +738,7 @@ static struct page_info *alloc_heap_pages(
  * Others try tmem pools then fail.  This is a workaround until all
  * post-dom0-creation-multi-page allocations can be eliminated.
  */
-if ( opt_tmem && ((order == 0) || (order >= 9)) &&
+if ( ((order == 0) || (order >= 9)) &&
  (total_avail_pages <= midsize_alloc_zone_pages) &&
  tmem_freeable_pages() )
 goto try_tmem;
@@ -984,7 +984,7 @@ static void free_heap_pages(
 avail[node][zone] += 1 << order;
 total_avail_pages += 1 << order;
 
-if ( opt_tmem )
+if ( tmem_enabled() )
 midsize_alloc_zone_pages = max(
 midsize_alloc_zone_pages, total_avail_pages / MIDSIZE_ALLOC_FRAC);
 
@@ -1755,7 +1755,7 @@ int assign_pages(
 {
 if ( unlikely((d->tot_pages + (1 << order)) > d->max_pages) )
 {
-if ( !opt_tmem || order != 0 || d->tot_pages != d->max_pages )
+if ( !tmem_enabled() || order != 0 || d->tot_pages != d->max_pages 
)
 gprintk(XENLOG_INFO, "Over-allocation for domain %u: "
 "%u > %u\n", d->domain_id,
 d->tot_pages + (1 << order), d->max_pages);
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 0436e49..16e249a 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2837,6 +2837,9 @@ void *tmem_relinquish_pages(unsigned int order, unsigned 
int memflags)
 
 unsigned long tmem_freeable_pages(void)
 {
+if ( !tmem_enabled() )
+return 0;
+
 return tmem_page_list_pages + _atomic_read(freeable_page_count);
 }
 
-- 
2.4.10


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

[Xen-devel] [PATCH 09/16] xen: sched: close potential races when switching scheduler to CPUs

[Dario Faggioli]

by using the sched_switch hook that we have introduced in
the various schedulers.

The key is to let the actual switch of scheduler and the
remapping of the scheduler lock for the CPU (if necessary)
happen together (in the same critical section) protected
(at least) by the old scheduler lock for the CPU.

This also means that, in Credit2 and RTDS, we can get rid
of the code that was doing the scheduler lock remapping
in csched2_free_pdata() and rt_free_pdata(), and of their
triggering ASSERT-s.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Tianyang Chen 
---
 xen/common/sched_credit.c  |9 +
 xen/common/sched_credit2.c |   28 ++--
 xen/common/sched_rt.c  |   13 -
 xen/common/schedule.c  |   30 +-
 4 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 929ba9c..903a704 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -577,6 +577,15 @@ csched_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 {
 unsigned long flags;
 struct csched_private *prv = CSCHED_PRIV(ops);
+struct schedule_data *sd = _cpu(schedule_data, cpu);
+
+/*
+ * This is called either during during boot, resume or hotplug, in
+ * case Credit1 is the scheduler chosen at boot. In such cases, the
+ * scheduler lock for cpu is already pointing to the default per-cpu
+ * spinlock, as Credit1 needs it, so there is no remapping to be done.
+ */
+ASSERT(sd->schedule_lock == >_lock && !spin_is_locked(>_lock));
 
 spin_lock_irqsave(>lock, flags);
 init_pdata(prv, pdata, cpu);
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 25d8e85..64fb028 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1974,7 +1974,6 @@ init_pdata(struct csched2_private *prv, unsigned int cpu)
 {
 unsigned rqi;
 struct csched2_runqueue_data *rqd;
-spinlock_t *old_lock;
 
 ASSERT(spin_is_locked(>lock));
 ASSERT(!cpumask_test_cpu(cpu, >initialized));
@@ -2005,21 +2004,11 @@ init_pdata(struct csched2_private *prv, unsigned int 
cpu)
 activate_runqueue(prv, rqi);
 }
 
-/* IRQs already disabled */
-old_lock = pcpu_schedule_lock(cpu);
-
-/* Move spinlock to new runq lock.  */
-per_cpu(schedule_data, cpu).schedule_lock = >lock;
-
 /* Set the runqueue map */
 prv->runq_map[cpu] = rqi;
 
 cpumask_set_cpu(cpu, >idle);
 cpumask_set_cpu(cpu, >active);
-
-/* _Not_ pcpu_schedule_unlock(): per_cpu().schedule_lock changed! */
-spin_unlock(old_lock);
-
 cpumask_set_cpu(cpu, >initialized);
 
 return rqi;
@@ -2029,10 +2018,19 @@ static void
 csched2_init_pdata(const struct scheduler *ops, void *pdata, int cpu)
 {
 struct csched2_private *prv = CSCHED2_PRIV(ops);
+spinlock_t *old_lock;
 unsigned long flags;
+unsigned rqi;
 
 spin_lock_irqsave(>lock, flags);
-init_pdata(prv, cpu);
+old_lock = pcpu_schedule_lock(cpu);
+
+rqi = init_pdata(prv, cpu);
+/* Move the scheduler lock to the new runq lock. */
+per_cpu(schedule_data, cpu).schedule_lock = >rqd[rqi].lock;
+
+/* _Not_ pcpu_schedule_unlock(): schedule_lock may have changed! */
+spin_unlock(old_lock);
 spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -2079,7 +2077,6 @@ csched2_free_pdata(const struct scheduler *ops, void 
*pcpu, int cpu)
 unsigned long flags;
 struct csched2_private *prv = CSCHED2_PRIV(ops);
 struct csched2_runqueue_data *rqd;
-struct schedule_data *sd = _cpu(schedule_data, cpu);
 int rqi;
 
 spin_lock_irqsave(>lock, flags);
@@ -2107,11 +2104,6 @@ csched2_free_pdata(const struct scheduler *ops, void 
*pcpu, int cpu)
 deactivate_runqueue(prv, rqi);
 }
 
-/* Move spinlock to the original lock.  */
-ASSERT(sd->schedule_lock == >lock);
-ASSERT(!spin_is_locked(>_lock));
-sd->schedule_lock = >_lock;
-
 spin_unlock(>lock);
 
 cpumask_clear_cpu(cpu, >initialized);
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 92be248..0564b1d 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -718,19 +718,6 @@ rt_alloc_pdata(const struct scheduler *ops, int cpu)
 static void
 rt_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
-struct rt_private *prv = rt_priv(ops);
-struct schedule_data *sd = _cpu(schedule_data, cpu);
-unsigned long flags;
-
-spin_lock_irqsave(>lock, flags);
-
-/* Move spinlock back to the default lock */
-ASSERT(sd->schedule_lock == >lock);
-ASSERT(!spin_is_locked(>_lock));
-sd->schedule_lock = >_lock;
-
-spin_unlock_irqrestore(>lock, flags);
-
 free_cpumask_var(_cpumask_scratch[cpu]);
 }
 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c

Re: [Xen-devel] [PATCH 3/6] xentrace: P2M lookup suport for ARM platform

[Julien Grall]

Hello Benjamin,

Thank you for the patch.

On 16/03/16 20:51, Benjamin Sanda wrote:

From: bensanda 

Modified p2m_lookup() to provide support for xentrace on the ARM platform. 
Added check for DOMID_XEN which skips PFN to MFN translation. xentrace sends a 
MFN dirrectly when requesting DOMID_XEN, so no translation is needed. Also sets 
page memory type, p2m_type_t, to p2m_ram_rw to provide correct access.


A line in the commit message should not be longer than 72 characters.



Signed-off-by: Benjamin Sanda 
---
  xen/arch/arm/p2m.c | 19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a2a9c4b..2e7da43 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -228,10 +228,21 @@ paddr_t p2m_lookup(struct domain *d, paddr_t paddr, 
p2m_type_t *t)
  paddr_t ret;
  struct p2m_domain *p2m = >arch.p2m;

-spin_lock(>lock);
-ret = __p2m_lookup(d, paddr, t);
-spin_unlock(>lock);
-
+/* Check for DOMID_XEN: If we are called with DOMID_XEN (from xentrace)


Multi-lines comment in Xen should be:

/*
 * Foo
 * Bar
 */

You can find the coding style in CODING_STYLE.


+then paddr is already a MFN and no translation is needed. We only set the
+page type as p2m_raw_rw and return the MFN directly */


DOMID_XEN is not specific to xentrace. It's a mechanism to share xenheap 
page to any guest.


xentrace is using directly an MFN because DOMID_XEN is considered as a 
PV guest on x86 (i.e MFN == GFN). And we don't have a such concept on ARM.



+if(DOMID_XEN != d->domain_id)



if ( d->domain_id != DOMID_XEN )


+{
+spin_lock(>lock);
+ret = __p2m_lookup(d, paddr, t);
+spin_unlock(>lock);
+}
+else
+{
+*t = p2m_ram_rw;


A DOMID_XEN page could be read only too. For instance, the meta-data of 
the trace buffer is read-only (see t_info), we don't want a domain to be 
able to overwrite them.


However, all the foreign page are mapped read-write. You will need to 
rework the code to map a foreign domain (see XENMAPSPACE_gmfn_foreign) 
to allow read-only foreign page (maybe by adding a new p2m_type_t?).



+ret = paddr;
+}
+
  return ret;
  }




Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuua6cdb77f816961f929d7934643febd2852230135
baseline version:
 qemuua648c137383d84bc4f95696e5293978d9541a26e

Last test of basis85884  2016-03-10 06:52:36 Z6 days
Failing since 86214  2016-03-14 12:20:15 Z2 days3 attempts
Testing same since86362  2016-03-16 02:54:18 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Amit Shah 
  Cao jin 
  Changlong Xie 
  Christian Borntraeger 
  Corey Minyard 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Auger 
  Eugene (jno) Dvurechenski 
  Fam Zheng 
  Gerd Hoffmann 
  Guillaume Subiron 
  Hervé Poussineau 
  Hollis Blanchard 
  Igor Mammedov 
  Ilya Maximets 
  Janosch Frank 
  Jason Wang 
  Jeff Cody 
  Kevin Wolf 
  Kirti Wankhede 
  Ladi Prosek 
  Lan Tianyu 
  Laurent Vivier 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Matthew Rosato 
  Max Reitz 
  Michael S. Tsirkin 
  Neo Jia 
  Paolo