[Xen-devel] [qemu-mainline baseline-only test] 67970: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail REGR. vs. 67964

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67964
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67964

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

version targeted for testing:
 qemuu2dfe5113b11ce0ddb08176ebb54ab7ac4104b413
baseline version:
 qemuu5b2ecabaeabc17f032197246c4846b9ba95ba8a6

Last test of basis67964  2016-10-30 10:18:17 Z1 days
Testing same since67970  2016-10-31 22:18:16 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v3 01/15] docs: L2 Cache Allocation Technology (CAT) feature document.

[Yi Sun]

Hi, Xu,

On 16-10-30 11:51:35, Meng Xu wrote:
> Hi Yi,
> 
> On Mon, Oct 24, 2016 at 11:40 PM, Yi Sun  wrote:
> > Signed-off-by: Yi Sun 
> > ---
> >  docs/features/l2_cat.pandoc | 314 
> > 
> >  1 file changed, 314 insertions(+)
> >  create mode 100644 docs/features/l2_cat.pandoc
> >
> > + 
> > + Status: **Tech Preview**
> > +
> > +Architecture(s): Intel x86
> > +
> > +   Component(s): Hypervisor, toolstack
> > +
> > +   Hardware: Atom codename Goldmont and beyond
> > + 
> 
> I'm interested in trying out your code.
> I'm planning to purchase a SoC with the Atom Goldmont processors.
> Do you have some suggestions about the SoC I should purchase?
> I would prefer to use the same SoC as you have. :-)
> 
> Thank you very much!
> 
> Meng
> 

Thank you for being interesting in this feature! The CPU name is Denverton.

Thanks,
Sun Yi

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

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

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[Dongli Zhang]

Hi David and Jan,

I did more testing on the code. Casting to either (long) or (unsigned long)
would be fine.

However, there is still an issue that ref is of type uint32_t and
IS_ERR_VALUE((unsigned long)ref) would not return true when ref=-ENOSPC (or
other error code).

IS_ERR_VALUE((long)ref) would return false as well.

The solution is to cast ref to (int) first as follows:

-   BUG_ON((signed short)ref < 0);
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)(int)ref));


David, I am very sorry for this error and I will be careful the next time.
Would you please let me know if I should resend a new patch or an incremental
based on previous one at 
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git?

Thank you very much!

Dongli Zhang


- Original Message -
From: da...@davemloft.net
To: dongli.zh...@oracle.com
Cc: linux-ker...@vger.kernel.org, xen-de...@lists.xenproject.org, 
net...@vger.kernel.org, boris.ostrov...@oracle.com, david.vra...@citrix.com, 
jgr...@suse.com
Sent: Tuesday, November 1, 2016 4:06:27 AM GMT +08:00 Beijing / Chongqing / 
Hong Kong / Urumqi
Subject: Re: [PATCH 1/1] xen-netfront: do not cast grant table reference to 
signed short

From: Dongli Zhang 
Date: Mon, 31 Oct 2016 13:38:29 +0800

> While grant reference is of type uint32_t, xen-netfront erroneously casts
> it to signed short in BUG_ON().
> 
> This would lead to the xen domU panic during boot-up or migration when it
> is attached with lots of paravirtual devices.
> 
> Signed-off-by: Dongli Zhang 

Since this is consistent with how the macros in linux/err.h handle "is
this an error" checks, this change looks good to me.

Applied, thanks.

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

Re: [Xen-devel] [PATCH 00/12] xen: add common function for reading optional value

[Juergen Gross]

On 31/10/16 18:08, David Miller wrote:
> From: Juergen Gross 
> Date: Mon, 31 Oct 2016 17:48:18 +0100
> 
>> There are multiple instances of code reading an optional unsigned
>> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
>> same code over and over add a service function doing the job and
>> replace the call of xenbus_scanf() with the call of the new function
>> where appropriate.
> 
> As this seems to be a series that will go through some tree other
> than mine, I assume the networking bits will be taken care of that
> way.
> 

If accepted I expect this series to go through the Xen tree.


Juergen

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ac55b925548f3b33f2bc93e603ecffe4a6cb191a
baseline version:
 ovmf b3400560603bcfaadc08e82a846933446b5afed3

Last test of basis   101825  2016-10-31 08:14:39 Z0 days
Testing same since   101829  2016-10-31 15:44:32 Z0 days2 attempts


People who touched revisions under test:
  Tapan Shah 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [linux-3.10 test] 101828: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101828
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

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

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   64 days
Testing same since   101576  2016-10-21 10:51:14 Z   10 days   17 attempts


People who touched revisions under test:
  Andrea Arcangeli 
  Andrew Morton 
  Bjorn Helgaas 
  Casey Schaufler 
  Dan Carpenter 
  Dave Carroll 
  Greg Kroah-Hartman 
  Herbert Xu 
  Hugh Dickins 
  Ian Abbott 
  James Hogan 
  Jann Horn 
  Jason S. McMullan 
  Jiri Slaby 
  Kashyap Desai 
  Kees Cook 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d
baseline version:
 xen  26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021

Last test of basis   101827  2016-10-31 11:02:00 Z0 days
Testing same since   101834  2016-10-31 22:10:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Scott 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=496673a2ada93c201fbe1cc83146c8bd8e79169d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
496673a2ada93c201fbe1cc83146c8bd8e79169d
+ branch=xen-unstable-smoke
+ revision=496673a2ada93c201fbe1cc83146c8bd8e79169d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x496673a2ada93c201fbe1cc83146c8bd8e79169d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH] Don't clear HCR_VM bit when updating VTTBR.

[Stefano Stabellini]

On Mon, 31 Oct 2016, Steve Capper wrote:
> On Wed, Oct 19, 2016 at 12:59:45PM -0700, Stefano Stabellini wrote:
> > On Mon, 10 Oct 2016, Jun Sun wrote:
> > > Currently function p2m_restore_state() would clear HCR_VM bit, i.e.,
> > > disabling stage2 translation, before updating VTTBR register. After
> > > some research and talking to ARM support, I got confirmed that this is not
> > > necessary. We are currently working on a new platform that would need this
> > > to be removed.
> > > 
> > > The patch is tested on FVP foundation model.
> > > 
> > > Signed-off-by: Jun Sun 
> > 
> > Hello Jun,
> > 
> > thanks for the patch and sorry for the late reply. I would appreciate
> > feedback from Julien, but he is current AFK.
> > 
> > Steve,
> > can I have your Acked-by on this patch?
> > 
> 
> Apologies for my very late reply on this.
> 
> I've taken a look and I think that this is okay, so please feel free to
> add:
> Acked-by: Steve Capper 

Thanks Steve. Given the state of the release, I am going to push the fix
to Xen 4.9 unless you or Jun have a strong argument for committing this
sooner.


> > 
> > >  xen/arch/arm/p2m.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index cc5634b..e4991df 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -140,8 +140,6 @@ void p2m_restore_state(struct vcpu *n)
> > >  return;
> > >  
> > >  hcr = READ_SYSREG(HCR_EL2);
> > > -WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
> > > -isb();
> > >  
> > >  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
> > >  isb();
> > > -- 
> > > 2.7.4
> > > 
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101796
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101796
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101796
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101796
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101796
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101796
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101796
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101796

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

version targeted for testing:
 qemuu2dfe5113b11ce0ddb08176ebb54ab7ac4104b413
baseline version:
 qemuu5b2ecabaeabc17f032197246c4846b9ba95ba8a6

Last test of basis   101796  2016-10-29 21:17:30 Z2 days
Testing same since   101826  2016-10-31 10:18:57 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH for-4.8] tools/oxenstored: Fix transaction handling in 32bit builds

[Wei Liu]

On Mon, Oct 31, 2016 at 08:51:07PM +, David Scott wrote:
> 
> > On 31 Oct 2016, at 14:19, Wei Liu  wrote:
> > 
> > On Mon, Oct 31, 2016 at 01:21:56PM +, Andrew Cooper wrote:
> >> In a 32bit build, the ocaml code 'proposed_id >= 0x7fff' compiles to:
> >> 
> >>  8055eac:   83 fb ffcmp$0x,%ebx
> >>  8055eaf:   7d 0f   jge8055ec0 <...+0x20>
> >> 
> >> which in C is 'proposed_id >= INT_MIN', or in other words, tautologically
> >> true.  As a result, 32bit builds of oxenstored always try to allocate the
> >> transaction id 1, and fall into an infinite loop of trying the next id if
> >> transaction 1 is already in use.
> >> 
> >> Restrict the range down to 1 billion, to sit in the positive half of a 31 
> >> bit
> >> ocaml integer.  The compiled code is now:
> >> 
> >>  8055eac:   b9 ff ff ff 7f  mov$0x7fff,%ecx
> >>  8055eb1:   39 cb   cmp%ecx,%ebx
> >>  8055eb3:   7d 0b   jge8055ec0 <...+0x20>
> >> 
> >> which (other than non-optimal code generation because of the unnecessary 
> >> use
> >> of %ecx), isn't unconditionally true.
> >> 
> >> In principle, the check could be changed to 'proposed_id == 0x7fff' 
> >> which
> >> would still allow for 2 billion transaction in 32bit builds.  However, in
> >> 64bit builds, this reintroduces a risk that if proposed_id is initially
> >> greater than 0x7fff, it will not be clipped suitably into range.
> >> 
> >> Signed-off-by: Andrew Cooper 
> > 
> > Reviewed-by: Wei Liu 
> 
> Acked-by: David Scott 
> 

Applied. Thanks.

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

Re: [Xen-devel] [PATCH for-4.8] tools/oxenstored: Fix transaction handling in 32bit builds

[David Scott]

> On 31 Oct 2016, at 14:19, Wei Liu  wrote:
> 
> On Mon, Oct 31, 2016 at 01:21:56PM +, Andrew Cooper wrote:
>> In a 32bit build, the ocaml code 'proposed_id >= 0x7fff' compiles to:
>> 
>>  8055eac:   83 fb ffcmp$0x,%ebx
>>  8055eaf:   7d 0f   jge8055ec0 <...+0x20>
>> 
>> which in C is 'proposed_id >= INT_MIN', or in other words, tautologically
>> true.  As a result, 32bit builds of oxenstored always try to allocate the
>> transaction id 1, and fall into an infinite loop of trying the next id if
>> transaction 1 is already in use.
>> 
>> Restrict the range down to 1 billion, to sit in the positive half of a 31 bit
>> ocaml integer.  The compiled code is now:
>> 
>>  8055eac:   b9 ff ff ff 7f  mov$0x7fff,%ecx
>>  8055eb1:   39 cb   cmp%ecx,%ebx
>>  8055eb3:   7d 0b   jge8055ec0 <...+0x20>
>> 
>> which (other than non-optimal code generation because of the unnecessary use
>> of %ecx), isn't unconditionally true.
>> 
>> In principle, the check could be changed to 'proposed_id == 0x7fff' which
>> would still allow for 2 billion transaction in 32bit builds.  However, in
>> 64bit builds, this reintroduces a risk that if proposed_id is initially
>> greater than 0x7fff, it will not be clipped suitably into range.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: David Scott 

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

[Xen-devel] [distros-debian-sid test] 67967: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 67925
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 67925
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 67925
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 67925
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 67925

baseline version:
 flight   67925

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[David Miller]

From: Dongli Zhang 
Date: Mon, 31 Oct 2016 13:38:29 +0800

> While grant reference is of type uint32_t, xen-netfront erroneously casts
> it to signed short in BUG_ON().
> 
> This would lead to the xen domU panic during boot-up or migration when it
> is attached with lots of paravirtual devices.
> 
> Signed-off-by: Dongli Zhang 

Since this is consistent with how the macros in linux/err.h handle "is
this an error" checks, this change looks good to me.

Applied, thanks.

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

[Xen-devel] [ovmf baseline-only test] 67969: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 67966

version targeted for testing:
 ovmf b3400560603bcfaadc08e82a846933446b5afed3
baseline version:
 ovmf 92ec8772df33f3c758763adcaf42fd42c8da812c

Last test of basis67966  2016-10-31 05:46:11 Z0 days
Testing same since67969  2016-10-31 14:49:06 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 

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  pass



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

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

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


Push not applicable.


commit b3400560603bcfaadc08e82a846933446b5afed3
Author: Fu Siyuan 
Date:   Mon Oct 31 10:21:39 2016 +0800

NetworkPkg: Check for NULL pointer before dereference it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Reviewed-by: Wu Jiaxin 

commit e86f363564e79dc719bbeed8ce87271b2972f55d
Author: Fu Siyuan 
Date:   Mon Oct 31 10:21:24 2016 +0800

MdeModulePkg: Check for NULL pointer before dereference it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Reviewed-by: Wu Jiaxin 

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

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov]

> Thankyou for the design doc.  An immediate +1 from me, simply for the
> doc existing :)

Thank you for you interest and comments.

> Forgive my ignorance (I am an x86 person, and given the CC list, I guess
> this is talking about ARM systems), but what are coprocessors and what
> might I do with one?

Well coprocessor could be a some processing unit inside a SoC which is
running some firmware and supplementing primary processor functions.
F.e. GPU, DSP, some FPGA inside a SoC.
The living example is a GPU sharing implemented for the ARM based SoC.
BTW, the xengt implements pretty close approach and is a pure x86
world solution.

> > It is targeted capability of different domains to run concurrently different
> > firmware on the coproc.
> I cant parse this sentence.  I presume you mean that the purpose of this
> framework is to provide a mechanism for Xen to share a coprocessors
> resource between multiple domains?

Maybe it should be reworded. I mean that coprocessors are entities
which are running some firmware to perform their tasks. So different
domains in their time slice could run different versions of firmware
on the same coprocessor.
It is mentioned here to stress that domains contexts are totally
independent (both for processed data and for firmware code).

> Grammar nit.  Either "Provide coprocessor resource sharing between..."
> or "Provide sharing of coprocessor resources between..."

Will take "Provide sharing of coprocessor resources between...".


> Does it need to only be configurable at system startup?  There is often
> more flexibility by having a default configuration at system start (so
> dom0 can use the resources), which can later be altered by toolstack policy.

I did mean that hypervisor, what starts first, checks what
coprocessors within the system would be shared, own them and provide
to a framework. Providing some of those resources to dom0 would not a
big deal: just assign a vcoproc to the domain. And yes, it could be a
default configuration.

>
> Considering the latter option, even if you don't implement support at
> first, tends to lead to a cleaner design, but of course it does depend
> heavily on the details of the situation.

Definitely we would tailor the design along with an implementation.

> > * MMU-enabled SoC with MMU-protected coprocessor(s)
> Right - definitely ARM then, but it took me until half way through the
> document to work this out.

You know, it was specified ARM based SoC here. At some point it was
removed such a dependency. Inspired by the already mentioned xengt.

> I would be tempted to extend this slightly, and specify that there
> should be a mechanism for the toolstack to query all of this information
> at arbitrary points in time.

It should be covered here:
>
> > Runtime configuration of scheduling algorithm per instance of shared
> > 
> > coprocessor
> > ---
> >
> > There will be a initial domain tool implemented which will provide a CLI for
> > runtime monitoring of shared coprocessors instances available, per-domain/
> > per-coproc instance list of vcoproc and runtime setup of the scheduler per
> > each coprocessor instance.

Maybe it needs some rewording.

> Do you mean that, ideally, Xen can fully context switch a coprocessor
> behind the back of domU, and the domU driver need not know or care about
> the difference?
You've got the point.

> And, where that isn't possible, some virtual hooks could be introduced
> to the domU driver so domU can opt into sharing when it has a compatible
> driver?
Yes, due to specifics of SoC implementation pure solution could be
inefficient, not secure or even impossible. In this case
drivers/firmware could be modified to cooperate with coprocessor
sharing framework in XEN.
This part could be architecture (coprocessor) specific, or machine
(SoC) specific.

Sincerely,
Andrii Anisov.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2 10 guest-startfail in 101792 pass in 101823
 test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail in 101792 pass in 
101823
 test-armhf-armhf-libvirt   7 host-ping-check-xen fail in 101810 pass in 101823
 test-amd64-i386-xl-raw   10 guest-start  fail in 101810 pass in 101823
 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
in 101810 pass in 101823
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat 
fail in 101810 pass in 101823
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
in 101810 pass in 101823
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 101818 
pass in 101823
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 101818 pass in 101823
 test-amd64-i386-xl-raw 18 guest-start/debian.repeat fail in 101818 pass in 
101823
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 101818 pass 
in 101823
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail pass 
in 101792
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat 
fail pass in 101810
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 101818
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 
guest-start/debianhvm.repeat fail pass in 101818

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101818 blocked 
in 101673
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101673
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101673
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101673
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101673
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101673
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101673
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101673
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101673
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101673

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf ac55b925548f3b33f2bc93e603ecffe4a6cb191a
baseline version:
 ovmf b3400560603bcfaadc08e82a846933446b5afed3

Last test of basis   101825  2016-10-31 08:14:39 Z0 days
Testing same since   101829  2016-10-31 15:44:32 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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
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 ac55b925548f3b33f2bc93e603ecffe4a6cb191a
Author: Tapan Shah 
Date:   Fri Oct 28 12:48:59 2016 -0700

ShellPkg: print only valid characters for file overwrite prompt

When copy command prompts to overwrite an existing file, pressing
backspace continuously removes everything including the shell prompt.
So print only valid characters for file overwrite prompt.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

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

[Xen-devel] [qemu-mainline baseline-only test] 67964: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67951
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67951

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

version targeted for testing:
 qemuu5b2ecabaeabc17f032197246c4846b9ba95ba8a6
baseline version:
 qemuuede0cbeb7892bdf4a19128853a3a3c61a17fb068

Last test of basis67951  2016-10-27 21:51:32 Z3 days
Testing same since67964  2016-10-30 10:18:17 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alexey Kardashevskiy 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Brad Smith 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Emilio G. Cota 
  Fam Zheng 
  Felipe Franciosi 
  Gerd Hoffmann 
  Hervé Poussineau 
  Jason Wang 
  John Paul Adrian Glaubitz 
  John Snow 
  Kevin Wolf 
  Kevin Wolf 
  Laurent Vivier 
  Laurent Vivier 
  Li Qiang 
  Mark Cave-Ayland 
  Max Reitz 
  Michael Roth 
  Nicholas Piggin 
  Nikunj A Dadhania 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Richard Henderson 
  Richard Henderson 
  Samuel Thibault 
  Sandipan Das 
  Swapnil Bokade 

Re: [Xen-devel] [PATCH 08/12] xen: make use of xenbus_read_unsigned() in xen-pcifront

[Bjorn Helgaas]

On Mon, Oct 31, 2016 at 05:48:26PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of the read from int to unsigned,
> but this case has been wrong before: negative values are not allowed
> for the modified case.
> 
> Cc: bhelg...@google.com
> Cc: linux-...@vger.kernel.org
> 
> Signed-off-by: Juergen Gross 

Acked-by: Bjorn Helgaas 

I assume this will be merged with the rest of the series via some tree
other than mine.

> ---
>  drivers/pci/xen-pcifront.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index d6ff5e8..8fc2e95 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -1038,10 +1038,8 @@ static int pcifront_detach_devices(struct 
> pcifront_device *pdev)
>   err = -ENOMEM;
>   goto out;
>   }
> - err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend, str, "%d",
> -);
> - if (err != 1)
> - state = XenbusStateUnknown;
> + state = xenbus_read_unsigned(pdev->xdev->otherend, str,
> +  XenbusStateUnknown);
>  
>   if (state != XenbusStateClosing)
>   continue;
> -- 
> 2.6.6
> 

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

[Xen-devel] [OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run Tempest to check OpenStack

[Anthony PERARD]

This script runs the OpenStack integration test suite, Tempest.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Campbell 

---
No change in V5

Change in V4:
- use \Q\E for tests names
- write the full name of the tests to skip
- use push @ignored_test then join()
- use variables to store common prefix
- rewrite comments

Change in V3:
- Use host as argument of the script.
- Use selecthost() and get rid of $gho.
- Use target_jobdir() instead of builddirsprops().
- Put the ignored Tempest tests into a var and try to explain why there are
  skip.
---
 sg-run-job   |  1 +
 ts-openstack-tempest | 65 
 2 files changed, 66 insertions(+)
 create mode 100755 ts-openstack-tempest

diff --git a/sg-run-job b/sg-run-job
index 5146dd1..932d7bf 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -477,6 +477,7 @@ proc run-job/test-rumprun {} {
 proc need-hosts/test-devstack {} { return host }
 proc run-job/test-devstack {} {
   run-ts . = ts-openstack-deploy host
+  run-ts . = ts-openstack-tempest host
 }
 
 if {[file exists sg-run-job-adhoc]} {
diff --git a/ts-openstack-tempest b/ts-openstack-tempest
new file mode 100755
index 000..91c5f3a
--- /dev/null
+++ b/ts-openstack-tempest
@@ -0,0 +1,65 @@
+#!/usr/bin/perl
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho = selecthost($whhost);
+our $builddir = target_jobdir($ho);
+
+sub tempest() {
+  my @ignored_tests;
+  my $scenario = 'tempest.scenario';
+  my $volume_boot_pattern =
+  "$scenario.test_volume_boot_pattern.TestVolumeBootPattern";
+  my $shelve_instance = "$scenario.test_shelve_instance.TestShelveInstance";
+
+  # Ignore tests which try to boot a guest with /dev/vda as boot device name.
+  push @ignored_tests,
+  "^\Q$volume_boot_pattern.test_volume_boot_pattern\E";
+  push @ignored_tests,
+  "^\Q$volume_boot_pattern.test_create_ebs_image_and_check_boot\E";
+  push @ignored_tests,
+  "^\Q$shelve_instance.test_shelve_volume_backed_instance\E";
+
+  # Those tests access a volume through iSCSI. This does not work when both the
+  # server and client of iSCSI are on the same Xen host, Linux 4.0 is the first
+  # Linux to have a fix.
+  push @ignored_tests,
+  "^\Q${volume_boot_pattern}V2.test_volume_boot_pattern\E";
+  push @ignored_tests,
+  "^\Q${volume_boot_pattern}V2.test_create_ebs_image_and_check_boot\E";
+
+  # This regex below select the tests to run and exclude the ones marked as
+  # slow as well as the explicit tests listed above.
+  # It is based on the one that can be found in tempest.git/tox.ini
+  # in the section [testenv:full].
+  my $ignored_tests = join("|", @ignored_tests);
+  my $regex =
+  
"(?!.*\\[.*\\bslow\\b.*\\]|$ignored_tests)(^tempest\\.(api|scenario|thirdparty))";
+
+  target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Anthony PERARD]

This patch should create a flight "openstack-nova", with those jobs:
  build-amd64
  build-amd64-xsm
  build-amd64-pvops
  build-amd64-libvirt
  test-amd64-amd64-devstack
  test-amd64-amd64-devstack-xsm

About the runvars revision_* of test-*-*-devstack:
  only REVISION_OPENSTACK_NOVA is set, the others are unset.
  Empty revision_* runvar would clone the default branch, which should
  be master for every openstack repos.

Signed-off-by: Anthony PERARD 

---
Change in V6:
- rebased

Change in V5:
- rename flight openstack to openstack-nova
- add -xsm variant of the test
- run test-devstack only on openstack-nova flight

Change in V4:
- also skip build-*-oldkern in make flight
- fix select_xenbranch
- set revision_*=$REVISION_OPENSTACK_* in make-flight
  (was revision_*=master before)
  only REVISION_OPENSTACK_NOVA is set, the others are unset.
  empty revision_* runvar would clone the default branch, which should
  be master for every openstack repos

Change in V3:
- Switch to "track" Nova tree instead of devstack.
Nova is the service we care about from a Xen point of view.
Also it is updated much more often than devstack.
- Use TREE_OPENSTACK_ as prefix for all trees variables.
- Change the filter, keep only *-devstack jobs.
- Add stuff into ./ap-push
- Add stuff into ./cr-daily-branch.
- Add 'openstack' into ./cr-for-branches.
---
 ap-common| 12 
 ap-fetch-version |  4 
 ap-fetch-version-old |  5 +
 ap-print-url |  3 +++
 ap-push  |  5 +
 cr-daily-branch  |  8 
 cr-for-branches  |  2 +-
 cri-common   |  1 +
 make-flight  | 52 
 9 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/ap-common b/ap-common
index cbb815c..b148170 100644
--- a/ap-common
+++ b/ap-common
@@ -54,6 +54,17 @@
 : ${PUSH_TREE_OVMF:=$XENBITS:/home/xen/git/osstest/ovmf.git}
 : ${BASE_TREE_OVMF:=git://xenbits.xen.org/osstest/ovmf.git}
 
+: ${GIT_OPENSTACK_ORG:=git://git.openstack.org}
+: ${TREE_OPENSTACK_CINDER:=$GIT_OPENSTACK_ORG/openstack/cinder.git}
+: ${TREE_OPENSTACK_DEVSTACK:=$GIT_OPENSTACK_ORG/openstack-dev/devstack.git}
+: ${TREE_OPENSTACK_GLANCE:=$GIT_OPENSTACK_ORG/openstack/glance.git}
+: ${TREE_OPENSTACK_KEYSTONE:=$GIT_OPENSTACK_ORG/openstack/keystone.git}
+: ${TREE_OPENSTACK_NOVA:=$GIT_OPENSTACK_ORG/openstack/nova.git}
+: ${TREE_OPENSTACK_REQUIREMENTS:=$GIT_OPENSTACK_ORG/openstack/requirements.git}
+: ${TREE_OPENSTACK_TEMPEST:=$GIT_OPENSTACK_ORG/openstack/tempest.git}
+: 
${PUSH_TREE_OPENSTACK_NOVA:=$XENBITS:/home/xen/git/osstest/openstack-nova.git}
+: ${BASE_TREE_OPENSTACK_NOVA:=git://xenbits.xen.org/osstest/openstack-nova.git}
+
 : ${TREE_LINUXFIRMWARE:=git://xenbits.xen.org/osstest/linux-firmware.git}
 : ${PUSH_TREE_LINUXFIRMWARE:=$XENBITS:/home/osstest/ext/linux-firmware.git}
 : 
${UPSTREAM_TREE_LINUXFIRMWARE:=$GIT_KERNEL_ORG/pub/scm/linux/kernel/git/firmware/linux-firmware.git}
@@ -82,6 +93,7 @@ fi
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 : ${LOCALREV_OVMF:=daily-cron.$branch}
 : ${LOCALREV_XTF:=daily-cron.$branch}
+: ${LOCALREV_OPENSTACK_NOVA:=daily-cron.$branch}
 
 : ${TREEBASE_LINUX_XCP:=http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index a107c93..a714ee2 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -106,6 +106,10 @@ ovmf)
repo_tree_rev_fetch_git ovmf \
$TREE_OVMF_UPSTREAM master $LOCALREV_OVMF
;;
+openstack-nova)
+   repo_tree_rev_fetch_git openstack-nova \
+   $TREE_OPENSTACK_NOVA master $LOCALREV_OPENSTACK_NOVA
+   ;;
 osstest)
 if [ "x$OSSTEST_USE_HEAD" = "xy" ] ; then
git update-ref -m "Arranging to test HEAD" \
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 3cbc176..6dddbb7 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -35,6 +35,7 @@ check_ap_fetch_placeholders
 : ${BASE_LOCALREV_XTF:=daily-cron.$branch.old}
 : ${BASE_LOCALREV_OVMF:=daily-cron.$branch.old}
 : ${BASE_TAG_LIBVIRT:=xen-tested-master}
+: ${BASE_LOCALREV_OPENSTACK_NOVA:=daily-cron.$branch.old}
 
 if info_linux_tree "$branch"; then
repo_tree_rev_fetch_git linux \
@@ -114,6 +115,10 @@ ovmf)
repo_tree_rev_fetch_git ovmf \
$BASE_TREE_OVMF xen-tested-master $BASE_LOCALREV_OVMF
;;
+openstack-nova)
+   repo_tree_rev_fetch_git openstack-nova \
+   $BASE_TREE_OPENSTACK_NOVA xen-tested-master 
$BASE_LOCALREV_OPENSTACK_NOVA
+   ;;
 osstest)
if [ "x$OSSTEST_USE_HEAD" != "xy" ] ; then
git fetch -f $HOME/testing.git production:ap-fetch
diff --git a/ap-print-url b/ap-print-url
index 93c14b3..6f4e6b1 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -67,6 +67,9 @@ ovmf)
 osstest)
echo none:;
;;
+openstack-nova)
+   echo $TREE_OPENSTACK_NOVA
+   ;;
 *)
echo >&2 "branch $branch ?"
exit 1

[Xen-devel] [OSSTEST PATCH v6 0/3] Have OpenStack tested on top of xen's master and libvirt's master.

[Anthony PERARD]

Hi,

I have looked into getting OpenStack been tested on the latest Xen via
osstest.

The ts-openstack-deploy script does prepare a bit more the host, clone
devstack and other OpenStack trees, then run ./stack.sh, which is a bit
like raisin and deploy OpenStack on the host. Once the machine is ready,
the integration test suite from OpenStack, Tempest, is started by
ts-openstack-tempest.

For the last patch that create a flight plan, I've tested only with
`./standalone make-flight openstack` and looked into the database to check
that only the necessary build job and the only test job are there.
(build-amd64{,-pvops,-libvirt} test-amd64-amd64-devstack)

Thanks.

Changes in V6:
  - rebased
  - fix ts-openstack-deploy script to work with newer devstach and new debian.

Change in V5:
  - on small change in patch 1, but I keeped the acked-by
  - few changes in the way the flight is created (in the last patch)

Change in V4:
  few changes listed in second and third patch, mostly cleanup.

Change in V3:
  - Track Nova tree instead of devstack.
  Nova is the service we care about from a Xen point of view.
  Also it is updated much more often than devstack.
  - Cleanups, see change log in patches.

Changes in V2:
  - no more Osstest::Toolstack::OpenStack.
  - osstest now clone every single tree that devstack is going to need.
And ./stack.sh should fail if one tree is missing.
  - avoid build-*-xsm for an openstack flight
  - rename ts-devstack to ts-openstack-devstack
  - New test script ts-openstack-tempest
  - Add CONFIG_CRYPTO_XTS=m to the kernel build.
  - new possible runvar $dom0_mem to control dom0 memory
  - several fix to have volume tests working.
  - have OpenStack deploy from it's builddir instead of /opt/stack
  - have 4GB for dom0 instead of relying on balloning.

Anthony PERARD (3):
  ts-openstack-deploy: Deploy OpenStack on a host with devstack
  ts-openstack-tempest: Run Tempest to check OpenStack
  Create a flight to test OpenStack with xen-unstable and libvirt

 ap-common|  12 ++
 ap-fetch-version |   4 +
 ap-fetch-version-old |   5 +
 ap-print-url |   3 +
 ap-push  |   5 +
 cr-daily-branch  |   8 ++
 cr-for-branches  |   2 +-
 cri-common   |   1 +
 make-flight  |  52 
 sg-run-job   |   6 +
 ts-openstack-deploy  | 338 +++
 ts-openstack-tempest |  65 ++
 12 files changed, 500 insertions(+), 1 deletion(-)
 create mode 100755 ts-openstack-deploy
 create mode 100755 ts-openstack-tempest

-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

[Anthony PERARD]

This script installs any necessary packages and clones all of the OpenStack
trees which are used by devstack to deploy OpenStack.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- rebased
- fix issues due to new debian and newer devstack:
  - add missing libvirt group
  - switch back to old nova-network instead of neutron
  - have devstack use 'service' instead of 'systemctl' to restart
services

Only change in V5:
- edit stackrc from devstack file to change the hardcoded path DEST

No change in V4:
- acked

Change in V3:
- Use host as argument to run the job.
- Use selectjob() and get rid of the unused $gho.
- Use target_jobdir() instead of builddirsprops().
- Remove GIT_BASE from devstack config.
- Rename the script to ts-openstack-deploy (from ts-openstack-devstack).
---
 sg-run-job  |   5 +
 ts-openstack-deploy | 338 
 2 files changed, 343 insertions(+)
 create mode 100755 ts-openstack-deploy

diff --git a/sg-run-job b/sg-run-job
index 9f8d003..5146dd1 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -474,6 +474,11 @@ proc run-job/test-rumprun {} {
  ts-guest-destroy-hardhost   $g   +
 }
 
+proc need-hosts/test-devstack {} { return host }
+proc run-job/test-devstack {} {
+  run-ts . = ts-openstack-deploy host
+}
+
 if {[file exists sg-run-job-adhoc]} {
 source sg-run-job-adhoc
 }
diff --git a/ts-openstack-deploy b/ts-openstack-deploy
new file mode 100755
index 000..5758f82
--- /dev/null
+++ b/ts-openstack-deploy
@@ -0,0 +1,338 @@
+#!/usr/bin/perl
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho = selecthost($whhost);
+our $builddir = target_jobdir($ho);
+
+sub tgt_init ();
+
+sub packages () {
+  # Install open-iscsi ahead of devstack ...
+  target_install_packages($ho, qw(git sudo open-iscsi));
+  # ... and start open-iscsi to have /etc/iscsi/initiatorname.iscsi
+  # generated. This is done on install on Ubuntu.
+  target_cmd_root($ho, 'service open-iscsi start');
+}
+
+sub checkout () {
+  prepbuilddirs();
+  build_clone($ho, 'cinder', $builddir, 'cinder');
+  build_clone($ho, 'devstack', $builddir, 'devstack');
+  build_clone($ho, 'glance', $builddir, 'glance');
+  build_clone($ho, 'keystone', $builddir, 'keystone');
+  build_clone($ho, 'nova', $builddir, 'nova');
+  build_clone($ho, 'requirements', $builddir, 'requirements');
+  build_clone($ho, 'tempest', $builddir, 'tempest');
+
+  my $vg = target_choose_vg($ho, 10*1024); # 10GB
+  target_putfilecontents_stash($ho, 60, <

Re: [Xen-devel] [PATCH for-4.8 0/2] Disable debug build for hypervisor

[Konrad Rzeszutek Wilk]

On Mon, Oct 31, 2016 at 05:11:19PM +, Andrew Cooper wrote:
> On 31/10/16 17:09, Wei Liu wrote:
> > I think this is new in this release.
> 
> I believe so.
> 
> >  Please check if this is the correct
> > approach.
> >
> > Cc: Andrew Cooper    
> >
> > Cc: George Dunlap  
> >
> > Cc: Ian Jackson  
> >
> > Cc: Jan Beulich  
> >
> > Cc: Konrad Rzeszutek Wilk   
> >
> > Cc: Stefano Stabellini  
> >
> > Cc: Tim Deegan    
> > 
> > Cc: Wei Liu   
> >
> > Wei Liu (2):
> >   xen: disable debug build
> >   Config.mk: fix comment for debug option
> 
> Both Reviewed-by: Andrew Cooper 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH for-4.8 0/2] Disable debug build for hypervisor

[Jan Beulich]

>>> On 31.10.16 at 18:11,  wrote:
> On 31/10/16 17:09, Wei Liu wrote:
>> I think this is new in this release.
> 
> I believe so.

Perhaps an adjustment to the release check list is needed?

Jan

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

Re: [Xen-devel] [PATCH for-4.8 0/2] Disable debug build for hypervisor

[Andrew Cooper]

On 31/10/16 17:09, Wei Liu wrote:
> I think this is new in this release.

I believe so.

>  Please check if this is the correct
> approach.
>
> Cc: Andrew Cooper  
>  
> Cc: George Dunlap    
>  
> Cc: Ian Jackson    
>  
> Cc: Jan Beulich    
>  
> Cc: Konrad Rzeszutek Wilk 
>  
> Cc: Stefano Stabellini    
>  
> Cc: Tim Deegan  
>   
> Cc: Wei Liu   
>
> Wei Liu (2):
>   xen: disable debug build
>   Config.mk: fix comment for debug option

Both Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH for-4.8 2/2] Config.mk: fix comment for debug option

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index ebbd9c0..fb836a4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -16,7 +16,8 @@ or   = $(if $(strip $(1)),$(1),$(if $(strip 
$(2)),$(2),$(if $(strip $(3)),$(
 
 -include $(XEN_ROOT)/.config
 
-# A debug build of Xen and tools?
+# A debug build of tools?
+# Hypervisor debug build is controlled by Kconfig.
 debug ?= n
 debug_symbols ?= $(debug)
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 1/2] xen: disable debug build

[Wei Liu]

Xen debug build is controlled by Kconfig.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index e9f7dcd..b3bb085 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -3,7 +3,7 @@ menu "Debugging Options"
 
 config DEBUG
bool "Developer Checks"
-   default y
+   default n
---help---
  If you say Y here this will enable developer checks such as asserts
  and extra printks. This option is intended for development purposes
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 0/2] Disable debug build for hypervisor

[Wei Liu]

I think this is new in this release. Please check if this is the correct
approach.

Cc: Andrew Cooper    
   
Cc: George Dunlap  
   
Cc: Ian Jackson  
   
Cc: Jan Beulich  
   
Cc: Konrad Rzeszutek Wilk   
   
Cc: Stefano Stabellini  
   
Cc: Tim Deegan    

Cc: Wei Liu   

Wei Liu (2):
  xen: disable debug build
  Config.mk: fix comment for debug option

 Config.mk | 3 ++-
 xen/Kconfig.debug | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [PATCH 00/12] xen: add common function for reading optional value

[David Miller]

From: Juergen Gross 
Date: Mon, 31 Oct 2016 17:48:18 +0100

> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job and
> replace the call of xenbus_scanf() with the call of the new function
> where appropriate.

As this seems to be a series that will go through some tree other
than mine, I assume the networking bits will be taken care of that
way.

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

[Xen-devel] [PATCH 03/12] xen: make use of xenbus_read_unsigned() in xen-blkfront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of some reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: konrad.w...@oracle.com
Cc: roger@citrix.com

Signed-off-by: Juergen Gross 
---
 drivers/block/xen-blkfront.c | 81 ++--
 1 file changed, 26 insertions(+), 55 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 9908597..2ee9646 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1758,17 +1758,13 @@ static int talk_to_blkback(struct xenbus_device *dev,
const char *message = NULL;
struct xenbus_transaction xbt;
int err;
-   unsigned int i, max_page_order = 0;
-   unsigned int ring_page_order = 0;
+   unsigned int i, max_page_order;
+   unsigned int ring_page_order;
 
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "max-ring-page-order", "%u", _page_order);
-   if (err != 1)
-   info->nr_ring_pages = 1;
-   else {
-   ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
-   info->nr_ring_pages = 1 << ring_page_order;
-   }
+   max_page_order = xenbus_read_unsigned(info->xbdev->otherend,
+ "max-ring-page-order", 0);
+   ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
+   info->nr_ring_pages = 1 << ring_page_order;
 
for (i = 0; i < info->nr_rings; i++) {
struct blkfront_ring_info *rinfo = >rinfo[i];
@@ -1877,18 +1873,14 @@ static int talk_to_blkback(struct xenbus_device *dev,
 
 static int negotiate_mq(struct blkfront_info *info)
 {
-   unsigned int backend_max_queues = 0;
-   int err;
+   unsigned int backend_max_queues;
unsigned int i;
 
BUG_ON(info->nr_rings);
 
/* Check if backend supports multiple queues. */
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "multi-queue-max-queues", "%u", _max_queues);
-   if (err < 0)
-   backend_max_queues = 1;
-
+   backend_max_queues = xenbus_read_unsigned(info->xbdev->otherend,
+ "multi-queue-max-queues", 1);
info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
/* We need at least one ring. */
if (!info->nr_rings)
@@ -2195,7 +2187,6 @@ static void blkfront_setup_discard(struct blkfront_info 
*info)
int err;
unsigned int discard_granularity;
unsigned int discard_alignment;
-   unsigned int discard_secure;
 
info->feature_discard = 1;
err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
@@ -2206,10 +2197,9 @@ static void blkfront_setup_discard(struct blkfront_info 
*info)
info->discard_granularity = discard_granularity;
info->discard_alignment = discard_alignment;
}
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "discard-secure", "%u", _secure);
-   if (err > 0)
-   info->feature_secdiscard = !!discard_secure;
+   info->feature_secdiscard =
+   !!xenbus_read_unsigned(info->xbdev->otherend, "discard-secure",
+  0);
 }
 
 static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo)
@@ -2301,16 +2291,11 @@ static int blkfront_setup_indirect(struct 
blkfront_ring_info *rinfo)
  */
 static void blkfront_gather_backend_features(struct blkfront_info *info)
 {
-   int err;
-   int barrier, flush, discard, persistent;
unsigned int indirect_segments;
 
info->feature_flush = 0;
info->feature_fua = 0;
 
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "feature-barrier", "%d", );
-
/*
 * If there's no "feature-barrier" defined, then it means
 * we're dealing with a very old backend which writes
@@ -2318,7 +2303,7 @@ static void blkfront_gather_backend_features(struct 
blkfront_info *info)
 *
 * If there are barriers, then we use flush.
 */
-   if (err > 0 && barrier) {
+   if (xenbus_read_unsigned(info->xbdev->otherend, "feature-barrier", 0)) {
info->feature_flush = 1;
info->feature_fua = 1;
}
@@ -2327,35 +2312,23 @@ static void blkfront_gather_backend_features(struct 
blkfront_info *info)
 * And if there is "feature-flush-cache" use that above
 * barriers.
 */
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "feature-flush-cache", "%d", );
-
-   if (err > 0 && flush) {
+   if (xenbus_read_unsigned(info->xbdev->otherend, "feature-flush-cache",
+0)) {
  

[Xen-devel] [PATCH 00/12] xen: add common function for reading optional value

[Juergen Gross]

There are multiple instances of code reading an optional unsigned
parameter from Xenstore via xenbus_scanf(). Instead of repeating the
same code over and over add a service function doing the job and
replace the call of xenbus_scanf() with the call of the new function
where appropriate.

Juergen Gross (12):
  xen: introduce xenbus_read_unsigned()
  xen: make use of xenbus_read_unsigned() in xen-blkback
  xen: make use of xenbus_read_unsigned() in xen-blkfront
  xen: make use of xenbus_read_unsigned() in xen-tpmfront
  xen: make use of xenbus_read_unsigned() in xen-kbdfront
  xen: make use of xenbus_read_unsigned() in xen-netback
  xen: make use of xenbus_read_unsigned() in xen-netfront
  xen: make use of xenbus_read_unsigned() in xen-pcifront
  xen: make use of xenbus_read_unsigned() in xen-scsifront
  xen: make use of xenbus_read_unsigned() in xen-fbfront
  xen: make use of xenbus_read_unsigned() in xen-pciback
  xen: make use of xenbus_read_unsigned() in xenbus

 drivers/block/xen-blkback/xenbus.c| 36 ++
 drivers/block/xen-blkfront.c  | 81 ++-
 drivers/char/tpm/xen-tpmfront.c   |  8 +--
 drivers/input/misc/xen-kbdfront.c | 13 ++---
 drivers/net/xen-netback/xenbus.c  | 50 ++-
 drivers/net/xen-netfront.c| 67 +++--
 drivers/pci/xen-pcifront.c|  6 +--
 drivers/scsi/xen-scsifront.c  |  6 +--
 drivers/video/fbdev/xen-fbfront.c | 13 ++---
 drivers/xen/xen-pciback/xenbus.c  |  8 ++-
 drivers/xen/xenbus/xenbus_probe_backend.c |  8 +--
 drivers/xen/xenbus/xenbus_xs.c| 22 +++--
 include/xen/xenbus.h  |  4 ++
 13 files changed, 112 insertions(+), 210 deletions(-)

Cc: konrad.w...@oracle.com
Cc: roger@citrix.com
Cc: peterhu...@gmx.de
Cc: tp...@selhorst.net
Cc: jarkko.sakki...@linux.intel.com
Cc: jguntho...@obsidianresearch.com
Cc: tpmdd-de...@lists.sourceforge.net
Cc: dmitry.torok...@gmail.com
Cc: linux-in...@vger.kernel.org
Cc: wei.l...@citrix.com
Cc: paul.durr...@citrix.com
Cc: net...@vger.kernel.org
Cc: bhelg...@google.com
Cc: linux-...@vger.kernel.org
Cc: tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
-- 
2.6.6


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

[Xen-devel] [PATCH 06/12] xen: make use of xenbus_read_unsigned() in xen-netback

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of some reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: wei.l...@citrix.com
Cc: paul.durr...@citrix.com
Cc: net...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 drivers/net/xen-netback/xenbus.c | 50 +++-
 1 file changed, 14 insertions(+), 36 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 8674e18..7356e00 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -785,12 +785,9 @@ static void xen_mcast_ctrl_changed(struct xenbus_watch 
*watch,
struct xenvif *vif = container_of(watch, struct xenvif,
  mcast_ctrl_watch);
struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
-   int val;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend,
-"request-multicast-control", "%d", ) < 0)
-   val = 0;
-   vif->multicast_control = !!val;
+   vif->multicast_control = !!xenbus_read_unsigned(dev->otherend,
+   "request-multicast-control", 0);
 }
 
 static int xen_register_mcast_ctrl_watch(struct xenbus_device *dev,
@@ -934,12 +931,9 @@ static void connect(struct backend_info *be)
/* Check whether the frontend requested multiple queues
 * and read the number requested.
 */
-   err = xenbus_scanf(XBT_NIL, dev->otherend,
-  "multi-queue-num-queues",
-  "%u", _num_queues);
-   if (err < 0) {
-   requested_num_queues = 1; /* Fall back to single queue */
-   } else if (requested_num_queues > xenvif_max_queues) {
+   requested_num_queues = xenbus_read_unsigned(dev->otherend,
+   "multi-queue-num-queues", 1);
+   if (requested_num_queues > xenvif_max_queues) {
/* buggy or malicious guest */
xenbus_dev_fatal(dev, err,
 "guest requested %u queues, exceeding the 
maximum of %u.",
@@ -1134,7 +1128,7 @@ static int read_xenbus_vif_flags(struct backend_info *be)
struct xenvif *vif = be->vif;
struct xenbus_device *dev = be->dev;
unsigned int rx_copy;
-   int err, val;
+   int err;
 
err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
   _copy);
@@ -1150,10 +1144,7 @@ static int read_xenbus_vif_flags(struct backend_info *be)
if (!rx_copy)
return -EOPNOTSUPP;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend,
-"feature-rx-notify", "%d", ) < 0)
-   val = 0;
-   if (!val) {
+   if (!xenbus_read_unsigned(dev->otherend, "feature-rx-notify", 0)) {
/* - Reduce drain timeout to poll more frequently for
 *   Rx requests.
 * - Disable Rx stall detection.
@@ -1162,34 +1153,21 @@ static int read_xenbus_vif_flags(struct backend_info 
*be)
be->vif->stall_timeout = 0;
}
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-"%d", ) < 0)
-   val = 0;
-   vif->can_sg = !!val;
+   vif->can_sg = !!xenbus_read_unsigned(dev->otherend, "feature-sg", 0);
 
vif->gso_mask = 0;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
-"%d", ) < 0)
-   val = 0;
-   if (val)
+   if (xenbus_read_unsigned(dev->otherend, "feature-gso-tcpv4", 0))
vif->gso_mask |= GSO_BIT(TCPV4);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
-"%d", ) < 0)
-   val = 0;
-   if (val)
+   if (xenbus_read_unsigned(dev->otherend, "feature-gso-tcpv6", 0))
vif->gso_mask |= GSO_BIT(TCPV6);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-no-csum-offload",
-"%d", ) < 0)
-   val = 0;
-   vif->ip_csum = !val;
+   vif->ip_csum = !xenbus_read_unsigned(dev->otherend,
+"feature-no-csum-offload", 0);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-ipv6-csum-offload",
-"%d", ) < 0)
-   val = 0;
-   vif->ipv6_csum = !!val;
+   vif->ipv6_csum = !!xenbus_read_unsigned(dev->otherend,
+   "feature-ipv6-csum-offload", 0);
 
return 0;
 }
-- 
2.6.6


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

[Xen-devel] [PATCH 07/12] xen: make use of xenbus_read_unsigned() in xen-netfront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of some reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: net...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 drivers/net/xen-netfront.c | 67 +-
 1 file changed, 18 insertions(+), 49 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e17879d..95d664e 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1169,43 +1169,23 @@ static netdev_features_t xennet_fix_features(struct 
net_device *dev,
netdev_features_t features)
 {
struct netfront_info *np = netdev_priv(dev);
-   int val;
 
-   if (features & NETIF_F_SG) {
-   if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-sg",
-"%d", ) < 0)
-   val = 0;
+   if (features & NETIF_F_SG &&
+   !xenbus_read_unsigned(np->xbdev->otherend, "feature-sg", 0))
+   features &= ~NETIF_F_SG;
 
-   if (!val)
-   features &= ~NETIF_F_SG;
-   }
+   if (features & NETIF_F_IPV6_CSUM &&
+   !xenbus_read_unsigned(np->xbdev->otherend,
+ "feature-ipv6-csum-offload", 0))
+   features &= ~NETIF_F_IPV6_CSUM;
 
-   if (features & NETIF_F_IPV6_CSUM) {
-   if (xenbus_scanf(XBT_NIL, np->xbdev->otherend,
-"feature-ipv6-csum-offload", "%d", ) < 0)
-   val = 0;
+   if (features & NETIF_F_TSO &&
+   !xenbus_read_unsigned(np->xbdev->otherend, "feature-gso-tcpv4", 0))
+   features &= ~NETIF_F_TSO;
 
-   if (!val)
-   features &= ~NETIF_F_IPV6_CSUM;
-   }
-
-   if (features & NETIF_F_TSO) {
-   if (xenbus_scanf(XBT_NIL, np->xbdev->otherend,
-"feature-gso-tcpv4", "%d", ) < 0)
-   val = 0;
-
-   if (!val)
-   features &= ~NETIF_F_TSO;
-   }
-
-   if (features & NETIF_F_TSO6) {
-   if (xenbus_scanf(XBT_NIL, np->xbdev->otherend,
-"feature-gso-tcpv6", "%d", ) < 0)
-   val = 0;
-
-   if (!val)
-   features &= ~NETIF_F_TSO6;
-   }
+   if (features & NETIF_F_TSO6 &&
+   !xenbus_read_unsigned(np->xbdev->otherend, "feature-gso-tcpv6", 0))
+   features &= ~NETIF_F_TSO6;
 
return features;
 }
@@ -1821,18 +1801,13 @@ static int talk_to_netback(struct xenbus_device *dev,
info->netdev->irq = 0;
 
/* Check if backend supports multiple queues */
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "multi-queue-max-queues", "%u", _queues);
-   if (err < 0)
-   max_queues = 1;
+   max_queues = xenbus_read_unsigned(info->xbdev->otherend,
+ "multi-queue-max-queues", 1);
num_queues = min(max_queues, xennet_max_queues);
 
/* Check feature-split-event-channels */
-   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "feature-split-event-channels", "%u",
-  _split_evtchn);
-   if (err < 0)
-   feature_split_evtchn = 0;
+   feature_split_evtchn = xenbus_read_unsigned(info->xbdev->otherend,
+   "feature-split-event-channels", 0);
 
/* Read mac addr. */
err = xen_net_read_mac(dev, info->netdev->dev_addr);
@@ -1966,16 +1941,10 @@ static int xennet_connect(struct net_device *dev)
struct netfront_info *np = netdev_priv(dev);
unsigned int num_queues = 0;
int err;
-   unsigned int feature_rx_copy;
unsigned int j = 0;
struct netfront_queue *queue = NULL;
 
-   err = xenbus_scanf(XBT_NIL, np->xbdev->otherend,
-  "feature-rx-copy", "%u", _rx_copy);
-   if (err != 1)
-   feature_rx_copy = 0;
-
-   if (!feature_rx_copy) {
+   if (!xenbus_read_unsigned(np->xbdev->otherend, "feature-rx-copy", 0)) {
dev_info(>dev,
 "backend does not support copying receive path\n");
return -ENODEV;
-- 
2.6.6


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

[Xen-devel] [PATCH 02/12] xen: make use of xenbus_read_unsigned() in xen-blkback

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of one read from int to unsigned,
but this case has been wrong before: negative values are not allowed
for the modified case.

Cc: konrad.w...@oracle.com
Cc: roger@citrix.com

Signed-off-by: Juergen Gross 
---
 drivers/block/xen-blkback/xenbus.c | 36 ++--
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 3cc6d1d..415e79b 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -533,13 +533,11 @@ static void xen_blkbk_discard(struct xenbus_transaction 
xbt, struct backend_info
struct xenbus_device *dev = be->dev;
struct xen_blkif *blkif = be->blkif;
int err;
-   int state = 0, discard_enable;
+   int state = 0;
struct block_device *bdev = be->blkif->vbd.bdev;
struct request_queue *q = bdev_get_queue(bdev);
 
-   err = xenbus_scanf(XBT_NIL, dev->nodename, "discard-enable", "%d",
-  _enable);
-   if (err == 1 && !discard_enable)
+   if (!xenbus_read_unsigned(dev->nodename, "discard-enable", 1))
return;
 
if (blk_queue_discard(q)) {
@@ -1039,30 +1037,24 @@ static int connect_ring(struct backend_info *be)
xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
return -ENOSYS;
}
-   err = xenbus_scanf(XBT_NIL, dev->otherend,
-  "feature-persistent", "%u", _grants);
-   if (err <= 0)
-   pers_grants = 0;
-
+   pers_grants = xenbus_read_unsigned(dev->otherend, "feature-persistent",
+  0);
be->blkif->vbd.feature_gnt_persistent = pers_grants;
be->blkif->vbd.overflow_max_grants = 0;
 
/*
 * Read the number of hardware queues from frontend.
 */
-   err = xenbus_scanf(XBT_NIL, dev->otherend, "multi-queue-num-queues",
-  "%u", _num_queues);
-   if (err < 0) {
-   requested_num_queues = 1;
-   } else {
-   if (requested_num_queues > xenblk_max_queues
-   || requested_num_queues == 0) {
-   /* Buggy or malicious guest. */
-   xenbus_dev_fatal(dev, err,
-   "guest requested %u queues, exceeding 
the maximum of %u.",
-   requested_num_queues, 
xenblk_max_queues);
-   return -ENOSYS;
-   }
+   requested_num_queues = xenbus_read_unsigned(dev->otherend,
+   "multi-queue-num-queues",
+   1);
+   if (requested_num_queues > xenblk_max_queues
+   || requested_num_queues == 0) {
+   /* Buggy or malicious guest. */
+   xenbus_dev_fatal(dev, err,
+   "guest requested %u queues, exceeding the 
maximum of %u.",
+   requested_num_queues, xenblk_max_queues);
+   return -ENOSYS;
}
be->blkif->nr_rings = requested_num_queues;
if (xen_blkif_alloc_rings(be->blkif))
-- 
2.6.6


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

[Xen-devel] [PATCH 01/12] xen: introduce xenbus_read_unsigned()

[Juergen Gross]

There are multiple instances of code reading an optional unsigned
parameter from Xenstore via xenbus_scanf(). Instead of repeating the
same code over and over add a service function doing the job.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xenbus/xenbus_xs.c | 15 +++
 include/xen/xenbus.h   |  4 
 2 files changed, 19 insertions(+)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 22f7cd7..99dfdfa 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -559,6 +559,21 @@ int xenbus_scanf(struct xenbus_transaction t,
 }
 EXPORT_SYMBOL_GPL(xenbus_scanf);
 
+/* Read an (optional) unsigned value. */
+unsigned int xenbus_read_unsigned(const char *dir, const char *node,
+ unsigned int default_val)
+{
+   unsigned int val;
+   int ret;
+
+   ret = xenbus_scanf(XBT_NIL, dir, node, "%u", );
+   if (ret <= 0)
+   val = default_val;
+
+   return val;
+}
+EXPORT_SYMBOL_GPL(xenbus_read_unsigned);
+
 /* Single printf and write: returns -errno or 0. */
 int xenbus_printf(struct xenbus_transaction t,
  const char *dir, const char *node, const char *fmt, ...)
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 32b944b..271ba62 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -151,6 +151,10 @@ __scanf(4, 5)
 int xenbus_scanf(struct xenbus_transaction t,
 const char *dir, const char *node, const char *fmt, ...);
 
+/* Read an (optional) unsigned value. */
+unsigned int xenbus_read_unsigned(const char *dir, const char *node,
+ unsigned int default_val);
+
 /* Single printf and write: returns -errno or 0. */
 __printf(4, 5)
 int xenbus_printf(struct xenbus_transaction t,
-- 
2.6.6


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

[Xen-devel] [PATCH 05/12] xen: make use of xenbus_read_unsigned() in xen-kbdfront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: dmitry.torok...@gmail.com
Cc: linux-in...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 drivers/input/misc/xen-kbdfront.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 227fbd2..3900875 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -108,7 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
 static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
-   int ret, i, abs;
+   int ret, i;
+   unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
 
@@ -127,8 +128,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
) < 0)
-   abs = 0;
+   abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
if (abs) {
ret = xenbus_write(XBT_NIL, dev->nodename,
   "request-abs-pointer", "1");
@@ -322,11 +322,8 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
 
case XenbusStateInitWait:
 InitWait:
-   ret = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "feature-abs-pointer", "%d", );
-   if (ret < 0)
-   val = 0;
-   if (val) {
+   if (xenbus_read_unsigned(info->xbdev->otherend,
+"feature-abs-pointer", 0)) {
ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
   "request-abs-pointer", "1");
if (ret)
-- 
2.6.6


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

[Xen-devel] [PATCH 09/12] xen: make use of xenbus_read_unsigned() in xen-scsifront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.

Signed-off-by: Juergen Gross 
---
 drivers/scsi/xen-scsifront.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 9dc8687..7e817c6 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -1060,13 +1060,9 @@ static void scsifront_read_backend_params(struct 
xenbus_device *dev,
  struct vscsifrnt_info *info)
 {
unsigned int sg_grant, nr_segs;
-   int ret;
struct Scsi_Host *host = info->host;
 
-   ret = xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg-grant", "%u",
-  _grant);
-   if (ret != 1)
-   sg_grant = 0;
+   sg_grant = xenbus_read_unsigned(dev->otherend, "feature-sg-grant", 0);
nr_segs = min_t(unsigned int, sg_grant, SG_ALL);
nr_segs = max_t(unsigned int, nr_segs, VSCSIIF_SG_TABLESIZE);
nr_segs = min_t(unsigned int, nr_segs,
-- 
2.6.6


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

[Xen-devel] [PATCH 04/12] xen: make use of xenbus_read_unsigned() in xen-tpmfront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of one read from int to unsigned,
but this case has been wrong before: negative values are not allowed
for the modified case.

Cc: peterhu...@gmx.de
Cc: tp...@selhorst.net
Cc: jarkko.sakki...@linux.intel.com
Cc: jguntho...@obsidianresearch.com
Cc: tpmdd-de...@lists.sourceforge.net

Signed-off-by: Juergen Gross 
---
 drivers/char/tpm/xen-tpmfront.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 62028f4..50072cc 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -337,18 +337,14 @@ static int tpmfront_resume(struct xenbus_device *dev)
 static void backend_changed(struct xenbus_device *dev,
enum xenbus_state backend_state)
 {
-   int val;
-
switch (backend_state) {
case XenbusStateInitialised:
case XenbusStateConnected:
if (dev->state == XenbusStateConnected)
break;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend,
-   "feature-protocol-v2", "%d", ) < 0)
-   val = 0;
-   if (!val) {
+   if (!xenbus_read_unsigned(dev->otherend, "feature-protocol-v2",
+ 0)) {
xenbus_dev_fatal(dev, -EINVAL,
"vTPM protocol 2 required");
return;
-- 
2.6.6


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

[Xen-devel] [PATCH 10/12] xen: make use of xenbus_read_unsigned() in xen-fbfront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 drivers/video/fbdev/xen-fbfront.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/xen-fbfront.c 
b/drivers/video/fbdev/xen-fbfront.c
index 0567d51..d0115a7 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -633,7 +633,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
  enum xenbus_state backend_state)
 {
struct xenfb_info *info = dev_get_drvdata(>dev);
-   int val;
 
switch (backend_state) {
case XenbusStateInitialising:
@@ -657,16 +656,12 @@ static void xenfb_backend_changed(struct xenbus_device 
*dev,
if (dev->state != XenbusStateConnected)
goto InitWait; /* no InitWait seen yet, fudge it */
 
-   if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-"request-update", "%d", ) < 0)
-   val = 0;
-   if (val)
+   if (xenbus_read_unsigned(info->xbdev->otherend,
+"request-update", 0))
info->update_wanted = 1;
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend,
-"feature-resize", "%d", ) < 0)
-   val = 0;
-   info->feature_resize = val;
+   info->feature_resize = xenbus_read_unsigned(dev->otherend,
+   "feature-resize", 0);
break;
 
case XenbusStateClosed:
-- 
2.6.6


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

[Xen-devel] [PATCH 12/12] xen: make use of xenbus_read_unsigned() in xenbus

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xenbus/xenbus_probe_backend.c | 8 +---
 drivers/xen/xenbus/xenbus_xs.c| 7 +++
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c 
b/drivers/xen/xenbus/xenbus_probe_backend.c
index 04f7f85..37929df 100644
--- a/drivers/xen/xenbus/xenbus_probe_backend.c
+++ b/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -224,13 +224,7 @@ static int read_frontend_details(struct xenbus_device 
*xendev)
 
 int xenbus_dev_is_online(struct xenbus_device *dev)
 {
-   int rc, val;
-
-   rc = xenbus_scanf(XBT_NIL, dev->nodename, "online", "%d", );
-   if (rc != 1)
-   val = 0; /* no online node present */
-
-   return val;
+   return !!xenbus_read_unsigned(dev->nodename, "online", 0);
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
 
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 99dfdfa..6afb993 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -687,7 +687,7 @@ static bool xen_strict_xenbus_quirk(void)
 }
 static void xs_reset_watches(void)
 {
-   int err, supported = 0;
+   int err;
 
if (!xen_hvm_domain() || xen_initial_domain())
return;
@@ -695,9 +695,8 @@ static void xs_reset_watches(void)
if (xen_strict_xenbus_quirk())
return;
 
-   err = xenbus_scanf(XBT_NIL, "control",
-   "platform-feature-xs_reset_watches", "%d", );
-   if (err != 1 || !supported)
+   if (!xenbus_read_unsigned("control",
+ "platform-feature-xs_reset_watches", 0))
return;
 
err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
-- 
2.6.6


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

[Xen-devel] [PATCH 11/12] xen: make use of xenbus_read_unsigned() in xen-pciback

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the read from int to unsigned,
but this case has been wrong before: negative values are not allowed
for the modified case.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xen-pciback/xenbus.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 5ce878c..3f0aee0 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -362,7 +362,7 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device 
*pdev)
int err = 0;
int num_devs;
int domain, bus, slot, func;
-   int substate;
+   unsigned int substate;
int i, len;
char state_str[64];
char dev_str[64];
@@ -395,10 +395,8 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device 
*pdev)
 "configuration");
goto out;
}
-   err = xenbus_scanf(XBT_NIL, pdev->xdev->nodename, state_str,
-  "%d", );
-   if (err != 1)
-   substate = XenbusStateUnknown;
+   substate = xenbus_read_unsigned(pdev->xdev->nodename, state_str,
+   XenbusStateUnknown);
 
switch (substate) {
case XenbusStateInitialising:
-- 
2.6.6


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

[Xen-devel] [PATCH 08/12] xen: make use of xenbus_read_unsigned() in xen-pcifront

[Juergen Gross]

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the read from int to unsigned,
but this case has been wrong before: negative values are not allowed
for the modified case.

Cc: bhelg...@google.com
Cc: linux-...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 drivers/pci/xen-pcifront.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index d6ff5e8..8fc2e95 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1038,10 +1038,8 @@ static int pcifront_detach_devices(struct 
pcifront_device *pdev)
err = -ENOMEM;
goto out;
}
-   err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend, str, "%d",
-  );
-   if (err != 1)
-   state = XenbusStateUnknown;
+   state = xenbus_read_unsigned(pdev->xdev->otherend, str,
+XenbusStateUnknown);
 
if (state != XenbusStateClosing)
continue;
-- 
2.6.6


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

Re: [Xen-devel] [PATCH v3.1 07/15] xen/x86: do the PCI scan unconditionally

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1491,6 +1491,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  early_msi_init();
>  
> +scan_pci_devices();
> +
>  iommu_setup();/* setup iommu if available */
>  
>  smp_prepare_cpus(max_cpus);
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
>  
>  if ( !amd_iommu_perdev_intremap )
>  printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is 
> not recommended (see XSA-36)!\n");
> -return scan_pci_devices();
> +
> +return 0;
>  }

I'm relatively certain that I did point out on a prior version that the
error handling here gets lost. At the very least the commit message
should provide a reason for doing so; even better would be if there
was no behavioral change (other than the point in time where this
happens slightly changing).

Jan

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

Re: [Xen-devel] [PATCH v3.1 06/15] xen/x86: split the setup of Dom0 permissions to a function

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> So that it can also be used by the PVH-specific domain builder. This is just
> code motion, it should not introduce any functional change.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v3.1 05/15] x86/paging: introduce paging_set_allocation

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -1609,13 +1609,7 @@ shadow_free_p2m_page(struct domain *d, struct 
> page_info *pg)
>  paging_unlock(d);
>  }
>  
> -/* Set the pool of shadow pages to the required number of pages.
> - * Input will be rounded up to at least shadow_min_acceptable_pages(),
> - * plus space for the p2m table.
> - * Returns 0 for success, non-zero for failure. */
> -static int sh_set_allocation(struct domain *d,
> - unsigned int pages,
> - int *preempted)
> +int sh_set_allocation(struct domain *d, unsigned int pages, bool *preempted)

Iirc functions with a name starting with sh_ are shadow code internal,
so you may better switch to shadow_set_allocation(). Tim?

With that taken care of (unless Tim indicates there's no need),
Reviewed-by: Jan Beulich 

Jan

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

[Xen-devel] [linux-3.4 test] 101822: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 101822
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720

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

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

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  187 days
Testing same since   101695  2016-10-26 18:26:23 Z4 days8 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Charles Keepax 
  Chen Yu 
  Christoph Hellwig 
  Chunfeng Yun 
  Clemens Ladisch 
  Colin Ian King 
  Cong Wang 
  Daeho Jeong 
  Dan Carpenter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David Rientjes 
  David 

Re: [Xen-devel] [PATCH v3.1 04/15] xen/x86: assert that local_events_need_delivery is not called by the idle domain

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> It doesn't make sense since the idle domain doesn't receive any events. This
> is relevant in order to be sure that hypercall_preempt_check is not called
> by the idle domain, which would happen previously when calling
> {hap/sh}_set_allocation during domain 0 creation.

AIUI this describes the state of things before this series, not before
this patch. I wonder whether this wouldn't better be folded into the
previous patch, with the commit message slightly adjusted.

Jan

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

Re: [Xen-devel] [PATCH v3.1 00/15] Initial PVHv2 Dom0 support

[Roger Pau Monne]

On Mon, Oct 31, 2016 at 02:43:08PM +, Andrew Cooper wrote:
> On 31/10/16 14:35, Boris Ostrovsky wrote:
> >
> >
> > On 10/29/2016 04:59 AM, Roger Pau Monne wrote:
> >> (resending as v3.1, it seems like I need to figure out how to
> >> properly use
> >> msmtp with git send-email because on the last try only the cover letter
> >> was actually sent).
> >>
> >> Hello,
> >>
> >> This is the first batch of the PVH Dom0 support eries, that includes
> >> everything up to the point where ACPI tables for he Dom0 are crafted.
> >> I've
> >> decided to left the last part of the series (the ne that contains the
> >> PCI
> >> config space handlers, and other mulation/trapping related code)
> >> separated,
> >> in order to focus and ease the review. This is f course not
> >> functional, one
> >> might be able to partially boot a Dom0 kernel if t doesn't try to access
> >> any physical device.
> >>
> >> Another reason for splitting this series is so hat I can write a proper
> >> design document about how this trapping is going o work, and what is it
> >> supposed to do, because during the last review ound I got the feeling
> >> that
> >> some comments where not really related to the ode itself, but to what
> >> I was
> >> trying to achieve, so it's best to discuss them n a design document
> >> rather
> >> than mixed up with code.
> >
> >
> > Given that we are dropping PVHv1 support from Linux and the fact that
> > v1 has always been a tech preview (or some such) should we drop it now?
> >
> > The is_pvh_domain() is getting more and more confusing.
> 
> +1 for dropping all the PVHv1 remnants from Xen.
> 
> Perhaps the start of 4.9 is the best time to flip this switch.

Yes, I don't have any objections to that. Perhaps it should be done after 
this series is in, since here I'm reusing some of the PVH code in 
domain_build.c (so removing PVH before committing this would force me to 
reintroduce those functions later on).

Roger.

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

Re: [Xen-devel] [PATCH v3.1 03/15] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> ... and using the "preempted" parameter. The solution relies on just calling
> softirq_pending if the current domain is the idle domain. If such preemption
> happens, the caller should then call process_pending_softirqs in order to
> drain the pending softirqs, and then call {sh/hap}_set_allocation again to
> continue with it's execution.
> 
> This allows us to call *_set_allocation() when building domain 0.
> 
> Signed-off-by: Roger Pau Monné 
> Acked-by: George Dunlap 
> ---
> Cc: George Dunlap 

Cc: Tim

> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> Changes since v2:
>  - Fix commit message.
> ---
>  xen/arch/x86/mm/hap/hap.c   | 4 +++-
>  xen/arch/x86/mm/shadow/common.c | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index f099e94..0645521 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned int pages, 
> int *preempted)
>  break;
>  
>  /* Check to see if we need to yield and try again */
> -if ( preempted && hypercall_preempt_check() )
> +if ( preempted &&
> + (is_idle_vcpu(current) ? softirq_pending(smp_processor_id()) :
> +  hypercall_preempt_check()) )
>  {
>  *preempted = 1;
>  return 0;
> diff --git a/xen/arch/x86/mm/shadow/common.c 
> b/xen/arch/x86/mm/shadow/common.c
> index 065bdc7..b2e99c2 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -1679,7 +1679,9 @@ static int sh_set_allocation(struct domain *d,
>  break;
>  
>  /* Check to see if we need to yield and try again */
> -if ( preempted && hypercall_preempt_check() )
> +if ( preempted &&
> + (is_idle_vcpu(current) ? softirq_pending(smp_processor_id()) :
> +  hypercall_preempt_check()) )
>  {
>  *preempted = 1;
>  return 0;
> -- 
> 2.7.4 (Apple Git-66)



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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Jan Beulich]

>>> On 29.10.16 at 10:59,  wrote:
> PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
> from physical or emulated devices over event channels using PIRQs. This
> applies to both DomU and Dom0 PVHv2 guests.
> 
> Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> route physical interrupts (even from emulated devices) over event channels,
> and is thus allowed to use some of the PHYSDEV ops.
> 
> Signed-off-by: Roger Pau Monné 

The patch looks fine now for its purpose, but I'm hesitant to ack it
without us having settled on whether we indeed mean to hide all
those physdev ops from Dom0. In particular I don't recall this (and
the reasoning behind it) having got written down somewhere.

Jan

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

Re: [Xen-devel] [PATCH] stubdom: fix "make distclean" regarding gmp

[Samuel Thibault]

Juergen Gross, on Fri 28 Oct 2016 16:53:20 +0200, wrote:
> make distclean tries to remove stubdom/gmp-4.3.2.tar.gz, while the
> downloaded file is stubdom/gmp-4.3.2.tar.bz2
> 
> Signed-off-by: Juergen Gross 

Acked-by: Samuel Thibault 

> ---
>  stubdom/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index d7a47f0..0252bcc 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -649,7 +649,7 @@ patchclean: crossclean
>  downloadclean: patchclean
>   rm -f newlib-$(NEWLIB_VERSION).tar.gz
>   rm -f zlib-$(ZLIB_VERSION).tar.gz
> - rm -f gmp-$(GMP_VERSION).tar.gz
> + rm -f gmp-$(GMP_VERSION).tar.bz2
>   rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz
>   rm -f pciutils-$(LIBPCI_VERSION).tar.bz2
>   rm -f grub-$(GRUB_VERSION).tar.gz
> -- 
> 2.6.6
> 

-- 
Samuel
c> [ ] morning [ ] afternoon [ ] evening [ ] night , everyone (choose as 
applicable)

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

Re: [Xen-devel] [PATCH v6 7/7] VMX: Fixup PI descriptor when cpu is offline

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -203,6 +203,76 @@ static void vmx_pi_do_resume(struct vcpu *v)
>  vmx_pi_unblock_vcpu(v);
>  }
>  
> +void vmx_pi_desc_fixup(int cpu)

unsigned int

With that fixed,
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] Xen on Qualcomm

[Julien Grall]

On 31/10/16 14:59, Suresh Kanzariya wrote:

Hi Julien,


Hi,

It seems that I forgot to add xen-devel on CC in my answer. Sorry for that.


Thanks for the information.

Just wanted to understand that Qualcomm boot itself contains a
Hypervisor and also Xen is also a hypervisor, so I am not sure Xen
hypervisor directly fits into the design, I guess Qualcomm hypervisor
need modification or remove completely to support xen. It will be
great if you can spread some light on this.


Indeed 2 hypervisors cannot cooperate on the same processor. If Qualcomm 
provides any hypervisor, you would have to remove it.


Although, I don't know much this platform, so I would recommend to 
contact Qualcomm for anything regarding that.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[Wei Liu]

On Sun, Oct 30, 2016 at 04:53:33PM +, Andrew Cooper wrote:
> On 30/10/16 04:29, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> > testid debian-hvm-install
> >
> > Tree: linux git://xenbits.xen.org/linux-pvops.git
> > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> > Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> > Tree: xen git://xenbits.xen.org/xen.git
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  0897514b4b376a167f968f79c6ea0dee1061458e
> >   Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
> >
> >
> >   commit 0897514b4b376a167f968f79c6ea0dee1061458e
> >   Author: Andrew Cooper 
> >   Date:   Wed Oct 26 10:34:21 2016 +0100
> >   
> >   tools/oxenstored: Avoid allocating invalid transaction ids
> 
> I have to admit that I am staring at this report in belief, but it is
> apparently deterministic.  It is very strange that only this job is
> affected; if there was actually a problem with xenstore transactions, I
> would have thought that there to be collateral damage everywhere.
> 
> Looking through the logs, there are several concerning things happening
> even in the success cases.
> 
> First:
> 
> (XEN) HVM1 restore: CPU 0
> (XEN) avc:  denied  { getvcpucontext } for domid=0 target=2
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dm_dom_t
> tclass=domain
> 
> The toolstack calls getvcpucontext as part of domain creation, and the
> XSM policy disallows this on dm_dom_t's.  Interestingly, this failure
> doesn't appear to be fatal to domain creation, and it really ought to
> be.  I expect there is also another bug lurking in the lower levels of
> the toolstack.
> 

No idea about this at the moment.

> Second:
> 
> (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:577
> (XEN) [ Xen-4.8.0-rc  x86_64  debug=y   Not tainted ]
> 
> (XEN) Xen call trace:
> (XEN)[] _xmalloc+0x2f/0x313
> (XEN)[] services.c#context_struct_to_string+0x98/0x16d
> (XEN)[] security_sid_to_context+0xd3/0xe7
> (XEN)[] hooks.c#flask_show_security_evtchn+0x6f/0x87
> (XEN)[] event_channel.c#dump_evtchn_info+0x246/0x2cb
> (XEN)[] handle_keypress+0x8c/0xac
> (XEN)[] console.c#__serial_rx+0x38/0x73
> (XEN)[] console.c#serial_rx+0x8a/0x8f
> (XEN)[] serial_rx_interrupt+0x90/0xac
> (XEN)[] ns16550.c#ns16550_interrupt+0x57/0x71
> (XEN)[] do_IRQ+0x56e/0x60f
> (XEN)[] common_interrupt+0x67/0x70
> (XEN)[] mwait-idle.c#mwait_idle+0x2af/0x2f9
> 
> The 'e' debugkey isn't safe to use when XSM is compiled in, as
> security_sid_to_context() allocates memory.
> 

This can not be easily fixed without reworking the XSM framework API. I
propose we just disable the offending snippet.

> Furthermore, any unexpected host crashes should cause a failure of the
> test.  This appears to have gone unnoticed because it happens in the
> capture-logs phase, with presumably sufficient timeouts that OSSTest
> doesn't notice that the host rebooted in the middle of log collection.
> 
> Third:
> 
> (d2) **
> (d2) blk_open(/local/domain/2/device/vbd/5632) -> 6
> (d2) xs_watch(device-model/1/logdirty/cmd, logdirty)
> (d2) xs_watch(device-model/1/command, dm-command)
> (d2) xs_watch(/local/domain/1/cpu, vcpu-set)
> (d2) xs_read(/local/domain/0/backend/pci/1/0/msitranslate): ENOENT
> (d2) xs_read(/local/domain/0/backend/pci/1/0/power_mgmt): ENOENT
> (d2) open(/var/log/dm-serial.log) -> 7
> (d2) fcntl(-1, 3, 3ffbc8/17775710)
> (d2) fcntl(-1, 4, /377)
> (d2) fcntl(7, 3, /377)
> (d2) fcntl(7, 4, /377)
> (d2) xs_watch(/local/domain/0/backend/console/1, be:0x14b1a7:1:0x186800)
> (d2) xs_directory(/local/domain/0/backend/console/1): EACCES
> (d2) xs_watch(/local/domain/0/backend/vkbd/1, be:0x1479ff:1:0x1867c0)
> (d2) xs_directory(/local/domain/0/backend/vkbd/1): EACCES
> (d2) xs_read(device-model/1/disable_pf): ENOENT
> (d2) xs_watch(/local/domain/1/log-throttling,
> /local/domain/1/log-throttling)
> (d2) Thread "kbdfront": pointer: 0x0xb0182570, stack: 0x0xaa
> (d2) *** FBFRONT for /local/domain/2/device/vfb/0 **
> 
> The stub qemu attempts to read d1's backends.  It probably shouldn't be
> doing that.
> 

This is (supposedly) harmless, so a low priority bug.

Wei.

> 
> Comparing the xenstored-access logs, between the success and failure
> cases, it does appear that in the failing case, all transactions have
> the id 1.  I am trying to debug why.
> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v6 6/7] VT-d: Some cleanups

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> @@ -643,7 +643,8 @@ static int msi_msg_to_remap_entry(
>  GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
>   iremap_entries, iremap_entry);
>  
> -memcpy(_ire, iremap_entry, sizeof(struct iremap_entry));
> +if ( iremap_entry->remap.p )
> +new_ire.remap.im = iremap_entry->remap.im;

I don't understand this change, but I also don't think the change is
going to be wanted/needed once the issues with the previous patch
got sorted out.

Jan

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

Re: [Xen-devel] [PATCH v6 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> v6:
> - Make pi_can_suppress_irte_update() a check-only function
> - Introduce another function pi_get_new_irte() to update the 'new_ire' if 
> needed

I don't see what you need this function for. My earlier comments
were not meant to make you split the function, but to drop all this
secondary modification (unless there's actually a reason for this,
which so far I haven't seen any proof of). Apart from that there
already is setup_posted_irte(), which seems to do most if not all
of what you really need.

In any event, the sequence of operations should be
1) create full new entry
2) check whether update is needed (i.e. whether old and new entries
   have meaningful differences)
3) do update
4) flush.

> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -547,6 +547,54 @@ static int remap_entry_to_msi_msg(
>  return 0;
>  }
>  
> +static bool pi_can_suppress_irte_update(const struct iremap_entry *new,
> +const struct iremap_entry *old)

The two parameter declarations should be aligned with one another.

> +{
> +ASSERT( old && new );
> +
> +if ( !old->remap.p || !old->remap.im || !new->remap.p || new->remap.im )
> +return false;

The asymmetry regarding the IM bit is confusing, and imo indicates
a problem with the logic.

> +/*
> + * We are updating posted IRTE to remapped one, check whether
> + * the common fields are going to be changed.
> + */
> +if ( ( new->remap.fpd != old->post.fpd ) ||
> + ( new->remap.sid != old->post.sid ) ||
> + ( new->remap.sq != old->post.sq ) ||
> + ( new->remap.svt != old->post.svt ) )

Stray blanks inside the inner parentheses.

Jan

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

Re: [Xen-devel] [PATCH v3.1 00/15] Initial PVHv2 Dom0 support

[Andrew Cooper]

On 31/10/16 14:35, Boris Ostrovsky wrote:
>
>
> On 10/29/2016 04:59 AM, Roger Pau Monne wrote:
>> (resending as v3.1, it seems like I need to figure out how to
>> properly use
>> msmtp with git send-email because on the last try only the cover letter
>> was actually sent).
>>
>> Hello,
>>
>> This is the first batch of the PVH Dom0 support eries, that includes
>> everything up to the point where ACPI tables for he Dom0 are crafted.
>> I've
>> decided to left the last part of the series (the ne that contains the
>> PCI
>> config space handlers, and other mulation/trapping related code)
>> separated,
>> in order to focus and ease the review. This is f course not
>> functional, one
>> might be able to partially boot a Dom0 kernel if t doesn't try to access
>> any physical device.
>>
>> Another reason for splitting this series is so hat I can write a proper
>> design document about how this trapping is going o work, and what is it
>> supposed to do, because during the last review ound I got the feeling
>> that
>> some comments where not really related to the ode itself, but to what
>> I was
>> trying to achieve, so it's best to discuss them n a design document
>> rather
>> than mixed up with code.
>
>
> Given that we are dropping PVHv1 support from Linux and the fact that
> v1 has always been a tech preview (or some such) should we drop it now?
>
> The is_pvh_domain() is getting more and more confusing.

+1 for dropping all the PVHv1 remnants from Xen.

Perhaps the start of 4.9 is the best time to flip this switch.

~Andrew

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

Re: [Xen-devel] [PATCH v3.1 00/15] Initial PVHv2 Dom0 support

[Boris Ostrovsky]

On 10/29/2016 04:59 AM, Roger Pau Monne wrote:

(resending as v3.1, it seems like I need to figure out how to properly use
msmtp with git send-email because on the last try only the cover letter
was actually sent).

Hello,

This is the first batch of the PVH Dom0 support eries, that includes
everything up to the point where ACPI tables for he Dom0 are crafted. I've
decided to left the last part of the series (the ne that contains the PCI
config space handlers, and other mulation/trapping related code) separated,
in order to focus and ease the review. This is f course not functional, one
might be able to partially boot a Dom0 kernel if t doesn't try to access
any physical device.

Another reason for splitting this series is so hat I can write a proper
design document about how this trapping is going o work, and what is it
supposed to do, because during the last review ound I got the feeling that
some comments where not really related to the ode itself, but to what I was
trying to achieve, so it's best to discuss them n a design document rather
than mixed up with code.



Given that we are dropping PVHv1 support from Linux and the fact that v1 
has always been a tech preview (or some such) should we drop it now?


The is_pvh_domain() is getting more and more confusing.

-boris

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b3400560603bcfaadc08e82a846933446b5afed3
baseline version:
 ovmf 92ec8772df33f3c758763adcaf42fd42c8da812c

Last test of basis   101821  2016-10-31 03:08:35 Z0 days
Testing same since   101825  2016-10-31 08:14:39 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

[Jan Beulich]

>>> On 31.10.16 at 15:13,  wrote:
> On 31/10/16 14:12, Jan Beulich wrote:
> On 31.10.16 at 14:48,  wrote:
>>> --- a/xen/arch/x86/hvm/svm/svmdebug.c
>>> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
>>> @@ -20,11 +20,10 @@
>>>  #include 
>>>  #include 
>>>  
>>> -static void svm_dump_sel(const char *name, svm_segment_register_t *s)
>>> +static void svm_dump_sel(const char *name, const svm_segment_register_t *s)
>>>  {
>>> -printk("%s: sel=0x%04x, attr=0x%04x, limit=0x%08x, base=0x%016llx\n", 
>>> -   name, s->sel, s->attr.bytes, s->limit,
>>> -   (unsigned long long)s->base);
>>> +printk("%s: %04x %05x %08x %016"PRIx64"\n",
>>> +   name, s->sel, s->attr.bytes, s->limit, s->base);
>> Why do you change to 5 digits for the attributes? Other than VMX,
>> SVM has nothing defined beyond bit 15.
> 
> Good point - I blindly copied the VMX side without adjusting.  Will fix.

With that
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] [PATCH for-4.8] tools/oxenstored: Fix transaction handling in 32bit builds

[Wei Liu]

On Mon, Oct 31, 2016 at 01:21:56PM +, Andrew Cooper wrote:
> In a 32bit build, the ocaml code 'proposed_id >= 0x7fff' compiles to:
> 
>   8055eac:   83 fb ffcmp$0x,%ebx
>   8055eaf:   7d 0f   jge8055ec0 <...+0x20>
> 
> which in C is 'proposed_id >= INT_MIN', or in other words, tautologically
> true.  As a result, 32bit builds of oxenstored always try to allocate the
> transaction id 1, and fall into an infinite loop of trying the next id if
> transaction 1 is already in use.
> 
> Restrict the range down to 1 billion, to sit in the positive half of a 31 bit
> ocaml integer.  The compiled code is now:
> 
>   8055eac:   b9 ff ff ff 7f  mov$0x7fff,%ecx
>   8055eb1:   39 cb   cmp%ecx,%ebx
>   8055eb3:   7d 0b   jge8055ec0 <...+0x20>
> 
> which (other than non-optimal code generation because of the unnecessary use
> of %ecx), isn't unconditionally true.
> 
> In principle, the check could be changed to 'proposed_id == 0x7fff' which
> would still allow for 2 billion transaction in 32bit builds.  However, in
> 64bit builds, this reintroduces a risk that if proposed_id is initially
> greater than 0x7fff, it will not be clipped suitably into range.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

[Andrew Cooper]

On 31/10/16 14:12, Jan Beulich wrote:
 On 31.10.16 at 14:48,  wrote:
>> --- a/xen/arch/x86/hvm/svm/svmdebug.c
>> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
>> @@ -20,11 +20,10 @@
>>  #include 
>>  #include 
>>  
>> -static void svm_dump_sel(const char *name, svm_segment_register_t *s)
>> +static void svm_dump_sel(const char *name, const svm_segment_register_t *s)
>>  {
>> -printk("%s: sel=0x%04x, attr=0x%04x, limit=0x%08x, base=0x%016llx\n", 
>> -   name, s->sel, s->attr.bytes, s->limit,
>> -   (unsigned long long)s->base);
>> +printk("%s: %04x %05x %08x %016"PRIx64"\n",
>> +   name, s->sel, s->attr.bytes, s->limit, s->base);
> Why do you change to 5 digits for the attributes? Other than VMX,
> SVM has nothing defined beyond bit 15.

Good point - I blindly copied the VMX side without adjusting.  Will fix.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

[Jan Beulich]

>>> On 31.10.16 at 14:48,  wrote:
> --- a/xen/arch/x86/hvm/svm/svmdebug.c
> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
> @@ -20,11 +20,10 @@
>  #include 
>  #include 
>  
> -static void svm_dump_sel(const char *name, svm_segment_register_t *s)
> +static void svm_dump_sel(const char *name, const svm_segment_register_t *s)
>  {
> -printk("%s: sel=0x%04x, attr=0x%04x, limit=0x%08x, base=0x%016llx\n", 
> -   name, s->sel, s->attr.bytes, s->limit,
> -   (unsigned long long)s->base);
> +printk("%s: %04x %05x %08x %016"PRIx64"\n",
> +   name, s->sel, s->attr.bytes, s->limit, s->base);

Why do you change to 5 digits for the attributes? Other than VMX,
SVM has nothing defined beyond bit 15.

Jan

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

Re: [Xen-devel] [PATCH 0/2] Fix Xen boot on XGene

[Julien Grall]

Hi Stefano,

On 26/10/16 23:12, Stefano Stabellini wrote:

On Wed, 26 Oct 2016, Julien Grall wrote:

Hi,
Apologize for not respecting the netiquette.

On Tue, 25 Oct 2016, 5:49 p.m. Stefano Stabellini,  
wrote:
  Hi all,

  the following commit:

  commit 21550029f709072aacf3b90edd574e7d3021b400
  Author: Julien Grall 
  Date:   Thu Oct 8 19:23:53 2015 +0100

  xen/arm: gic-v2: Automatically detect aliased GIC400


  removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to
  check whether the two GICC pages have a 64K stride. However the
  heuristic needs device tree to report a GICC region size of 128K to work
  properly. That is not the case for some versions of XGene (including the
  one I am using, kindly provided by CloudLab.us).

  The patch series fixes the issue by reintroducing platform quirks,
  PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if
  PLATFORM_QUIRK_GIC_64K_STRIDE.

  We should consider this series for 4.8.


The platform you are using has likely a buggy firmware (I cannot find the mail 
from
APM stating that).

I am not convinced that we should support a such case. IIRC unmodified Linux 
will
not work properly on those platform (e.g the GIC will be drived as a GICv1).


I agree with you that it is buggy firmware, but unfortunately it is
still out there, deployed. I am using a regular unmodified old Linux
kernel (4.0) which works fine (and should still work fine with modern
Xen hypervisors). I believe this DTS comes from upstream Linux 4.0.

The question is: should we carry this workaround to make our users' life
easier? Or should we push back the burden of fixing the firmware to the
users? There are valid arguments for both, eventually it comes down to
finding the right compromise.


In general it is better to get the newest firmware as other unrelated 
bugs may be present on older version or there is missing workaround for 
broken hardware (e.g enabling chicken bits). For instance, we have 
already decided to not support some version of the X-gene firmware (see 
commit 784c2d1 "xen/arm: Drop support of platform where GICH_LR_HW is 
not working correctly").


In this specific case, you assume that the GIC device tree node will 
always point to the beginning of the first 64K page. It might be 
possible in the future to have an updated firmware pointing to the last 
alias of the first page, so the second 4K page will follow directly.




To be clear I don't feel strongly either way, but I think it is easier
for us to carry this workaround than for our users to update the
firmware. So in this case I would take these patches. But it might not
be the case in the future for other, more invasive, workarounds. Let me
know what you think.


I would much prefer something in Xen to check whether the user has to 
upgrade his firmware based on known broken features.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

[Andrew Cooper]

This makes it more succinct and easier to read.

Before:
  (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
  (XEN) CS: sel=0x0008, attr=0x029b, limit=0x, base=0x
  (XEN) DS: sel=0x0033, attr=0x0cf3, limit=0x, base=0x
  (XEN) SS: sel=0x0018, attr=0x0c93, limit=0x, base=0x
  (XEN) ES: sel=0x0033, attr=0x0cf3, limit=0x, base=0x
  (XEN) FS: sel=0x0033, attr=0x0cf3, limit=0x, base=0x
  (XEN) GS: sel=0x0033, attr=0x0cf3, limit=0x, base=0x
  (XEN) GDTR: sel=0x, attr=0x, limit=0x0067, base=0x0010d100
  (XEN) LDTR: sel=0x, attr=0x, limit=0x, base=0x
  (XEN) IDTR: sel=0x, attr=0x, limit=0x0fff, base=0x00110900
  (XEN) TR: sel=0x0038, attr=0x0089, limit=0x0067, base=0x0010d020

After:
  (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
  (XEN)sel  attr  limit   base
  (XEN)   CS: 0008 0029b  
  (XEN)   DS: 0033 00cf3  
  (XEN)   SS: 0018 00c93  
  (XEN)   ES: 0033 00cf3  
  (XEN)   FS: 0033 00cf3  
  (XEN)   GS: 0033 00cf3  
  (XEN) GDTR:  0 0067 0010d100
  (XEN) LDTR:  0  
  (XEN) IDTR:  0 0fff 00110900
  (XEN)   TR: 0038 00089 0067 0010d020

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svmdebug.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index ded5d19..f85f70a 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -20,11 +20,10 @@
 #include 
 #include 
 
-static void svm_dump_sel(const char *name, svm_segment_register_t *s)
+static void svm_dump_sel(const char *name, const svm_segment_register_t *s)
 {
-printk("%s: sel=0x%04x, attr=0x%04x, limit=0x%08x, base=0x%016llx\n", 
-   name, s->sel, s->attr.bytes, s->limit,
-   (unsigned long long)s->base);
+printk("%s: %04x %05x %08x %016"PRIx64"\n",
+   name, s->sel, s->attr.bytes, s->limit, s->base);
 }
 
 /* This function can directly access fields which are covered by clean bits. */
@@ -79,16 +78,17 @@ void svm_vmcb_dump(const char *from, struct vmcb_struct 
*vmcb)
(unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);
 
 /* print out all the selectors */
-svm_dump_sel("CS", >cs);
-svm_dump_sel("DS", >ds);
-svm_dump_sel("SS", >ss);
-svm_dump_sel("ES", >es);
-svm_dump_sel("FS", >fs);
-svm_dump_sel("GS", >gs);
+printk("   sel  attr  limit   base\n");
+svm_dump_sel("  CS", >cs);
+svm_dump_sel("  DS", >ds);
+svm_dump_sel("  SS", >ss);
+svm_dump_sel("  ES", >es);
+svm_dump_sel("  FS", >fs);
+svm_dump_sel("  GS", >gs);
 svm_dump_sel("GDTR", >gdtr);
 svm_dump_sel("LDTR", >ldtr);
 svm_dump_sel("IDTR", >idtr);
-svm_dump_sel("TR", >tr);
+svm_dump_sel("  TR", >tr);
 }
 
 bool_t
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Julien Grall]

Hi Jan,

On 12/10/16 13:59, Jan Beulich wrote:

On 12.10.16 at 14:51,  wrote:

Hello Jan,

On 12/10/2016 12:45, Jan Beulich wrote:

On 11.10.16 at 15:39,  wrote:

On 06/10/16 13:21, Jan Beulich wrote:

On 05.10.16 at 20:30,  wrote:

On 30/09/2016 02:46, Jan Beulich wrote:

On 29.09.16 at 23:42,  wrote:

+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif


Did you build test this for ARM? The function ought to be unused,
as ...


@@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif

+free_ebmalloc_unused_mem();


... the whole function here doesn't get built on ARM.

Julien - we're still awaiting your input on general aspects here.


efi_init_memory would need to be called during Xen boot on ARM. I am not
sure where as I we don't yet have runtime support on ARM.

Other than that, the patch looks good to me.


But that wasn't the question. My goal is to have as little code
inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
as much of this new code as possible outside of such conditionals.
So the question really is whether that alternative approach would
be fine with you, or what problems you might see.


I am not sure to get it. The current approach looks good to me, however,
the implementation should not be exposed to ARM until all the TODOs
mentioned by Daniel are fixed.


Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
  using this, let's just bump it (perhaps by making it a per-arch
  constant),
- if the section chosen needs to be different (which it really
  shouldn't be), let's simply adjust it,


If we keep the section in BSS, then we really need to move the
initialization of BSS earlier.


Right, but that should be simple enough. Or we do ...


This TODO really needs to be fixed now otherwise it will be a nightmare
to debug later on.


- as we've already figured there's no need for the stub
  free_ebmalloc_unused_mem() right now anyway.


But we would need to call free_ebmalloc_unused_mem from somewhere. The
idea to not expose the early memory allocator on ARM is avoid to have an
implementation with may not fully work on ARM because of known missing
pieces.


And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.


... this, which you didn't comment on at all.


I skipped this part by mistake. That would work to, assuming there is a 
proper comment on top of EBMALLOC_SIZE explaining what needs to be done 
in order to fully support the early allocator on ARM.


Both solutions are fine by me.

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH for-4.8] tools/oxenstored: Fix transaction handling in 32bit builds

[Andrew Cooper]

In a 32bit build, the ocaml code 'proposed_id >= 0x7fff' compiles to:

  8055eac:   83 fb ffcmp$0x,%ebx
  8055eaf:   7d 0f   jge8055ec0 <...+0x20>

which in C is 'proposed_id >= INT_MIN', or in other words, tautologically
true.  As a result, 32bit builds of oxenstored always try to allocate the
transaction id 1, and fall into an infinite loop of trying the next id if
transaction 1 is already in use.

Restrict the range down to 1 billion, to sit in the positive half of a 31 bit
ocaml integer.  The compiled code is now:

  8055eac:   b9 ff ff ff 7f  mov$0x7fff,%ecx
  8055eb1:   39 cb   cmp%ecx,%ebx
  8055eb3:   7d 0b   jge8055ec0 <...+0x20>

which (other than non-optimal code generation because of the unnecessary use
of %ecx), isn't unconditionally true.

In principle, the check could be changed to 'proposed_id == 0x7fff' which
would still allow for 2 billion transaction in 32bit builds.  However, in
64bit builds, this reintroduces a risk that if proposed_id is initially
greater than 0x7fff, it will not be clipped suitably into range.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: David Scott 
---
 tools/ocaml/xenstored/connection.ml | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/xenstored/connection.ml 
b/tools/ocaml/xenstored/connection.ml
index 0b47009..3ffd35b 100644
--- a/tools/ocaml/xenstored/connection.ml
+++ b/tools/ocaml/xenstored/connection.ml
@@ -218,8 +218,16 @@ let fire_watch watch path =
 
 (* Search for a valid unused transaction id. *)
 let rec valid_transaction_id con proposed_id =
-   (* Clip proposed_id to the range [1, 0x7ffe] *)
-   let id = if proposed_id <= 0 || proposed_id >= 0x7fff then 1 else 
proposed_id in
+   (*
+* Clip proposed_id to the range [1, 0x3ffe]
+*
+* The chosen id must not trucate when written into the uint32_t tx_id
+* field, and needs to fit within the positive range of a 31 bit ocaml
+* integer to function when compiled as 32bit.
+*
+* Oxenstored therefore supports only 1 billion open transactions.
+*)
+   let id = if proposed_id <= 0 || proposed_id >= 0x3fff then 1 else 
proposed_id in
 
if Hashtbl.mem con.transactions id then (
(* Outstanding transaction with this id.  Try the next. *)
-- 
2.1.4


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

Re: [Xen-devel] [PULL 00/13] xen-20161028-tag

[Peter Maydell]

On 29 October 2016 at 02:10, Stefano Stabellini  wrote:
> The following changes since commit 5b2ecabaeabc17f032197246c4846b9ba95ba8a6:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' into 
> staging (2016-10-28 17:59:04 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161028-tag
>
> for you to fetch changes up to 71981364b6152e63d0f3098fcdf8b884fa9ffa50:
>
>   xen: Rename xen_be_del_xendev (2016-10-28 17:54:49 -0700)
>
> 
> Xen 2016/10/28
>
> 
> Emil Condrea (13):
>   xen: Fix coding style errors
>   xen: Fix coding style warnings
>   xen: Create a new file xen_pvdev.c
>   xen: Move xenstore_update to xen_pvdev.c
>   xen: Move evtchn functions to xen_pvdev.c
>   xen: Prepare xendev qtail to be shared with frontends
>   xen: Move xenstore cleanup and mkdir functions
>   xen: Rename xen_be_printf to xen_pv_printf
>   xen: Rename xen_be_unbind_evtchn
>   xen: Rename xen_be_send_notify
>   xen: Rename xen_be_evtchn_event
>   xen: Rename xen_be_find_xendev
>   xen: Rename xen_be_del_xendev
>

Applied, thanks.

-- PMM

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021
baseline version:
 xen  a62511bf14971ff581212decbbf57fc11b967840

Last test of basis   101824  2016-10-31 08:02:25 Z0 days
Testing same since   101827  2016-10-31 11:02:00 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Juergen Gross 
  Roger Pau Monne 
  Roger Pau Monné 
  Samuel Thibault 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021
+ branch=xen-unstable-smoke
+ revision=26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x26c4f0b8a4cf233f600f4163fc3aeeb7f70b3021 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : 

[Xen-devel] [linux-3.10 test] 101820: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101820
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

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

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   63 days
Testing same since   101576  2016-10-21 10:51:14 Z   10 days   16 attempts


People who touched revisions under test:
  Andrea Arcangeli 
  Andrew Morton 
  Bjorn Helgaas 
  Casey Schaufler 
  Dan Carpenter 
  Dave Carroll 
  Greg Kroah-Hartman 
  Herbert Xu 
  Hugh Dickins 
  Ian Abbott 
  James Hogan 
  Jann Horn 
  Jason S. McMullan 
  Jiri Slaby 
  Kashyap Desai 
  Kees Cook 

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Boris Ostrovsky]

On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:

From: Matt Fleming 

The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.

Pull the common code out of head_32.S and into pgtable_32.S so that
setup_pgtable_32 can be invoked from both the new Xen entry point and
the existing startup_32 code.



Ping to x86 maintainers.

Peter, you had questions about this patch. Did I answer them?

-boris




Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Signed-off-by: Matt Fleming 
---
 arch/x86/Makefile|   2 +
 arch/x86/kernel/Makefile |   2 +
 arch/x86/kernel/head_32.S| 168 +
 arch/x86/kernel/pgtable_32.S | 196 +++
 4 files changed, 201 insertions(+), 167 deletions(-)
 create mode 100644 arch/x86/kernel/pgtable_32.S

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d44933..67cc771 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -204,6 +204,8 @@ head-y += arch/x86/kernel/head$(BITS).o
 head-y += arch/x86/kernel/ebda.o
 head-y += arch/x86/kernel/platform-quirks.o

+head-$(CONFIG_X86_32) += arch/x86/kernel/pgtable_32.o
+
 libs-y  += arch/x86/lib/

 # See arch/x86/Kbuild for content of core part of the kernel
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4dd5d50..eae85a5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -8,6 +8,8 @@ extra-y += ebda.o
 extra-y+= platform-quirks.o
 extra-y+= vmlinux.lds

+extra-$(CONFIG_X86_32) += pgtable_32.o
+
 CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)

 ifdef CONFIG_FUNCTION_TRACER
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 5f40126..0db066e 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -41,51 +41,6 @@
 #define X86_VENDOR_ID  new_cpu_data+CPUINFO_x86_vendor_id

 /*
- * This is how much memory in addition to the memory covered up to
- * and including _end we need mapped initially.
- * We need:
- * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
- * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
- *
- * Modulo rounding, each megabyte assigned here requires a kilobyte of
- * memory, which is currently unreclaimed.
- *
- * This should be a multiple of a page.
- *
- * KERNEL_IMAGE_SIZE should be greater than pa(_end)
- * and small than max_low_pfn, otherwise will waste some page table entries
- */
-
-#if PTRS_PER_PMD > 1
-#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
-#else
-#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
-#endif
-
-/*
- * Number of possible pages in the lowmem region.
- *
- * We shift 2 by 31 instead of 1 by 32 to the left in order to avoid a
- * gas warning about overflowing shift count when gas has been compiled
- * with only a host target support using a 32-bit type for internal
- * representation.
- */
-LOWMEM_PAGES = (((2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT)
-
-/* Enough space to fit pagetables for the low memory linear map */
-MAPPING_BEYOND_END = PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT
-
-/*
- * Worst-case size of the kernel mapping we need to make:
- * a relocatable kernel can live anywhere in lowmem, so we need to be able
- * to map all of lowmem.
- */
-KERNEL_PAGES = LOWMEM_PAGES
-
-INIT_MAP_SIZE = PAGE_TABLE_SIZE(KERNEL_PAGES) * PAGE_SIZE
-RESERVE_BRK(pagetables, INIT_MAP_SIZE)
-
-/*
  * 32-bit kernel entrypoint; only used by the boot CPU.  On entry,
  * %esi points to the real-mode code as a 32-bit pointer.
  * CS and DS must be 4 GB flat segments, but we don't depend on
@@ -157,92 +112,7 @@ ENTRY(startup_32)
call load_ucode_bsp
 #endif

-/*
- * Initialize page tables.  This creates a PDE and a set of page
- * tables, which are located immediately beyond __brk_base.  The variable
- * _brk_end is set up to point to the first "safe" location.
- * Mappings are created both at virtual address 0 (identity mapping)
- * and PAGE_OFFSET for up to _end.
- */
-#ifdef CONFIG_X86_PAE
-
-   /*
-* In PAE mode initial_page_table is statically defined to contain
-* enough entries to cover the VMSPLIT option (that is the top 1, 2 or 3
-* entries). The identity mapping is handled by pointing two PGD entries
-* to the first kernel PMD.
-*
-* Note the upper half of each PMD or PTE are always zero at this stage.
-*/
-
-#define KPMDS (((-__PAGE_OFFSET) >> 30) & 3) /* Number of kernel PMDs */
-
-   xorl %ebx,%ebx  /* %ebx is kept at zero */
-
-   movl $pa(__brk_base), %edi
-   movl $pa(initial_pg_pmd), %edx
-   movl $PTE_IDENT_ATTR, %eax
-10:
-   leal PDE_IDENT_ATTR(%edi),%ecx  /* Create PMD entry */
-   movl 

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that 
it's being cross-compiled"):
> On Mon, Oct 31, 2016 at 02:57:54AM -0600, Jan Beulich wrote:
> > >>> On 29.10.16 at 19:22,  wrote:
> > > Append --build and --host flags to GMP's configure script so that it
> > > knows it is being compiled for another architecture.
> > 
> > Why --host and --build? Aiui,
> > - host is where the configure runs,
> > - build is where tool chain components being built are supposed to run,
> > - target is where the final binaries are intended to run.
> 
> I think you got them wrong, in particular host and build semantics.
> 
> build is where the build runs, host is where the resulting binary runs,
> target is where the output of the resulting binary runs (assuming the
> binary is compiler).
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html
> 
> Since GMP is not a compiler, target is not relevant here.

This very unfortunate terminology has, sadly, become the de facto
standard.  It is very confusing, but Wei has it right.

Ian.

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

[Xen-devel] Processed: Re: [Xen-users] Error compiling Xen in configuring stubdom/gmp with glibc-2.23 on Arch Linux

[xen]

Processing commands for x...@bugs.xenproject.org:

> close 53
Closing bug #53
> 
> thanks
Finished processing.

Modified/created Bugs:
 - 53: http://bugs.xenproject.org/xen/bug/53

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on 
reporting bugs
Contact xen-bugs-ow...@bugs.xenproject.org with any infrastructure issues

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

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: fix sed usage

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v2 for-4.8] tools/libacpi: fix sed usage"):
> Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
> that are not available on all the OSes supported by the Xen tools.
> 
> The '-i' option has slightly different semantics between GNU and BSD sed
> implementations, while on the GNU version the suffix is optional, on the BSD
> one it is not. Also BSD sed seems to have problems parsing the script
> itself, reporting "extra characters at the end of d command".
> 
> Fix those issues by using a temporary intermediate file, and replace the
> script with a simpler version that achieves the same purpose (removing the
> initial license header comment).

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] Don't clear HCR_VM bit when updating VTTBR.

[Steve Capper]

On Wed, Oct 19, 2016 at 12:59:45PM -0700, Stefano Stabellini wrote:
> On Mon, 10 Oct 2016, Jun Sun wrote:
> > Currently function p2m_restore_state() would clear HCR_VM bit, i.e.,
> > disabling stage2 translation, before updating VTTBR register. After
> > some research and talking to ARM support, I got confirmed that this is not
> > necessary. We are currently working on a new platform that would need this
> > to be removed.
> > 
> > The patch is tested on FVP foundation model.
> > 
> > Signed-off-by: Jun Sun 
> 
> Hello Jun,
> 
> thanks for the patch and sorry for the late reply. I would appreciate
> feedback from Julien, but he is current AFK.
> 
> Steve,
> can I have your Acked-by on this patch?
> 

Apologies for my very late reply on this.

I've taken a look and I think that this is okay, so please feel free to
add:
Acked-by: Steve Capper 

Cheers,
-- 
Steve

> 
> >  xen/arch/arm/p2m.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index cc5634b..e4991df 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -140,8 +140,6 @@ void p2m_restore_state(struct vcpu *n)
> >  return;
> >  
> >  hcr = READ_SYSREG(HCR_EL2);
> > -WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
> > -isb();
> >  
> >  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
> >  isb();
> > -- 
> > 2.7.4
> > 

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Wei Liu]

On Mon, Oct 31, 2016 at 11:22:02AM +0100, Samuel Thibault wrote:
> Ian Jackson, on Mon 31 Oct 2016 10:21:04 +, wrote:
> > Wei Liu writes ("[PATCH for-4.8] stubdom: make GMP aware that it's being 
> > cross-compiled"):
> > > Append --build and --host flags to GMP's configure script so that it
> > > knows it is being compiled for another architecture.
> > > 
> > > This should fix the issue that GMP doesn't compile with gcc 6, because
> > > configure script won't try to test the host environment anymore.
> > 
> > Acked-by: Ian Jackson 
> 
> Acked-by: Samuel Thibault 

Applied.

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

Re: [Xen-devel] [PATCH v2 1/7] xenstore: fix add_change_node()

[Wei Liu]

On Thu, Oct 27, 2016 at 11:15:24AM +0100, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:55:52AM +0200, Juergen Gross wrote:
> > add_change_node() in xenstored is used to add a modified node to the
> > list of changed nodes of one transaction. It is being called with the
> > recurse parameter set to true when removing a node in order to get
> > watches for children of the node fired at transaction end, too.
> > 
> > If, however, the node to be deleted had been modified in the same
> > transaction the recurse parameter of add_change_node() is lost as
> > an entry already in the list of the changed nodes won't be entered
> > again.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Wei Liu 
> 
> I think we should apply this to 4.8, too. I will wait a bit for
> different opinions.
> 
> (I've only looked at this patch in this series because I caught the
> "fix" in subject line)
> 
> > ---
> > Candidate for backport
> > ---
> >  tools/xenstore/xenstored_transaction.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/xenstore/xenstored_transaction.c 
> > b/tools/xenstore/xenstored_transaction.c
> > index 34720fa..3c0b8f7 100644
> > --- a/tools/xenstore/xenstored_transaction.c
> > +++ b/tools/xenstore/xenstored_transaction.c
> > @@ -103,8 +103,11 @@ void add_change_node(struct transaction *trans, const 
> > char *node, bool recurse)
> > }
> >  
> > list_for_each_entry(i, >changes, list)
> > -   if (streq(i->node, node))
> > +   if (streq(i->node, node)) {
> > +   if (recurse)
> > +   i->recurse = recurse;
> > return;
> > +   }
> 
> I would like to add {} around list_for_each_entry. No need to resend.
> 

Added pair of braces and applied.

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

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: fix sed usage

[Wei Liu]

On Mon, Oct 31, 2016 at 10:29:14AM +, Wei Liu wrote:
> On Mon, Oct 31, 2016 at 11:05:20AM +0100, Roger Pau Monne wrote:
> > Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
> > that are not available on all the OSes supported by the Xen tools.
> > 
> > The '-i' option has slightly different semantics between GNU and BSD sed
> > implementations, while on the GNU version the suffix is optional, on the BSD
> > one it is not. Also BSD sed seems to have problems parsing the script
> > itself, reporting "extra characters at the end of d command".
> > 
> > Fix those issues by using a temporary intermediate file, and replace the
> > script with a simpler version that achieves the same purpose (removing the
> > initial license header comment).
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Acked-by: Wei Liu 

Applied.

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

Re: [Xen-devel] [PATCH for-4.8 v2] stubdom: fix stubdom-vtpm build

[Wei Liu]

On Mon, Oct 31, 2016 at 10:27:55AM +, Wei Liu wrote:
> On Mon, Oct 31, 2016 at 10:04:18AM +0100, Juergen Gross wrote:
> > stubdom-vtpm needs gmp and expects it under
> > stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
> > it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64 at least in an
> > openSUSE environment.
> > 
> > Modify gmp configure parameters to explicitly specify --libdir.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Wei Liu 

Applied.

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Jan Beulich]

>>> On 31.10.16 at 11:14,  wrote:
> On Mon, Oct 31, 2016 at 02:57:54AM -0600, Jan Beulich wrote:
>> >>> On 29.10.16 at 19:22,  wrote:
>> > Append --build and --host flags to GMP's configure script so that it
>> > knows it is being compiled for another architecture.
>> 
>> Why --host and --build? Aiui,
>> - host is where the configure runs,
>> - build is where tool chain components being built are supposed to run,
>> - target is where the final binaries are intended to run.
> 
> I think you got them wrong, in particular host and build semantics.
> 
> build is where the build runs, host is where the resulting binary runs,
> target is where the output of the resulting binary runs (assuming the
> binary is compiler).
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifyi 
> ng-Target-Triplets.html
> 
> Since GMP is not a compiler, target is not relevant here.

Oh, indeed, I've been confused. Sorry for the noise.

Jan

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[Andrew Cooper]

On 31/10/16 10:31, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm"):
>> On 30/10/16 04:29, osstest service owner wrote:
>>>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
> ...
>> Where can I find the build logs for the bisection runs?  I am fairly
>> sure I have a newer version of Ocaml than comes by default in Debian,
>> and I wonder whether I have hit some version-dependent behaviour.
> Let me walk you through this.
>
> We'll follow links starting with, say, the "Last fail repro" url,
> above:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101803/
>
> Click on the test column heading to get to
>
> http://logs.test-lab.xenproject.org/osstest/logs/101803/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/info.html
>
> Scroll down and you'll see `Test control variables'.  Select the build
> of interest, which I think is `buildjob'.  (There are also
> `xenbuildjob' which is the hypervisor build, and `kernbuildjob' which
> is, as might be expected, the kernel.)  So click through to
> 101797.build-i386-xsm:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/info.html
>
> The main build log is that for the `xen-build' step:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/4.ts-xen-build-prep.log
>
> Finding out which ocaml was actually installed can sometimes be a
> little harder, because build host sharing means that the run of
> `host-build-prep' shown in that job might be a no-op, and there isn't
> an easy way to click through to the job that actually did the install
> (sorry).
>
> However, it's easy enough to know what ocaml was probably installed:
> looking at `Test control variables' in the build job, you see
> `all_host_suite' with value `jessie'.  Then go here
>
> https://www.debian.org/distrib/packages
>
> and in the `search package directories' enter `ocaml' (searching
> within `stable', since jessie is currently stable);
>
> https://packages.debian.org/search?keywords=ocaml=names=stable=all
>
> Results: 4.01.0-5.

Thankyou.  It turns out that I am using the same version of Ocaml.

However, looking at the build log, I think the fact that this is a 32bit
build of the binary might be the salient point.  Let me see if I can
rebuild oxenstored as 32bit.

~Andrew

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

Re: [Xen-devel] (no subject)

[Ian Jackson]

George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component.  And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done.  I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
> 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.

This kind of situation is not that uncommon.  For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.

(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)

Ian.

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm"):
> On 30/10/16 04:29, osstest service owner wrote:
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
...
> Where can I find the build logs for the bisection runs?  I am fairly
> sure I have a newer version of Ocaml than comes by default in Debian,
> and I wonder whether I have hit some version-dependent behaviour.

Let me walk you through this.

We'll follow links starting with, say, the "Last fail repro" url,
above:

http://logs.test-lab.xenproject.org/osstest/logs/101803/

Click on the test column heading to get to

http://logs.test-lab.xenproject.org/osstest/logs/101803/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/info.html

Scroll down and you'll see `Test control variables'.  Select the build
of interest, which I think is `buildjob'.  (There are also
`xenbuildjob' which is the hypervisor build, and `kernbuildjob' which
is, as might be expected, the kernel.)  So click through to
101797.build-i386-xsm:

http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/info.html

The main build log is that for the `xen-build' step:

http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/4.ts-xen-build-prep.log

Finding out which ocaml was actually installed can sometimes be a
little harder, because build host sharing means that the run of
`host-build-prep' shown in that job might be a no-op, and there isn't
an easy way to click through to the job that actually did the install
(sorry).

However, it's easy enough to know what ocaml was probably installed:
looking at `Test control variables' in the build job, you see
`all_host_suite' with value `jessie'.  Then go here

https://www.debian.org/distrib/packages

and in the `search package directories' enter `ocaml' (searching
within `stable', since jessie is currently stable);

https://packages.debian.org/search?keywords=ocaml=names=stable=all

Results: 4.01.0-5.

Ian.

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

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: fix sed usage

[Wei Liu]

On Mon, Oct 31, 2016 at 11:05:20AM +0100, Roger Pau Monne wrote:
> Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
> that are not available on all the OSes supported by the Xen tools.
> 
> The '-i' option has slightly different semantics between GNU and BSD sed
> implementations, while on the GNU version the suffix is optional, on the BSD
> one it is not. Also BSD sed seems to have problems parsing the script
> itself, reporting "extra characters at the end of d command".
> 
> Fix those issues by using a temporary intermediate file, and replace the
> script with a simpler version that achieves the same purpose (removing the
> initial license header comment).
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

> ---
> Cc: Boris Ostrovsky 
> Cc: Jan Beulich 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
> Changes since v1:
>  - Don't pipe awk output into sed, in order to prevent losing error status.
> ---
>  tools/libacpi/Makefile | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> index 18a5cd4..b79db47 100644
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -47,9 +47,11 @@ $(MK_DSDT): mk_dsdt.c
>  
>  ifeq ($(GPL),y)
>  $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
> gpl/mk_dsdt_gpl.sh $(MK_DSDT)
> - awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
> + # Remove last bracket
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@.1.$(TMP_SUFFIX)
>   # Strip license comment
> - sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
> + sed '1,/\*\//d' $@.1.$(TMP_SUFFIX) > $@.$(TMP_SUFFIX)
> + rm -f $@.1.$(TMP_SUFFIX)
>   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
>   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
>   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
> @@ -57,8 +59,11 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl 
> dsdt_acpi_info.asl gpl/mk_d
>  
>  # NB. awk invocation is a portable alternative to 'head -n -1'
>  $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl 
> gpl/mk_dsdt_gpl.sh $(MK_DSDT)
> - awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
> - sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
> + # Remove last bracket
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@.1.$(TMP_SUFFIX)
> + # Strip license comment
> + sed '1,/\*\//d' $@.1.$(TMP_SUFFIX) > $@.$(TMP_SUFFIX)
> + rm -f $@.1.$(TMP_SUFFIX)
>   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
>   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
>   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
> -- 
> 2.7.4 (Apple Git-66)
> 

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

Re: [Xen-devel] [PATCH for-4.8 v2] stubdom: fix stubdom-vtpm build

[Wei Liu]

On Mon, Oct 31, 2016 at 10:04:18AM +0100, Juergen Gross wrote:
> stubdom-vtpm needs gmp and expects it under
> stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
> it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64 at least in an
> openSUSE environment.
> 
> Modify gmp configure parameters to explicitly specify --libdir.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
> To be applied on top of Wei's patch to account for cross environment
> Backport candidate
> ---
>  stubdom/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index dd52121..571704d 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -171,7 +171,7 @@ gmp-$(XEN_TARGET_ARCH): gmp-$(GMP_VERSION).tar.bz2 
> $(NEWLIB_STAMPFILE)
>   rm $@ -rf || :
>   mv gmp-$(GMP_VERSION) $@
>   #patch -d $@ -p0 < gmp.patch
> - cd $@; CPPFLAGS="-isystem 
> $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
> CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
> --enable-static --disable-fft --without-readline 
> --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf --build=`gcc 
> -dumpmachine` --host=$(GNU_TARGET_ARCH)-xen-elf
> + cd $@; CPPFLAGS="-isystem 
> $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
> CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
> --enable-static --disable-fft --without-readline 
> --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf 
> --libdir=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib --build=`gcc 
> -dumpmachine` --host=$(GNU_TARGET_ARCH)-xen-elf
>   sed -i 's/#define HAVE_OBSTACK_VPRINTF 1/\/\/#define 
> HAVE_OBSTACK_VPRINTF 1/' $@/config.h
>   touch $@
>  
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Samuel Thibault]

Ian Jackson, on Mon 31 Oct 2016 10:21:04 +, wrote:
> Wei Liu writes ("[PATCH for-4.8] stubdom: make GMP aware that it's being 
> cross-compiled"):
> > Append --build and --host flags to GMP's configure script so that it
> > knows it is being compiled for another architecture.
> > 
> > This should fix the issue that GMP doesn't compile with gcc 6, because
> > configure script won't try to test the host environment anymore.
> 
> Acked-by: Ian Jackson 

Acked-by: Samuel Thibault 

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.8] stubdom: make GMP aware that it's being 
cross-compiled"):
> Append --build and --host flags to GMP's configure script so that it
> knows it is being compiled for another architecture.
> 
> This should fix the issue that GMP doesn't compile with gcc 6, because
> configure script won't try to test the host environment anymore.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Wei Liu]

On Mon, Oct 31, 2016 at 02:57:54AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 19:22,  wrote:
> > Append --build and --host flags to GMP's configure script so that it
> > knows it is being compiled for another architecture.
> 
> Why --host and --build? Aiui,
> - host is where the configure runs,
> - build is where tool chain components being built are supposed to run,
> - target is where the final binaries are intended to run.

I think you got them wrong, in particular host and build semantics.

build is where the build runs, host is where the resulting binary runs,
target is where the output of the resulting binary runs (assuming the
binary is compiler).

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html

Since GMP is not a compiler, target is not relevant here.

> 
> We're talking about a simple cross build here afaict, not a Canadian
> cross,

Correct, it's a simple cross build, not a Canadian cross.

The rest is moot because it is based on wrong assumption.

Wei.

> i.e. host == build, with only target being different, i.e. I'd
> assume you really want to specify --target (and leave host and build
> to be determined automatically), along the lines of e.g. a simple
> compiler cross build, which produces
> 
> S["target_os"]="linux-gnu"
> S["target_vendor"]="pc"
> S["target_cpu"]="x86_64"
> S["target"]="x86_64-pc-linux-gnu"
> 
> S["host_os"]="linux-gnu"
> S["host_vendor"]="pc"
> S["host_cpu"]="i686"
> S["host"]="i686-pc-linux-gnu"
> 
> S["build_os"]="linux-gnu"
> S["build_vendor"]="pc"
> S["build_cpu"]="i686"
> S["build"]="i686-pc-linux-gnu"
> 
> among its awk expression to perform substitution in various other
> files/scripts (except that in the stubdom case it would be target_os
> to be different from host_os/build_os, and - on a 64-bit system -
> target_cpu matching host_cpu/build_cpu).
> 
> Jan
> 

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

[Xen-devel] [PATCH v2 for-4.8] tools/libacpi: fix sed usage

[Roger Pau Monne]

Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
that are not available on all the OSes supported by the Xen tools.

The '-i' option has slightly different semantics between GNU and BSD sed
implementations, while on the GNU version the suffix is optional, on the BSD
one it is not. Also BSD sed seems to have problems parsing the script
itself, reporting "extra characters at the end of d command".

Fix those issues by using a temporary intermediate file, and replace the
script with a simpler version that achieves the same purpose (removing the
initial license header comment).

Signed-off-by: Roger Pau Monné 
---
Cc: Boris Ostrovsky 
Cc: Jan Beulich 
Cc: Ian Jackson 
Cc: Wei Liu 
---
Changes since v1:
 - Don't pipe awk output into sed, in order to prevent losing error status.
---
 tools/libacpi/Makefile | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 18a5cd4..b79db47 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -47,9 +47,11 @@ $(MK_DSDT): mk_dsdt.c
 
 ifeq ($(GPL),y)
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   # Remove last bracket
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.1.$(TMP_SUFFIX)
# Strip license comment
-   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   sed '1,/\*\//d' $@.1.$(TMP_SUFFIX) > $@.$(TMP_SUFFIX)
+   rm -f $@.1.$(TMP_SUFFIX)
$(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
@@ -57,8 +59,11 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl 
dsdt_acpi_info.asl gpl/mk_d
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
-   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   # Remove last bracket
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.1.$(TMP_SUFFIX)
+   # Strip license comment
+   sed '1,/\*\//d' $@.1.$(TMP_SUFFIX) > $@.$(TMP_SUFFIX)
+   rm -f $@.1.$(TMP_SUFFIX)
$(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
-- 
2.7.4 (Apple Git-66)


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a62511bf14971ff581212decbbf57fc11b967840
baseline version:
 xen  35ac0c08178ac15565b32ca56b00fa5414f1d3b1

Last test of basis   101752  2016-10-28 12:02:29 Z2 days
Testing same since   101824  2016-10-31 08:02:25 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a62511bf14971ff581212decbbf57fc11b967840
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
a62511bf14971ff581212decbbf57fc11b967840
+ branch=xen-unstable-smoke
+ revision=a62511bf14971ff581212decbbf57fc11b967840
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xa62511bf14971ff581212decbbf57fc11b967840 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [Apply for Xen Outreach Prj] QEMU analysis

[Roger Pau Monné]

On Fri, Oct 28, 2016 at 10:28:38PM -0500, Lee Naroah wrote:
> Hi Mr. Monné,
> 
> My name is Haoran Li.  I am a second year Ph. D student in Computer
> Science.  My research interest is Real-Time Virtualization.  I wonder to
> know some more details of the project,  "*QEMU xen-blkback performance
> analysis and improvements*", as shown in
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects.

Hello,

Part of this project has already been completed, see:

http://git.qemu.org/?p=qemu.git;a=commit;h=b6eb9b45f7307638ff166401721ae6d0401e1d67

(I've also updated the projects page in order to reflect this)

So you will have choose between one of the two remaining proposed 
improvements. It's still not clear whether they will provide a performance 
improvement over the current code, so some analysis will be needed in order 
to decide which one is better. Also, AFAICT the deadline for 
Outreachy applications is already over (it was the 17th of October) [0].

Roger.

[0] https://wiki.gnome.org/Outreachy

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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Juergen Gross]

On 29/10/16 19:22, Wei Liu wrote:
> Append --build and --host flags to GMP's configure script so that it
> knows it is being compiled for another architecture.
> 
> This should fix the issue that GMP doesn't compile with gcc 6, because
> configure script won't try to test the host environment anymore.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Juergen Gross 

Juergen

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

[Xen-devel] [PATCH for-4.8 v2] stubdom: fix stubdom-vtpm build

[Juergen Gross]

stubdom-vtpm needs gmp and expects it under
stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64 at least in an
openSUSE environment.

Modify gmp configure parameters to explicitly specify --libdir.

Signed-off-by: Juergen Gross 
---
To be applied on top of Wei's patch to account for cross environment
Backport candidate
---
 stubdom/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index dd52121..571704d 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -171,7 +171,7 @@ gmp-$(XEN_TARGET_ARCH): gmp-$(GMP_VERSION).tar.bz2 
$(NEWLIB_STAMPFILE)
rm $@ -rf || :
mv gmp-$(GMP_VERSION) $@
#patch -d $@ -p0 < gmp.patch
-   cd $@; CPPFLAGS="-isystem 
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
--enable-static --disable-fft --without-readline 
--prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf --build=`gcc -dumpmachine` 
--host=$(GNU_TARGET_ARCH)-xen-elf
+   cd $@; CPPFLAGS="-isystem 
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
--enable-static --disable-fft --without-readline 
--prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf 
--libdir=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib --build=`gcc 
-dumpmachine` --host=$(GNU_TARGET_ARCH)-xen-elf
sed -i 's/#define HAVE_OBSTACK_VPRINTF 1/\/\/#define 
HAVE_OBSTACK_VPRINTF 1/' $@/config.h
touch $@
 
-- 
2.6.6


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

Re: [Xen-devel] [PATCH for-4.8] stubdom: make GMP aware that it's being cross-compiled

[Jan Beulich]

>>> On 29.10.16 at 19:22,  wrote:
> Append --build and --host flags to GMP's configure script so that it
> knows it is being compiled for another architecture.

Why --host and --build? Aiui,
- host is where the configure runs,
- build is where tool chain components being built are supposed to run,
- target is where the final binaries are intended to run.

We're talking about a simple cross build here afaict, not a Canadian
cross, i.e. host == build, with only target being different, i.e. I'd
assume you really want to specify --target (and leave host and build
to be determined automatically), along the lines of e.g. a simple
compiler cross build, which produces

S["target_os"]="linux-gnu"
S["target_vendor"]="pc"
S["target_cpu"]="x86_64"
S["target"]="x86_64-pc-linux-gnu"

S["host_os"]="linux-gnu"
S["host_vendor"]="pc"
S["host_cpu"]="i686"
S["host"]="i686-pc-linux-gnu"

S["build_os"]="linux-gnu"
S["build_vendor"]="pc"
S["build_cpu"]="i686"
S["build"]="i686-pc-linux-gnu"

among its awk expression to perform substitution in various other
files/scripts (except that in the stubdom case it would be target_os
to be different from host_os/build_os, and - on a 64-bit system -
target_cpu matching host_cpu/build_cpu).

Jan

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

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[Jan Beulich]

>>> On 31.10.16 at 09:28,  wrote:
>> >  ref = gnttab_claim_grant_reference(>gref_rx_head);
>> > -BUG_ON((signed short)ref < 0);
>> > +WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
> 
>> You really need to cast to plain (or signed) long here - casting to
>> unsigned long will work only in 32-bit configurations, as otherwise
>> you lose the sign of the value.
> 
> Seems the sign of value would not be lost since casting to unsigned long will
> use signed extension. Is my understanding wrong or did I miss anything?

ref being of type grant_ref_t, which is a typedef of uint32_t, I can't
see how the conversion to unsigned long would be using sign
extension. Did you look at the generated code? (If ref was of a signed
type, I don't think the original author would have found a need to cast
it to signed short.)

> I have verified this with both sample userspace helloworld program
> and a kernel module.

Are you saying you did see the warning trigger with a 64-bit kernel?
I'd be very surprised, but of course I may be overlooking something.

Jan

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

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[Dongli Zhang]

> >  ref = gnttab_claim_grant_reference(>gref_rx_head);
> > -BUG_ON((signed short)ref < 0);
> > +WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));

> You really need to cast to plain (or signed) long here - casting to
> unsigned long will work only in 32-bit configurations, as otherwise
> you lose the sign of the value.

Seems the sign of value would not be lost since casting to unsigned long will
use signed extension. Is my understanding wrong or did I miss anything? I have
verified this with both sample userspace helloworld program and a kernel
module.

> And then just issuing a warning here is insufficient, I think: Either
> you follow David's line of thought assuming that no failure here is

Keeping this can help debug xen-netfront.

> possible at all (in which case the BUG_ON() can be ditched without
> replacement), or you follow your original one (which matches mine)
> that we can't exclude an error here because of a bug elsewhere,
> in which case this either needs to stay BUG_ON() or should be
> followed by some form of bailing out (so that the bad ref won't get
> stored, preventing its later use from causing further damage).

The reason I use warning instead BUG_ON is that Linus suggested use
WARN_ON_ONCE() in a previous email:
http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html

I would change to BUG_ON() if it is OK to you.

Thank you very much!

Dongli Zhang 


- Original Message -
From: jbeul...@suse.com
To: dongli.zh...@oracle.com
Cc: david.vra...@citrix.com, xen-de...@lists.xenproject.org, 
boris.ostrov...@oracle.com, jgr...@suse.com, linux-ker...@vger.kernel.org, 
net...@vger.kernel.org
Sent: Monday, October 31, 2016 3:48:03 PM GMT +08:00 Beijing / Chongqing / Hong 
Kong / Urumqi
Subject: Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table 
reference to signed short

>>> On 31.10.16 at 06:38,  wrote:
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
> *queue)
>   queue->rx_skbs[id] = skb;
>  
>   ref = gnttab_claim_grant_reference(>gref_rx_head);
> - BUG_ON((signed short)ref < 0);
> + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));

You really need to cast to plain (or signed) long here - casting to
unsigned long will work only in 32-bit configurations, as otherwise
you lose the sign of the value.

And then just issuing a warning here is insufficient, I think: Either
you follow David's line of thought assuming that no failure here is
possible at all (in which case the BUG_ON() can be ditched without
replacement), or you follow your original one (which matches mine)
that we can't exclude an error here because of a bug elsewhere,
in which case this either needs to stay BUG_ON() or should be
followed by some form of bailing out (so that the bad ref won't get
stored, preventing its later use from causing further damage).

Jan

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

Re: [Xen-devel] [PATCH] stubdom: fix stubdom-vtpm build

[Juergen Gross]

On 31/10/16 08:55, Jan Beulich wrote:
 On 28.10.16 at 17:10,  wrote:
>> stubdom-vtpm needs gmp and expects it under
>> stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
>> it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64
> 
> Are you sure this is universal, rather dependent upon some
> (possibly even host) configuration item? I think that some distros
> have switched to (or have always used) /lib as the main library
> directory for x86-64, while others (like SUSE's) stick to the
> originally mandated /lib64. Over the years I have found quite a
> few projects where, in order to become consistent with SUSE's
> model, I had to override the global default of /lib with /lib64 just
> for x86-64 (but not for e.g. ia64).

No, I don't think it is universal. This is the reason I did the move
of the file only in case it is to be found under lib64 but not under
lib.

I've tested the build to break with plain

./configure

and with

./configure --prefix=/usr --libdir=/usr/lib64

which I use normally to match my SUSE environment.

OTOH looking at Wei's recent patch to modify gmp's configure to
specify cross compilation I now believe the correct answer to my
problem is to add

--libdir=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib

to the configure statement of gmp. I'll send V2 of the patch.


Juergen


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 92ec8772df33f3c758763adcaf42fd42c8da812c
baseline version:
 ovmf d115b80b7d31f0c2b5c7438de5258a6d263c4de2

Last test of basis67965  2016-10-31 03:20:04 Z0 days
Testing same since67966  2016-10-31 05:46:11 Z0 days1 attempts


People who touched revisions under test:
  Zhang Lubo 

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



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

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

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


Push not applicable.


commit 92ec8772df33f3c758763adcaf42fd42c8da812c
Author: Zhang Lubo 
Date:   Thu Oct 27 15:36:00 2016 +0800

NetworkPkg: Add error handling logic when using AllocateZeroPool

Add error handling logic if failed to apply new memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Reviewed-By: Wu Jiaxin 
Reviewed-By: Fu Siyuan 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2 10 guest-startfail in 101792 pass in 101818
 test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail in 101792 pass in 
101818
 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
in 101810 pass in 101792
 test-armhf-armhf-libvirt   7 host-ping-check-xen fail in 101810 pass in 101818
 test-amd64-i386-xl-raw   10 guest-start  fail in 101810 pass in 101818
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 
guest-start/debianhvm.repeat fail in 101810 pass in 101818
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat 
fail in 101810 pass in 101818
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
in 101810 pass in 101818
 test-amd64-i386-xl-raw   18 guest-start/debian.repeat  fail pass in 101792
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail pass 
in 101792
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
101810
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat 
fail pass in 101810
 test-amd64-amd64-libvirt-vhd  9 debian-di-install  fail pass in 101810
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat  fail pass in 101810

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 101673
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101673
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101673
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101673
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101673
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101673
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101673
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101673
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101673
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101673

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