[Xen-devel] [linux-4.1 test] 63341: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux10f9e3bce7f3ab7ab4d09a9b78c7208c9a1455f7
baseline version:
 linux205a8514e63a221c3a5071f27521013444e43e5f

Last test of basis63223  2015-10-22 22:19:07 Z6 days
Testing same since63326  2015-10-27 01:12:52 Z2 days2 attempts


People who touched revisions under test:
  "J. Bruce Fields" 
  Aaron Conole 
  Alex Deucher 
  Alexander Couzens 
  Alexei Starovoitov 
  Andrew Morton 
  Andrey Vagin 
  Arad, Ronen 
  Ben Hutchings 
  Ben Skeggs 
  Catalin Marinas 
  Chris Mason 
  Christoph Hellwig 
  Chuck Lever 
  Cong Wang 
  Cong Wang 
  Daniel Borkmann 
  Daniel Vetter 
  Daniel Vetter 
  Dann Frazier 
  Dave Airlie 
  Dave Airlie 
  Dave Kleikamp 
  David S. Miller 
  David Sterba 
  Eric Dumazet 
  Frederic Weisbecker 
  Ganapatrao Kulkarni 
  Greg Kroah-Hartman 
  Guillaume Nault 
  Herbert Xu 
  Ilya Dryomov 
  Ingo Molnar 
  Ivan Mikhaylov 
  J. Bruce Fields 
  James Chapman 
  Javier Martinez Canillas 
  Jeff Layton 
  Jens Axboe 
  Joe Perches 
  Jon Maloy 
  Jon Paul Maloy 
  Konstantin Khlebnikov 
  Krzysztof Kozlowski 
  Kukjin Kim 
  Lee Jones 
  Linus Torvalds 
  Linus Walleij 
  Michal Hocko 
  Mika Westerberg 
  Mike Galbraith 
  Mike Snitzer 
  Oleksii Berezhniak 
  Pavel Roskin 
  Peter Zijlstra (Intel) 
  Pravin B Shelar 
  Ronen Arad 
  Russell King 
  Shaohua Li 
  Steve Capper 
  Steve Wise 
  Tejun Heo 
  Tom Herbert 
  Uwe Kleine-König 
  WANG Cong 
  Will Deacon 
  Wolfram Sang 
  Wolfram Sang 
  Ying Xue 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf ae658d9163afd6053db7d37d46f54388e33a0052
baseline version:
 ovmf f40577c3563fcad7fc512617925d0574a7c64e2f

Last test of basis63328  2015-10-27 03:40:09 Z2 days
Testing same since63342  2015-10-28 06:21:47 Z0 days1 attempts


People who touched revisions under test:
  "Yao, Jiewen" 
  Dandan Bi 
  Eric Dong 
  Haojian Zhuang 
  Michael Kinney 
  Star Zeng 
  Tim He 
  Yao, Jiewen 
  Yonghong Zhu 

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=ae658d9163afd6053db7d37d46f54388e33a0052
+ . ./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 
ae658d9163afd6053db7d37d46f54388e33a0052
+ branch=ovmf
+ revision=ae658d9163afd6053db7d37d46f54388e33a0052
+ . ./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.6-testing
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkerne

Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)

[Fu Wei]

Hi Stefano,

I have tried my grub on Foundation model, but I did not get this
error, I guess that is the UEFI problem ?

On 1 October 2015 at 00:00, Stefano Stabellini
 wrote:
> Hi Fu,
>
> I backported your patches to the CentOS aarch64 grub2 rpm.  I am testing
> it on X-Gene with EFI firmware. It works fine when booting Xen, but
> booting native kernels (no Xen) doesn't work anymore. Grub prints
>
> error: out of memory.
>
> Press any key to continue...
>
> grub is still able to continue and load Linux, but then the kernel fails
> to boot with "Cannot open root device", even though the grub config is
> still same as before and the rootfs (which is xfs) hasn't changed.
> Reverting the patches solved the problem.
>
> Do you have any ideas on what is causing the issue? Maybe the initramfs
> hasn't been properly loaded?
>
>
> Thanks,
>
> Stefano
>
>
> On Tue, 8 Sep 2015, Fu Wei wrote:
>> Hi Vladimir,
>>
>> Do you have any suggestion on this patchset?
>> Do I need to improve anything?
>>
>> Great thanks for your help.
>>
>> On 4 August 2015 at 16:34, Fu Wei  wrote:
>> > Hi Vladimir,
>> >
>> > this patchset follows all your comment of v2 patchset.
>> > Do you have any suggestion on this patchset?
>> >
>> > Great thanks for your help.
>> >
>> >
>> > On 23 July 2015 at 13:16,   wrote:
>> >> From: Fu Wei 
>> >>
>> >>   - This adds support for the Xen boot on ARM specification for arm64.
>> >>
>> >>   - Add and export some accessor functions of "loaded" flag and
>> >> grub_linux_get_fdt function in include/grub/arm64/linux.h for xen 
>> >> boot.
>> >>
>> >>   - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm
>> >> to load different binaries for xen boot.
>> >> Introduce xen_module to load common or custom module for xen boot.
>> >>
>> >>   - This Xen boot support is a separated  module for aarch64,
>> >> but reuse the existing code of devicetree in linux module.
>> >>
>> >>   - Add the support of xen_hypervisor, xen_linux and xen_initrd
>> >> in util/grub.d/20_linux_xen.in
>> >>
>> >>   - Add the introduction of all xen boot commands in docs/grub.texi
>> >>
>> >>   - The example of this support is > >> the Foundation FVP model>
>> >> 
>> >> https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB
>> >>
>> >> Changelog:
>> >> v3: create separate module for xen boot: xen_boot
>> >> create separate commands for different types of module
>> >> delete order-dependent for commands of xen module
>> >> simplify the code
>> >>
>> >> v2: remove the patches which have been accepted.
>> >> according to Vladimir's suggestion, change the command manes
>> >> and relevant code:
>> >> multiboot-->xen_hypervisor
>> >> module-->xen_module
>> >> improve the option parsing support for xen_hypervisor/xen_module 
>> >> commands.
>> >> add a patch for adding xen_hypervisor/xen_module support
>> >> in util/grub.d/20_linux_xen.in.
>> >> update docs/grub.texi patch for the new command names.
>> >>
>> >> v1: The first version upstream patchset to grub-devel mailing list
>> >>
>> >>
>> >> Fu Wei (4):
>> >>   arm64: Add and export some accessor functions for xen boot
>> >>   arm64: Add xen_boot module file
>> >>   * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64
>> >>   arm64: Add the introduction of xen boot commands in docs/grub.texi
>> >>
>> >>  docs/grub.texi|  56 
>> >>  grub-core/Makefile.core.def   |   7 +
>> >>  grub-core/loader/arm64/linux.c|  13 +
>> >>  grub-core/loader/arm64/xen_boot.c | 685 
>> >> ++
>> >>  include/grub/arm64/linux.h|   6 +-
>> >>  util/grub.d/20_linux_xen.in   |  16 +-
>> >>  6 files changed, 779 insertions(+), 4 deletions(-)
>> >>  create mode 100644 grub-core/loader/arm64/xen_boot.c
>> >>
>> >> --
>> >> 1.8.3.1
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Fu Wei
>> > Software Engineer
>> > Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
>> > Ph: +86 21 61221326(direct)
>> > Ph: +86 186 2020 4684 (mobile)
>> > Room 1512, Regus One Corporate Avenue,Level 15,
>> > One Corporate Avenue,222 Hubin Road,Huangpu District,
>> > Shanghai,China 200021
>>
>>
>>
>> --
>> Best regards,
>>
>> Fu Wei
>> Software Engineer
>> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
>> Ph: +86 21 61221326(direct)
>> Ph: +86 186 2020 4684 (mobile)
>> Room 1512, Regus One Corporate Avenue,Level 15,
>> One Corporate Avenue,222 Hubin Road,Huangpu District,
>> Shanghai,China 200021
>>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

[Xen-devel] [linux-next test] 63344: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-build fail REGR. vs. 63240
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 63240
 build-amd64   5 xen-build fail REGR. vs. 63240
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 63240
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 63240

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

Re: [Xen-devel] [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe

[Hu, Robert]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson 
> Subject: [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe
> 
> From: Robert Ho 
> 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 
> ---
> v14: ts-nested-setup command line syntax updated.
> ---
>  sg-run-job |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/sg-run-job b/sg-run-job
> index 8174ef7..6b59ab3 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -348,6 +348,16 @@ proc run-job/test-pair-oneway {} {
>  run-ts . =  ts-guest-stop  dst_host
> + debian
>  }
> 
> +proc need-hosts/test-nested {} {return host}
> +proc run-job/test-nested {} {
> +run-ts . = ts-debian-hvm-install + host l1
> +run-ts . = ts-nested-setup + --define l1=host:l1
> +nested-layer-descend l1
> +run-ts . = ts-debian-hvm-install l1 l2
> +run-ts . = ts-guest-stop l1 l2
> +run-ts . = ts-guest-destroy + host l1
> +}
> +
[Hu, Robert] 

Not sure if rooted to this patch or patch 21 or 22, current test steps will
be

[root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy 
test-amd64-amd64-qemuu-nested |grep testid
Could not open a connection to your authentication agent.
WARNING: Unable to access ssh-agent. Some tests may fail
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 1 
testid build-check(1) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 2 
testid hosts-allocate ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 3 
testid host-install(3) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 4 
testid host-ping-check-native ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 5 
testid xen-install ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 6 
testid xen-boot ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 7 
testid host-ping-check-xen ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 8 
testid leak-check/basis(8) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 9 
testid debian-hvm-install ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 10 
testid nested-setup ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 11 
testid host-ping-check-native/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 12 
testid xen-install/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 13 
testid xen-boot/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 14 
testid host-ping-check-xen/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 15 
testid leak-check/basis/l1(15) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 16 
testid debian-hvm-install/l1/l2 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 17 
testid guest-stop/l1/l2 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 18 
testid guest-destroy ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 19 
testid leak-check/check/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 20 
testid capture-logs/l1(20) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 21 
testid final-poweroff/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 22 
testid leak-check/check ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 23 
testid capture-logs(23) ==
standalone.test-amd64-amd64-qemuu-nested status = pass

Note step 18 destroies l1, while step 19 and step 20 will try to leak check and 
capture log in l1.
I'm not quite understand these tcl part, any fix suggestions?

>  proc test-guest-migr {g} {
>  set to_reap [spawn-ts . = ts-migrate-support-check + host $g 1]
>  set can_migrate [reap-ts $to_reap]
> --
> 1.7.10.4


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

Re: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Thursday, October 29, 2015 12:37 AM
> To: Jan Beulich ; Wu, Feng 
> Cc: Tian, Kevin ; Keir Fraser ;
> GeorgeDunlap ; Andrew Cooper
> ; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Wed, 2015-10-28 at 03:03 -0600, Jan Beulich wrote:
> > > > > On 28.10.15 at 03:58,  wrote:
> 
> > > We still call arch_vcpu_block() in vcpu_block(), but we don't need
> > > to
> > > call arch_vcpu_block_cancel(v) when local_events_need_delivery()
> > > returns true. Then before VM-Entry, we can check if 'NV' field is
> > > ' pi_wakeup_vector', if it is, we change the PI status and remove
> > > it from the blocking list.
> > >
> > > Jan, if #2 is what you mean, I think it worth a try. If I don't
> > > understand
> > > your comments correctly, could you please elaborate it more? Thanks
> > > a lot!
> >
> > Ideally we'd avoid both arch_vcpu_*() calls by doing what is needed
> > in arch code (e.g. the VM entry path).
> >
> +1
> 
> > If only avoiding the cancel
> > hook is reasonably possible this way, then so be it - still better to
> > have just one hook here than having two.
> >
> +1 again
> 
> As an aside, I've spoked with some ARM people, the context being that
> they will get to implement a similar feature in the nearish future.
> 
> They said that, although they can't be sure, they don't think they'll
> be interested in arch hooks in the scheduling code and that, actually,
> having them risk being more harmful than helpful.
> 
> Of course, that does not mean that we shouldn't add them for the sake
> of this patch, if we can't avoid doing that. But if we can avoid them,
> that is perhaps one more reason for doing things that way.

Jan & Dario, thanks a lot for you guys' input. If you agree, I will remove
the arch_vcpu_block_cancel() and maybe arch_vcpu_wake_prepare()
as well, and implement the logic before VM-entry in V9, the patch will
be coming soon. Thanks again!

Thanks,
Feng 

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

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

Re: [Xen-devel] OSSTest nested patch PART2 -- L1 host has no 'Suite' property

[Hu, Robert]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:58 PM
> To: Hu, Robert 
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: Re: OSSTest nested patch PART2 -- L1 host has no 'Suite' property
> 
> Hu, Robert writes ("OSSTest nested patch PART2 -- L1 host has no 'Suite'
> property"):
> > Now the patch has been refined to get whole
> 'test-amd64-amd64-qemuu-nested' pass.
> 
> How exciting :-).
> 
> > But still one trivial issue I observed in the test log: L1 host has no 
> > 'Suite'
> property.
> > Any suggestions to improve this?
> 
> Two questions:
> 
> 1. I think this (missing suite) probably ought to be fatal.  Which is
> the first ts-* script which complains about it ?
[Hu, Robert] 

ts-xen-install l1

> 
> 2. In general the suite runvars are set by make-flight.  So I think
> your patch to make-flight needs adjusting.  TBH I think the suite
> should be set in do_hvm_debian_test_one for all Debian HVM tests,
> even though maybe nothing uses it now.
[Hu, Robert] 

In selecthost(),

if (defined $job) {
$ho->{Suite} = get_runvar_default("${ident}_suite",$job,
  $c{DebianSuite});
}

by default shall be the config file containing value, which I absolutely have
set.
The odd thing shall be $job is not defined. Any case possible?
Maybe this only happens in my debugging steps, in whole job running, it
probably would disappear.

> 
> Thanks,
> Ian.

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

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

[osstest service owner]

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

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 13 guest-localmigrate 
fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux23d88271b4f97f66de521ac9b2c1471e6311cf26
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  112 days
Failing since 59348  2015-07-10 04:24:05 Z  111 days   69 attempts
Testing same since63339  2015-10-28 03:14:01 Z1 days1 attempts


2483 people touched revisions under test,
not listing them all

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 63294 pass in 63338
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 
63338
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 
63338
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 63310 pass in 63338
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 63310 pass in 63338
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63310 pass in 63338
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 
63338
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63324 pass in 63338
 test-amd64-i386-xl-raw3 host-install(3)  broken in 63324 pass in 63338
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 
pass in 63338
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 
63338
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 63324 pass in 63338
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63310 pass in 63294
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
63228
 test-amd64-amd64-xl-rtds  6 xen-bootfail pass in 63228
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail pass in 63294
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63310
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 63310
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 63310
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail pass in 63310
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail pass in 63310
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 63324

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63228 blocked in 62277
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63324 like 62277
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62277
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62277

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 63228 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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux3edd6224c2a677bb59efe0b083a51fc2b3b5c64

Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)

[Fu Wei]

Hi Stefano,

Sorry for late response, I will try to test my latest patch ASAP. but
I don't see this problem before.
will let you know the result , thanks for your testing

On 2 October 2015 at 00:19, Stefano Stabellini
 wrote:
> On Wed, 30 Sep 2015, Stefano Stabellini wrote:
>> Hi Fu,
>>
>> I backported your patches to the CentOS aarch64 grub2 rpm.  I am testing
>> it on X-Gene with EFI firmware. It works fine when booting Xen, but
>> booting native kernels (no Xen) doesn't work anymore. Grub prints
>>
>> error: out of memory.
>>
>> Press any key to continue...
>>
>> grub is still able to continue and load Linux, but then the kernel fails
>> to boot with "Cannot open root device", even though the grub config is
>> still same as before and the rootfs (which is xfs) hasn't changed.
>> Reverting the patches solved the problem.
>>
>> Do you have any ideas on what is causing the issue? Maybe the initramfs
>> hasn't been properly loaded?
>
> It looks like the following chunk of commit
> f8451af8251a3866cb8b7307b9917dd5d34fbd0a "arm64: Export useful functions
> from linux.c" causes troubles:
>
>
> diff --git a/grub-core/loader/linux.c b/grub-core/loader/linux.c
> index 117232f..a63a11a 100644
> --- a/grub-core/loader/linux.c
> +++ b/grub-core/loader/linux.c
> @@ -205,7 +205,8 @@ grub_initrd_init (int argc, char *argv[],
>initrd_ctx->nfiles++;
>initrd_ctx->components[i].size
> = grub_file_size (initrd_ctx->components[i].file);
> -  initrd_ctx->size += ALIGN_UP (initrd_ctx->components[i].size, 4);
> +  if (argc != 1)
> +   initrd_ctx->size += ALIGN_UP (initrd_ctx->components[i].size, 4);
>  }
>
>if (newc)
>
>
> Simply removing this change seems to fix the issue and Xen still boots
> fine.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

[Xen-devel] [PATCH] blkif.h: document blkif multi-queue/ring extension

[Bob Liu]

Document the multi-queue/ring feature in terms of XenStore keys to be written
by the backend and by the frontend.

Signed-off-by: Bob Liu 
---
 xen/include/public/io/blkif.h |   48 +
 1 file changed, 48 insertions(+)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 8f0f9a6..f7823bb 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -394,6 +394,54 @@
  */
 
 /*
+ * Multiple hardware queues/rings:
+ * If supported, the backend will write the key "multi-queue-max-queues" to
+ * the directory for that vbd, and set its value to the maximum supported
+ * number of queues.
+ * Frontends that are aware of this feature and wish to use it can write the
+ * key "multi-queue-num-queues" with the number they wish to use, which must be
+ * greater than zero, and no more than the value reported by the backend in
+ * "multi-queue-max-queues".
+ *
+ * For frontends requesting just one queue, the usual event-channel and
+ * ring-ref keys are written as before, simplifying the backend processing
+ * to avoid distinguishing between a frontend that doesn't understand the
+ * multi-queue feature, and one that does, but requested only one queue.
+ *
+ * Frontends requesting two or more queues must not write the toplevel
+ * event-channel and ring-ref keys, instead writing those keys under sub-keys
+ * having the name "queue-N" where N is the integer ID of the queue/ring for
+ * which those keys belong. Queues are indexed from zero.
+ * For example, a frontend with two queues must write the following set of
+ * queue-related keys:
+ *
+ * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
+ * /local/domain/1/device/vbd/0/queue-0 = ""
+ * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
+ * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
+ * /local/domain/1/device/vbd/0/queue-1 = ""
+ * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
+ * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
+ *
+ * It is also possible to use multiple queues/rings together with
+ * feature multi-page ring buffer.
+ * For example, a frontend requests two queues/rings and the size of each ring
+ * buffer is two pages must write the following set of related keys:
+ *
+ * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
+ * /local/domain/1/device/vbd/0/ring-page-order = "1"
+ * /local/domain/1/device/vbd/0/queue-0 = ""
+ * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = ""
+ * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = ""
+ * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
+ * /local/domain/1/device/vbd/0/queue-1 = ""
+ * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = ""
+ * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = ""
+ * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
+ *
+ */
+
+/*
  * STATE DIAGRAMS
  *
  *
-- 
1.7.10.4


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

Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure [and 1 more messages]

[Hu, Robert]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:53 PM
> To: Hu, Robert 
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: RE: OSSTest nested patch PART2 -- L2 installation failure [and 1 more
> messages]
> 
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Now another issue: after attach lvm to L1, cannot see it inside.
> > vgdisplay shows nothing.
> >
> > My manual test like this:
> > xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
> >
> > xl block-list can see it, while inside L1 cannot.
> 
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Tried:
> > After attach, in L1 cannot see the additional disk, if L1 is nested
> > Xen. After reboot, can see it.  If L1 is booted as normal guest, it
> > can see the additional disk at once, after attachment.
> 
> So your two tests are:
> 
> case A case B
> 
>1.   boot L1 nestedhvm=1
> nestedhvm=0
> without additional disk
> 
>2.   xl block-attach in L0
> 
>3.   xl block-list in L0 shows it
> 
>4.   ??? in L1 to look for disk  not visiblevisible
> 
>5.   reboot L1 with same nestedhvm
> setting
> 
>6.   ??? in L1 to look for disk  visiblevisible
> 
> Is that right ?
[Hu, Robert] 

No. Both 2 cases with nestedhvm=1, just different boot entries I select:
one is boot directly from Dom0 kernel, the other from Xen.

> 
> I think this may be because the L1 booted with nestedhvm=1 gets its
> disks solely via the emulated IDE controller supplied by qemu in L0.
> And that IDE controller does not support hotplug.
> 
> (I don't quite understand why merely setting nestedhvm=1 stops the L1
> from finding its Xen platform PCI device and initialising itself as a
> Xen guest in a way that would prevent it also being a host.  I'm not
> sure this is relevant, though.)
> 
> Ian.

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

[Xen-devel] [libvirt test] 63340: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95
baseline version:
 libvirt  e739d956e850093b05ea7d95f76ada49bd2ebfb5

Last test of basis63231  2015-10-23 04:21:36 Z5 days
Testing same since63340  2015-10-28 04:19:47 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Luyao Huang 
  Michal Privoznik 
  Pavel Hrdina 
  Pino Toscano 
  Roman Bogorodskiy 
  Wido den Hollander 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=3c7590e0a435d833895fc7b5be489e53e223ad95
+ . ./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 libvirt 
3c7590e0a435d833895fc7b5be489e53e223ad95
+ branch=libvirt
+ revision=3c7590e0a435d833895fc7b5be489e53e223ad95
+ . ./cri-lock-repos
++ . ./cri-common
+

Re: [Xen-devel] [PATCH] x86/vmx: Improvements to vmentry failure handling

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, October 24, 2015 1:53 AM
> 
> Combine the almost identical vm_launch_fail() and vm_resume_fail() into
> a single vmx_vmentry_failure().
> 
> Re-save all GPRs so that domain_crash() prints the real register values,
> rather than the active stack of the vmx_vmentry_failure() callpath.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH] use clear_domain_page() instead of open coding it

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, October 19, 2015 10:52 PM
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCHv1 2/2] passthrough: improve locking when iterating over interrupts bound to VMs

[Konrad Rzeszutek Wilk]

On Fri, Oct 23, 2015 at 12:05:22PM +0100, David Vrabel wrote:
> radix_tree_gang_lookup() only requires a RCU read lock, not the
> per-domain event_lock.

Don't you need to make some form of 'spin_lock_init' call?

> 
> Introduce a new RCU read lock and take the per-interrupt lock before
> calling the callback instead.
> 
> This eliminates all contention on the event_lock when injecting
> interrupts from passthrough devices.

This pt_pirq_iterate is called from:

hvm_migrate_pirqs (which only uses irq_desc lock) - so you could
also drop the event_lock there.

pt_irq_time_out (which  is only called for legacy interrupts and
only at 8ms). Uses event_lock.

pci_clean_dpci_irqs (during domain shutdown, uses event_lock).

Also should this rcu lock be put in 'pirq_guest_unmask' (which oddly
enough has no lock?!)?

Reading the radix-tree.h t says: "
..
The notable exceptions to this rule are the following functions:
 ...
  radix_tree_gang_lookup

The first 7 functions are able to be called locklessly, using RCU. The
caller must ensure calls to these functions are made within rcu_read_lock()
regions."

Great, so that is what your patch does. Thought it would imply that
everybody using radix_tree_gang_lookup on pirq_tree needs to use RCU?

> 
> Signed-off-by: David Vrabel 
> ---
>  xen/drivers/passthrough/io.c | 10 +++---
>  xen/include/xen/sched.h  |  1 +
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 7c86c20..9b51ef0 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -601,7 +601,7 @@ int pt_pirq_iterate(struct domain *d,
>  unsigned int pirq = 0, n, i;
>  struct pirq *pirqs[8];
>  
> -ASSERT(spin_is_locked(&d->event_lock));
> +rcu_read_lock(&d->pirq_rcu_lock);
>  
>  do {
>  n = radix_tree_gang_lookup(&d->pirq_tree, (void **)pirqs, pirq,
> @@ -610,12 +610,18 @@ int pt_pirq_iterate(struct domain *d,
>  {
>  struct hvm_pirq_dpci *pirq_dpci = pirq_dpci(pirqs[i]);
>  
> +spin_lock(&pirq_dpci->lock);
> +
>  pirq = pirqs[i]->pirq;
>  if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
>  rc = cb(d, pirq_dpci, arg);
> +
> +spin_unlock(&pirq_dpci->lock);
>  }
>  } while ( !rc && ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
>  
> +rcu_read_unlock(&d->pirq_rcu_lock);
> +
>  return rc;
>  }
>  
> @@ -678,9 +684,7 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
>  if ( !iommu_enabled || !d->arch.hvm_domain.irq.dpci )
> return;
>  
> -spin_lock(&d->event_lock);
>  pt_pirq_iterate(d, _hvm_dpci_msi_eoi, (void *)(long)vector);
> -spin_unlock(&d->event_lock);
>  }
>  
>  static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci 
> *pirq_dpci)
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 3729b0f..ae98c1e 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -355,6 +355,7 @@ struct domain
>   */
>  struct radix_tree_root pirq_tree;
>  unsigned int nr_pirqs;
> +rcu_read_lock_t pirq_rcu_lock;
>  
>  enum guest_type guest_type;
>  
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [seabios baseline-only test] 38218: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38218 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38218/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38209

Tests which did not succeed, but are not blocking:
 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-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 seabios  9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
baseline version:
 seabios  234210135f07cf29f8fbee687ef7bd8adcf566ef

Last test of basis38209  2015-10-25 04:50:34 Z3 days
Testing same since38218  2015-10-28 16:21:12 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   fail
 test-amd64-i386-xl-qemuu-winxpsp3pass



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 9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
Author: Kevin O'Connor 
Date:   Mon Oct 26 09:38:30 2015 -0400

docs: Minor - replace seavgabios text in Build_overview.md with link

Signed-off-by: Kevin O'Connor 

commit a7620df726c9a56af6dfdfb4690722945ce2a388
Author: Kevin O'Connor 
Date:   Sun Oct 18 11:27:50 2015 -0400

virtio: Minor - replace tab characters with space

Signed-off-by: Kevin O'Connor 

commit 528c9f8c5a238f5533cdb35cb1c53de7c58a53d7
Author: Kevin O'Connor 
Date:   Sun Oct 18 11:25:15 2015 -0400

biostables: Minor - fix incorrect indentation

Signed-off-by: Kevin O'Connor 

commit 5ced3bb370f2221b886224c9c3816de490b2a5a9
Author: Kevin O'Connor 
Date:   Sun Oct 18 11:24:54 2015 -0400

coreboot: Minor - avoid K&R style function declaration

Signed-off-by: Kevin O'Connor 

commit 98a100c24febc9e8bd677d65e808ad6cf83fb1ee
Author: Kevin O'Connor 
Date:   Thu Oct 22 11:59:47 2015 -0400

build: Allow official tarball builds to be considered "clean"

If building from an official tarball and EXTRAVERSION info is
provided, then consider the build to be "clean" (don't include
hostname/build timestamp).  This is done on the expectation that
EXTRAVERSION will have enough information to allow developers to find
the builder and build environment should a defect be reported, and
therefore the hostname/timestamp is not necessary.

Signed-off-by: Kevin O'Connor 

commit 08d39868d326c0a75a188639d86f1a248178d1c6
Author: Kevin O'Connor 
Date:   Thu Oct 22 11:58:16 2015 -0400

docs: Document 'make EXTRAVERSION=xyz' and scripts/tarball.sh

Document the existence of the EXTRAVERSION field and the information
expected to be present in it.  D

Re: [Xen-devel] [PATCHv1 1/2] passthrough: use per-interrupt lock when injecting an interrupt

[Konrad Rzeszutek Wilk]

.snip..
> > @@ -481,6 +489,8 @@ int pt_irq_destroy_bind(
> >  pirq = pirq_info(d, machine_gsi);
> >  pirq_dpci = pirq_dpci(pirq);
> >  
> > +spin_lock(&pirq_dpci->lock);
> 
> Considering that code further down in this function checks
> pirq_dpci to be non-NULL, this doesn't look safe (or else those
> checks should go away, as after this addition they would be
> likely to trigger e.g. Coverity warnings).

?  The checks are for pirq_dpci->dom.

> 
> > @@ -621,7 +633,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
> >  return 1;
> >  }
> >  
> > -/* called with d->event_lock held */
> > +/* called with pirq_dhci->lock held */
> >  static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
> 
> The fact that this is a safe change to the locking model imo needs
> to be spelled out explicitly in the commit message. Afaict it's safe
> only because desc_guest_eoi() uses pirq for nothing else than to
> (atomically!) clear pirq->masked.
> 
> > @@ -675,7 +687,7 @@ static void hvm_dirq_assist(struct domain *d, struct 
> > hvm_pirq_dpci *pirq_dpci)
> >  {
> >  ASSERT(d->arch.hvm_domain.irq.dpci);
> >  
> > -spin_lock(&d->event_lock);
> > +spin_lock(&pirq_dpci->lock);
> >  if ( test_and_clear_bool(pirq_dpci->masked) )
> >  {
> >  struct pirq *pirq = dpci_pirq(pirq_dpci);
> 
> Along the same lines - it's not obvious that the uses of pirq here are
> safe with event_lock no longer held. In particular I wonder about
> send_guest_pirq() - despite the other use in __do_IRQ_guest() not
> doing any locking either I'm not convinced this is correct.


It seems that the event channel mechanism only uses the event channel
lock when expanding and initializing (FIFO). For the old mechanism
it was for binding, closing (uhuh), status, reset, and set_priority.

The 'closing' is interesting. What if the guest was closing the port
while we are to notify it of an interrupt (so inside hvm_dirq_assist).

evtchn_close will take the event_lock call pirq_cleanup_check
and calls pt_pirq_cleanup_check. We check for STATE_RUN (still set
as dpci_softirq hasn't finished calling hvm_dirq_assist) so it returns
zero .. and does not call radix_tree_delete.

Then evtchn_close goes to 'unlink_pirq_port' and then follows up with
'unmap_domain_pirq_emuirq'. That sets emuirq to IRQ_UNBOUND.

OK, now hvm_dirq_assist is now inside the first 'if' and checks:

684 if ( hvm_domain_use_pirq(d, pirq) )

which would have been true, but now is false (as emuirq is now
IRQ_UNBOUND). 

Lets also assume this is for an MSI.

The 'pt_irq_need_timer' returns 0:

142 return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE));

which hits this:

723 ASSERT(pt_irq_need_timer(pirq_dpci->flags));

and blows up.

If we are not compiled with 'debug=y' then we would set a timer which
8 ms later calls 'pt_irq_time_out'. It then clears the STATE_RUN and
the softirq is done.

So lets switch back to 'evtchn_close'.. which unlocks the event_lock
and is done.

The 'pt_irq_time_out' is pretty much a nop - takes the event_lock,
does not iterate over the list as it is an MSI one so no legacy interrupts.
Calls pt_irq_guest_eoi over the radix tree - and pt_irq_guest_eoi does nothing
as the _HVM_IRQ_DPCI_EOI_LATCH_SHIFT is not set.

I think that is the only issue - when using the legacy event channels
and the guest fiddling with the pirq. I suppose that means anybody
using 'unmap_domain_pirq_emuirq' will hit this ASSERT(). That means:

 arch_domain_soft_reset
 physdev_unmap_pirq
 evtchn_close

Thought you could 'fix' this by doing:


diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index bda9374..6ea59db 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -720,8 +720,8 @@ static void hvm_dirq_assist(struct domain *d, struct 
hvm_pirq_dpci *pirq_dpci)
  * guest will never deal with the irq, then the physical interrupt line
  * will never be deasserted.
  */
-ASSERT(pt_irq_need_timer(pirq_dpci->flags));
-set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
+if (pt_irq_need_timer(pirq_dpci->flags))
+set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT);
 }
 spin_unlock(&d->event_lock);
 }






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

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 60684

version targeted for testing:
 linux8d98caa286ccbb1cad7378b1731cd5539d8d6860
baseline version:
 linux69f75ebe3b1d

Re: [Xen-devel] Is it possible to create a domain with privileges similar to dom0

[Razvan Cojocaru]

On 10/28/2015 08:57 PM, D'Mita Levy wrote:
> Is it possible to create a domain that has increased privilege levels
> that are similar to dom0? I am interested in installing a VM and have it
> perform certain tasks that will require it to have a higher privilege
> level than domU guests.

It is, take a look at XSM.


Cheers,
Razvan

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

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

[osstest service owner]

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

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  b261366f10eb150458d28aa728d399d0a781997e
baseline version:
 xen  bf0d4923d7783ece38bb8f3b832e8df0f3fc284b

Last test of basis63335  2015-10-27 16:02:08 Z1 days
Testing same since63349  2015-10-28 18:01:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  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=b261366f10eb150458d28aa728d399d0a781997e
+ . ./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 
b261366f10eb150458d28aa728d399d0a781997e
+ branch=xen-unstable-smoke
+ revision=b261366f10eb150458d28aa728d399d0a781997e
+ . ./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-unstable
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=

Re: [Xen-devel] [PATCH v3] dom variable error handled in Xenstore

[Lasya Venneti]

On 28 October 2015 at 06:30, Dario Faggioli 
wrote:

> On Wed, 2015-10-28 at 05:42 +0530, Lasya wrote:
> > xc_dom_allocate function in build function in init-xenstore-domain.c
> > returns NULL on failure.
> > In that case, variable rv is set to ENOMEM and directed to failure
> > path err.
> >
> >
> So, about the subject line:
>  - we want tags (as in "tag: does some stuff"), in order to help people
>figure out quickly (and/or filter in their mail readers) what
>component of Xen the patch is about. In your case, a suitable tag
>would be "tools/xenstore:", or even just "xenstore:";
>  - it should hint at and summarize very very briefly what is being
>done. In this case, for instance, something like this:
>"xenstore: check for domain allocation errors".
>
> Dario, I will trim down the content, and send another in.

> About the actual changelog:
>  - wrap lines a bit more, ideally around 70 characters per line. The
>point being, it should display well in things like `git log', which
>typically indents it a bit;
>  - it should describe what the patch does, at a higher abstraction
>level (e.g., why the patch is necessary, why a particular approach
>has been taken, etc.). What you have up here, can pretty much all
>be inferred already reading the code. So, for instance, something
>like this:
>"When building xenstore domain, failure at allocating the memory
> for it was not handled. Fix that"
>  - since you are (I think) fixing an issue identified by Coverity,
>you should mention the Coverity ID in the changelog somehow as well.
>
I shall mention the coverity ID this time , and will keep this is mind.
As I didn't have knowledge about the code base, I used the variable
names. I will definitely explain the bug in conceptual terms this time.

>
> About the code:
>
> > Signed-off-by: Lasya Venneti 
>
> > diff --git a/tools/xenstore/init-xenstore-domain.c
> > @@ -42,6 +42,10 @@ static int build(xc_interface *xch, int argc,
> > char** argv)
> >   snprintf(cmdline, 512, "--event %d --internal-db", rv);
> >
> >   dom = xc_dom_allocate(xch, cmdline, NULL);
> > + if (dom == NULL) {
> > + rv = ENOMEM;
> > + goto err;
> > + }
> >
> On what basis did you decide that ENOMEM was a good return value?
>
> I mean, have you checked what kind of value / error code is being
> returned in the other cases (e.g., , xc_domain_setmaxmem(),
> xc_domain_max_vcpus(), etc), if something goes wrong?
>
> Thanks and Regards,
> Dario
>
Wei had advised me to raise ENOMEM (Out of memory). However,
on your advice I checked the xc_domain_setmaxmem()  and
xc_domain_max_vcpus().
On failure:
->xc_domain_setmaxmem returns a negative value.
function libxl__build_pre in xen/tools/libxl/libxl_dom.c returns
ERROR_FAIL when xc_domain_setmaxmem fails.

->xc_domain_max_vcpus returns a non zero value.
It returns the same error value for libxl_build_pre function as
above.

I must also add errno.h header to the file, I forgot to do that. I shall
do so in the next version.

Request your comments, should I go with ENOMEM as we are finding
(I think) 'amount' of dom memory allocation, and on failure it returns
NULL, or with the generic ERROR_FAIL.

Regards
Lasya V


--
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] Add build-id to XENVER hypercall.

[Konrad Rzeszutek Wilk]

On Wed, Oct 28, 2015 at 11:42:41AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 09:14:00AM -0600, Jan Beulich wrote:
> > >>> On 09.10.15 at 15:25,  wrote:
> > > On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> > >> On 09/10/15 09:17, Jan Beulich wrote:
> > >>  On 09.10.15 at 04:56,  wrote:
> > >> >> However they also change the behavior of the existing hypercall
> > >> >> for XENVER_[compile_info|changeset|commandline] and make them
> > >> >> dom0 accessible. This is if XSM is built in or not (though with
> > >> >> XSM one can expose it to a guest if desired).
> > >> > Wasn't the outcome of the previous discussion that we should not
> > >> > alter default behavior for existing sub-ops?
> > >> 
> > >> I raised a worry that some guests might break if they suddenly have
> > >> access to this information cut off.
> > > 
> > > Let me double-confirm that the guests are OK with this being
> > > gone. I did ran tests to see if the worked, but hadn't actually tried
> > > acessing (/sys/hypervisor/xen*) the values.
> > 
> > Well, this is the kind of thing you can't find out by testing _some_
> > guest(s) - you'd need to test with all possible ones, which of course
> > is not feasible. Hence we need to be very conservative when
> 
> I was thinking to test:
> 
> F19-64 F19-32 F17-64 F17-32 F16-32
> F16-64 F15-32 F15-64 NetBSD FreeBSD RHEL5-64 RHEL5-32 SLES11-32 SLES12-32
> OL6_X86_64_PVHVM OL6_X86_64_PV OL5_X86_64_PVHVM Win2K (with SuSE PV drivers)
> WinXP (with Windows GPL drivers) and Windows 7 (with Windows GPL), SOL12
> 
> And see what happens when those are not available (poke in /sysfs or whatever
> I can)
> 
> > deciding to restrict part of a so far guest-kind-indifferent ABI.
> 
> Right, so only three of them are off.
> 
> Perhaps an another option would be to return success and fill out the
> value with an empty string?
> 
> That actually sounds nicer.

Like this:

>From f5672c4b72361132798c0ec4bd124c9ddc80bd44 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 28 Sep 2015 09:00:58 -0400
Subject: [PATCH] xsm/libxl/xen_version: Add XSM for the xen_version hypercall.

All of XENVER_* have now an XSM check.

The XENVER_[compile_info|changeset|commandline] are now
guarded by an XSM check for priviliged domains.

We allow the initial domain to see these while the other
guests are not permitted. But to not make them unhappy
we will return 0 or empty strings.

The rest: XENVER_[version|extraversion|capabilities|
parameters|get_features|page_size|guest_handle] behave
as before - allowed by default for guests (thought if the
XSM checks fail then we will return empty strings as well).

Also in case XSM for all version_* is disabled we add code
in libxl so that it won't divide by zero.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: Do XSM check for all the XENVER_ ops.
v3: Add empty data conditions.
---
 tools/flask/policy/policy/modules/xen/xen.te |  9 
 tools/libxl/libxl.c  |  2 +
 xen/common/kernel.c  | 63 ++--
 xen/include/xsm/dummy.h  | 23 ++
 xen/include/xsm/xsm.h|  6 +++
 xen/xsm/dummy.c  |  1 +
 xen/xsm/flask/hooks.c| 27 
 xen/xsm/flask/policy/access_vectors  |  5 +++
 8 files changed, 124 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index d35ae22..40dd7f4 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -73,6 +73,12 @@ allow dom0_t xen_t:xen2 {
 pmu_ctrl
 get_symbol
 };
+
+# Allow dom0 to use XENVER_compile_info|changeset|commandline]
+allow dom0_t xen_t:xen2 {
+version_priv
+};
+
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
@@ -137,6 +143,9 @@ if (guest_writeconsole) {
 # pmu_ctrl is for)
 allow domain_type xen_t:xen2 pmu_use;
 
+# All all domains to use (unprivileged parts of) the XENVER_* hypercall
+allow domain_type xen_t:domain2 version_use;
+
 ###
 #
 # Domain creation
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 22bbc29..3c03b6a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5288,6 +5288,8 @@ const libxl_version_info* 
libxl_get_version_info(libxl_ctx *ctx)
 info->virt_start = u.p_parms.virt_start;
 
 info->pagesize = xc_version(ctx->xch, XENVER_pagesize, NULL);
+if (!info->pagesize) /* No divide by zero! */
+   info->pagesize = 1;
 
 xc_version(ctx->xch, XENVER_commandline, &u.xen_commandline);
 info->commandline = strdup(u.xen_commandline);
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 6a3196a..c98c58c 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -13,6 +13,7 @@
 #in

Re: [Xen-devel] [PATCH v1 2/4] xen-version: Add third parameter (len) to the do_version hypercall.

[Konrad Rzeszutek Wilk]

On Wed, Oct 28, 2015 at 06:34:37PM +, Andrew Cooper wrote:
> On 28/10/15 17:55, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> > On 09.10.15 at 14:46,  wrote:
> >>> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
>  On 09/10/15 09:25, Jan Beulich wrote:
>  On 09.10.15 at 04:56,  wrote:
> >> All existing commands ignore the parameter so this does
> >> not break the ABI.
> > Does it not? What about the debug mode clobbering of hypercall
> > argument registers?
>  That is an implementation detail of the hypervisor.  It is irrelevant to
>  guests whether Xen chooses to clobber the spare registers or not.
> >>> Or in other words the effect here is to clobber one _less_ register, and
> >>> the guest cannot have been relying on a register getting so clobbered (if
> >>> nothing else it doesn't happen in debug=n builds).
> >> No, the one less register clobbered is in the first clobbering phase,
> >> where _unused_ inputs get clobbered (for hypervisor internal
> >> consumption). The second clobbering phase destroys all _used_
> >> input registers' contents (the guest visible values), and _this_ is
> >> what results in ABI breakage (because callers assuming the
> >> hypercall to take two arguments assume that the 3rd argument
> >> register will retain its contents.
> > Thanks for explaining it! I see my patch missed the change to
> > hypercall_table and along with compiling with debug=y it all worked
> > so I didn't get the 'len' parameter to be clobbered.
> >
> > Ugh.
> >
> > Then the right way to make this work would be to only clobber
> > the third argument if the XENVER_buildid command was used? And
> > preserve the third argument only if XENVER_buildid command was used.
> >
> > And not clobber third argument in all other cases. That would
> > require some nasty tweaking of entry.S.
> >
> > Ugh. I think going to the original idea of just having an
> > xen_build_id_t[1024] would be the easiest.
> >
> > Or I can do a structure:
> >
> > struct xen_build_id_t {
> > uint32_tlen; /* IN: size of the buffer. */
> > uint32_t_pad; /* IN: MUST be zero. */
> > XEN_GUEST_HANDLE_64(char) buf; /* OUT: Buffer with build_id. */
> > }
> >
> > Any preference? The 'xen_build_id_t[1024]' looks nicer.
> 
> The current interface the xen_version hypercall is mad.  It has the same
> shortcoming as the C library function gets().
> 
> It is unfortunate that our current debug register-clobbering strategy
> prevents altering the number of parameters in a forwards compatible.
> 
> There are two options to move forwards:
> 1) Introduce a new hypercall and relegate the existing one to being a
> _compat.
> 2) Change our debug clobbering strategy.
> 
> We definitely dont any further contritions to the school of "pass a
> pointer without a length and trust the other side".
> 
> I think it might be prudent to follow option 1), as that also allows to
> fix other issues such as the arbitrary (and unreasonable IMO) 1k
> restriction on the length of the hypervisor command line.

 Yak shaving..

If we are going that route may I suggest another option (less
animal interaction):

3) Stick XENVER_build_id under the xSplice hypercall?


> 
> ~Andrew

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

[Xen-devel] Is it possible to create a domain with privileges similar to dom0

[D'Mita Levy]

Is it possible to create a domain that has increased privilege levels that
are similar to dom0? I am interested in installing a VM and have it perform
certain tasks that will require it to have a higher privilege level than
domU guests.

-- 
D'Mita Levy
Cyber Fellow, Applied Research Center
Florida International University
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 2/4] xen-version: Add third parameter (len) to the do_version hypercall.

[Andrew Cooper]

On 28/10/15 17:55, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> On 09.10.15 at 14:46,  wrote:
>>> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
 On 09/10/15 09:25, Jan Beulich wrote:
 On 09.10.15 at 04:56,  wrote:
>> All existing commands ignore the parameter so this does
>> not break the ABI.
> Does it not? What about the debug mode clobbering of hypercall
> argument registers?
 That is an implementation detail of the hypervisor.  It is irrelevant to
 guests whether Xen chooses to clobber the spare registers or not.
>>> Or in other words the effect here is to clobber one _less_ register, and
>>> the guest cannot have been relying on a register getting so clobbered (if
>>> nothing else it doesn't happen in debug=n builds).
>> No, the one less register clobbered is in the first clobbering phase,
>> where _unused_ inputs get clobbered (for hypervisor internal
>> consumption). The second clobbering phase destroys all _used_
>> input registers' contents (the guest visible values), and _this_ is
>> what results in ABI breakage (because callers assuming the
>> hypercall to take two arguments assume that the 3rd argument
>> register will retain its contents.
> Thanks for explaining it! I see my patch missed the change to
> hypercall_table and along with compiling with debug=y it all worked
> so I didn't get the 'len' parameter to be clobbered.
>
> Ugh.
>
> Then the right way to make this work would be to only clobber
> the third argument if the XENVER_buildid command was used? And
> preserve the third argument only if XENVER_buildid command was used.
>
> And not clobber third argument in all other cases. That would
> require some nasty tweaking of entry.S.
>
> Ugh. I think going to the original idea of just having an
> xen_build_id_t[1024] would be the easiest.
>
> Or I can do a structure:
>
> struct xen_build_id_t {
>   uint32_tlen; /* IN: size of the buffer. */
>   uint32_t_pad; /* IN: MUST be zero. */
>   XEN_GUEST_HANDLE_64(char) buf; /* OUT: Buffer with build_id. */
> }
>
> Any preference? The 'xen_build_id_t[1024]' looks nicer.

The current interface the xen_version hypercall is mad.  It has the same
shortcoming as the C library function gets().

It is unfortunate that our current debug register-clobbering strategy
prevents altering the number of parameters in a forwards compatible.

There are two options to move forwards:
1) Introduce a new hypercall and relegate the existing one to being a
_compat.
2) Change our debug clobbering strategy.

We definitely dont any further contritions to the school of "pass a
pointer without a length and trust the other side".

I think it might be prudent to follow option 1), as that also allows to
fix other issues such as the arbitrary (and unreasonable IMO) 1k
restriction on the length of the hypervisor command line.

~Andrew

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

Re: [Xen-devel] [linux-3.14 test] 63336: regressions - FAIL

[Julien Grall]

Hi,

On 28/10/15 17:31, osstest service owner wrote:
> flight 63336 linux-3.14 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/63336/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-armhf-pvops 5 kernel-build  fail REGR. vs. 
> 62648

> + make -j4 INSTALL_PATH=/home/osstest/build.63336.build-armhf-pvops/dist/boot 
> INSTALL_MOD_PATH=/home/osstest/build.63336.build-armhf-pvops/dist 
> modules_install dtbs_install
> make: *** No rule to make target `dtbs_install'.  Stop.
> make: *** Waiting for unfinished jobs

This is not a Linux regression but a bug introduced in osstest
by d4dba6183d616b1d4f9826834318db48eb8ec5d6 "ts-kernel-build:
Include dtbs in dist file"

As said by the commit message the target dtbs_install has
been introduced post-3.14. It also says that we only test
3.16 and onwards on ARM. However this job seems to prove
the contrary.

So shall we disable 3.14 job for ARM for once and all?

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1 2/4] xen-version: Add third parameter (len) to the do_version hypercall.

[Konrad Rzeszutek Wilk]

On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> >>> On 09.10.15 at 14:46,  wrote:
> > On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
> >> On 09/10/15 09:25, Jan Beulich wrote:
> >> > > > > On 09.10.15 at 04:56,  wrote:
> >> > > All existing commands ignore the parameter so this does
> >> > > not break the ABI.
> >> > Does it not? What about the debug mode clobbering of hypercall
> >> > argument registers?
> >> 
> >> That is an implementation detail of the hypervisor.  It is irrelevant to
> >> guests whether Xen chooses to clobber the spare registers or not.
> > 
> > Or in other words the effect here is to clobber one _less_ register, and
> > the guest cannot have been relying on a register getting so clobbered (if
> > nothing else it doesn't happen in debug=n builds).
> 
> No, the one less register clobbered is in the first clobbering phase,
> where _unused_ inputs get clobbered (for hypervisor internal
> consumption). The second clobbering phase destroys all _used_
> input registers' contents (the guest visible values), and _this_ is
> what results in ABI breakage (because callers assuming the
> hypercall to take two arguments assume that the 3rd argument
> register will retain its contents.

Thanks for explaining it! I see my patch missed the change to
hypercall_table and along with compiling with debug=y it all worked
so I didn't get the 'len' parameter to be clobbered.

Ugh.

Then the right way to make this work would be to only clobber
the third argument if the XENVER_buildid command was used? And
preserve the third argument only if XENVER_buildid command was used.

And not clobber third argument in all other cases. That would
require some nasty tweaking of entry.S.

Ugh. I think going to the original idea of just having an
xen_build_id_t[1024] would be the easiest.

Or I can do a structure:

struct xen_build_id_t {
uint32_tlen; /* IN: size of the buffer. */
uint32_t_pad; /* IN: MUST be zero. */
XEN_GUEST_HANDLE_64(char) buf; /* OUT: Buffer with build_id. */
}

Any preference? The 'xen_build_id_t[1024]' looks nicer.
> 
> Jan
> 

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

Re: [Xen-devel] arm64: iomem_resource doesn't contain all the region used

[Julien Grall]

(Adding David and Daniel)

On 23/10/15 16:45, Ian Campbell wrote:
> On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
>> Is there any way we could register the IO region used on ARM without
>> having to enforce it in all the drivers?
> 
> This seems like an uphill battle to me.

I agree about it. However this is how x86 handle memory hotplug for xen
ballooning. I'm wondering how this is cannot an problem for x86?

Note that the problem is the same if a module is insert after hand.

> 
> Why not do as I suggested IRL yesterday and expose the map of "potential
> RAM" addresses to the guest as well as the "actual RAM" addresses in the
> regular memory properties.
> 
> i.e. explicitly expose the holes where RAM can be hotplugged later.

I was trying to find another solution because I find your suggestion
fragile.

Currently the device tree for a guest is set in stone after the creation
of the domain. I.e it's not possible to modify the device tree later
(I'm not speaking about hardcode value...).

This means that the region for "balloon hotplug" and "PCI hotplug" must
be static and can't overlapped. We may end up to run out of "PCI
hotplug" address space while there is plenty of free space in the
"balloon hotplug". However it's not possible to move from one to another.

How do you define the size of those regions? In one side, we can't
"hardcode" them because the user may not want to use either "balloon
hotplug" or "PCI hoplug". On another side, we could expose them to the
user but it's not nice.

> This is even analogous to a native memory hotplug case, which AIUI
> similarly involves the provisioning of specific address space where RAM
> might plausibly appear in the future (I don't think physical memory hotplug
> involves searching for free PA space and hoping for the best, although
> strange things have happened I guess).

I've looked at how Power PC handle native hotplug. From my
understanding, when a new memory bank is added, the device tree will be
updated by someone (firmware?) and an event will be sent to the Linux.

Linux will then read the new DT node (see
ibm,dynamic_reconfiguration-memory) and add the new memory region to Linux.

> 
> With any luck you would be able to steal or define the bindings in terms of
> the native hotplug case rather than inventing some Xen specific thing.

I wasn't able to find the binding for ibm,dynamic-reconfiguration-memory
in Linux.

> 
> In terms of dom0 the "potential" RAM is the host's actual RAM banks.

Your solution works for DOM0, but ...

> In terms of domU the "potential" RAM is defined by the domain builder
> layout (currently the two banks mentioned in Xen's arch-arm.h).

... the DOMU one is more complex (see above). Today the guest layout is
static, I wouldn't be surprised to see it becoming dynamic very soon (I
have in mind PCI hotplug) and therefore defining static hotplug region
would not possible.

Regards,

[1]
https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.4&id=55b3da98a40dbb3776f7454daf0d95dde25c33d2


-- 
Julien Grall

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

[Xen-devel] [linux-3.14 test] 63336: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux07bd6f89f7ff56495c31505985af690c976374d6
baseline version:
 linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9

Last test of basis62648  2015-10-03 22:43:24 Z   24 days
Failing since 63225  2015-10-22 22:20:24 Z5 days5 attempts
Testing same since63336  2015-10-27 17:53:49 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Adrian Hunter 
  Al Viro 
  Alex Deucher 
  Alexander Couzens 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine Ténart 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Dooks 
  Ben Hutchings 
  Ben Skeggs 
  Brian Norris 
  Charles Keepax 
  Chris Mason 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dann Frazier 
  Dave Airlie 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Dirk Mueller 
  Dirk Müller 
  Eric Dumazet 
  Eric W. Biederman 
  Eryu Guan 
  Fabiano Fidêncio 
  Filipe Manana 
  Frederic Weisbecker 
  Geert Uytterhoeven 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Nikolaus Schaller 
  Herbert Xu 
  Ian Abbott 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jason Wang 
  Jeff Mahoney 
  Jenny Derzhavetz 
  Jiri Olsa 
  Joe Perches 
  Joe Stringer 
  Joe Thornber 
  Johan Hovold 
  John Covici 
  John Flatness 
  Joonsoo Kim 
  Joonsoo Kim 
  Julian Anastasov 
  Kan Liang 
  Kees Cook 
  Konstantin Khlebnikov 
  Krzysztof Kozlowski 
  Kukjin Kim 
  Linus Torvalds 
  Liu.Zhao 
  Mark Brown 
  Mark Salyzyn 
  Mathias Nyman 
  Matt Fleming 
  Mel Gorman 
  Michael Ellerman 
  Michal Hocko 
  Michel Stam 
  Mika Westerberg 
  Mike Galbraith 
  Mike Snitzer 
  Mikulas Patocka 
  Namhyung Kim 
  NeilBrown 
  Nicholas Bellinger 
  Nicolas Pitre 
  Oleksii Berezhniak 
  Pablo Neira Ayuso 
  Paolo Bonzini 
  Paul Bolle 
  Paul E. McKenney 
  Paul Mackerras 
  Paul Mackerras 
  Pavel Roskin 
  Peter Seiderer 
  Peter Zijlstra (Intel) 
  Peter Zijls

Re: [Xen-devel] [PATCH RFC] tools/ocaml/xb: Correct calculations of data/space the ring

[Andrew Cooper]

On 28/10/15 16:56, Samuel Thibault wrote:
> Andrew Cooper, le Wed 28 Oct 2015 16:43:54 +, a écrit :
>>> IIRC the test is not bogus even when prod wraps around, (prod - cons)
>>> will still correctly be the difference between both, modulo 2^32.
>> (prod - cons) >= XENSTORE_RING_SIZE checks for the prod getting more
>> than a ring's worth ahead of cons.
>>
>> (cons - prod) < -XENSTORE_RING_SIZE is supposed to check for cons
>> getting ahead of prod
> If cons is a ahead of prod, prod-cons is way bigger than
> XENSTORE_RING_SIZE, and thus the first test already catches that. In the
> 2^32 wrap case, the difference will still be correct.

Hmm - of course.  I will scale back the adjustments to the error handling.

~Andrew

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

Re: [Xen-devel] [PATCH v3 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 10/28/2015 05:11 PM, Wei Liu wrote:

On Tue, Oct 13, 2015 at 03:11:15PM +0200, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
---
  tools/libxc/include/xc_dom.h |  5 +
  tools/libxc/xc_dom_core.c| 19 +--
  tools/libxc/xc_dom_x86.c |  8 
  3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index b0120a6..fa772a9 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,6 +94,11 @@ struct xc_dom_image {
  xen_pfn_t pfn_alloc_end;
  xen_vaddr_t virt_alloc_end;
  xen_vaddr_t bsd_symtab_start;
+
+/* initrd parameters as specified in start_info page */
+unsigned long initrd_start;
+unsigned long initrd_len;
+
  unsigned int alloc_bootstack;
  xen_vaddr_t virt_pgtab_end;

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 8e1e17f..15e9fa3 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1041,6 +1041,7 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
  int xc_dom_build_image(struct xc_dom_image *dom)
  {
  unsigned int page_size;
+bool unmapped_initrd;

  DOMPRINTF_CALLED(dom->xch);

@@ -1064,11 +1065,15 @@ int xc_dom_build_image(struct xc_dom_image *dom)
  if ( dom->kernel_loader->loader(dom) != 0 )
  goto err;

-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Load ramdisk if initial mapping required. */
+unmapped_initrd = dom->parms.unmapped_initrd && !dom->ramdisk_seg.vstart;


A minor suggestion, the comment is describing the reverse logic of the
statement that immediately follows it, can you make the comment and
statement match?


Sure.


I think I manage to work this out: if ramdisk_seg.vstart is set that
means upper layer wants the ramdisk to be mapped at that address (ARM is
doing that), so in that case even if kernel supports unmapped initrd we
should still map the ramdisk. Correct me if I'm wrong.


That's how it was meant to be.


The rest of code looks correct. With that understand (and whether you
follow my minor suggestion or not):

Acked-by: Wei Liu 



Thanks,

Juergen

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

Re: [Xen-devel] [BUG] mistakenly wake in Xen's credit scheduler

[suokun]

On Tue, Oct 27, 2015 at 11:41 PM, Dario Faggioli
 wrote:
> On Tue, 2015-10-27 at 14:32 -0600, suokun wrote:
>> On Tue, Oct 27, 2015 at 4:44 AM, Dario Faggioli
>>  wrote:
>
>> Hi, Dario,
>> Thank you for your reply.
>>
> Hi,
>
>> Here are my two VMs running on the same physical CPU.
>> VM-IO: 1-vCPU pinned to a pCPU, running netperf
>> VM-CPU: 1-vCPU pinned the the same pCPU, running a while(1) loop
>> Another machine run the netperf client to send the requests to VM-IO.
>>
>> My code is very simple:
>> in VM-IO, as server side: $ netserver -p 12345
>> in VM-CPU, just running a while(1) loop: $./loop
>> in the client, send I/O request to the VM-IO: $ netperf -H
>> [server_ip]
>> -l 15 -t TCP_STREAM -p 12345
>>
> Ok, thanks.
>
>> The setting that led to the poor IO performance is as follows:
>> VM-IO:  1-vCPU pinned to a pCPU, running netperf
>> VM-CPU: 1-vCPU pinned the the same pCPU, running a while(1) loop
>>
>> The root cause is that when an IO request comes, VM-IO’s vCPU is
>> elevated to BOOST and goes through vcpu_wake —> __runq_tickle. In
>> __runq_tickle, the currently running vCPU (i.e., the vCPU from VM
>> -CPU) is marked as _VPF_migrating.
>>
> Ok.
>
>> Then, Xen goes through schedule() to
>> reschedule the current vCPU (i.e., vCPU from VM-CPU) and schedule the
>> next vCPU (i.e., the vCPU from VM-IO). Due to the _VPF_migrating
>> flag, the descheduled vCPU will be migrated in context_saved() and
>> later woken up in cpu_wake().
>>
> Sure.
>
>> Indeed, csched_vcpu_wake() will quit if the
>> vCPU from VM-CPU is on run queue. But it is actually not. In
>> csched_schedule(), the vCPU will not be inserted back to run queue
>> because it is not runnable due to the __VPF_migrating bit in
>> pause_flags. As such, the vCPU from VM-CPU will boosted and not be
>> preempted by a later IO request because BOOST can not preempt BOOST.
>>
> Aha! Now I see what you mean. From the previous email, I couldn't
> really tell which one call to schedule you where looking at, during
> each phase of the analysis... Thanks for clarifying!
>
> And, yes, I agree with you that, since the vCPU of VM-CPU fails the
> vcpu_runnable() test, it's being treated as it is really waking up from
> sleep, in csched_vcpu_wake(), and hence boosted.
>
>> A simple fix would be allowing BOOST to preempt BOOST.
>>
> Nah, that would be an hack on top of an hack! :-P
>
>> A better fix
>> would be checking the CPU affinity before setting the __VPF_migrating
>> flag.
>>
> Yeah, I like this better. So, can you try the patch attached to this
> email?
>
> Here at my place, without any patch, I get the following results:
>
>  idle:   throughput = 806.64
>  with noise: throughput = 166.50
>
> With the patch, I get this:
>
>  idle:   throughput = 807.18
>  with noise: throughput = 731.66
>
> The patch (if you confirm that it works) fixes the bug in this
> particular situations, where vCPUs are all pinned to the same pCPUs,
> but does not prevent vCPUs being migrated around the pCPUs to become
> BOOSTed in Credit2.
>
> That is something I think we should avoid, and I've got a (small) patch
> series ready for that. I'll give some more testing to it before sending
> it to the list, though, as I want to make sure it's not causing
> regressions.
>
> Thanks and Regards,
> Dario

Hi, Dario,

thank you for your reply.

Here is my patch, actually just one line of code:

if ( new_idlers_empty && new->pri > cur->pri )
{
SCHED_STAT_CRANK(tickle_idlers_none);
SCHED_VCPU_STAT_CRANK(cur, kicked_away);
SCHED_VCPU_STAT_CRANK(cur, migrate_r);
SCHED_STAT_CRANK(migrate_kicked_away);

+   /* migration can happen only cpu number greater than 1 and vcpu is
not pinned to a single physical CPU */
+   if(num_online_cpus() > 1 &&
cpumask_weight((cur->vcpu)->cpu_hard_affinity) > 1) {
set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
+   }
cpumask_set_cpu(cpu, &mask);
}

without patch:
idle: throughput = 941
with noise: throughput = 32

with patch
idle: throughput = 941
with noise: throughput = 691


I tried your patch, here is the test results on my machine:
with your patch
idle: throughput = 941
with noise: throughput = 658

Both our patch can improve the I/O throughput with noise
significantly. But still, compared to the I/O-only scenario, there is
a 250~290 gap.

That is due to the ratelimit in Xen's credit scheduler. The default
value of rate limit is 1000us which means once CPU-intensive vCPU
starts to run, I/O-intensive vCPU need to wait 1000us even though an
I/O-request comes or its priority is BOOST. However, the time interval
between two I/O requests in Netperf is just tens of microsecond, far
less than the ratelimit. That will make some I/O-request cannot be
handled in time, cause the loss of throughput.

I tried to reduce the rate limit manually and the throughput will
increase after that.

Best
Tony


> ---
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about

Re: [Xen-devel] [PATCH v3 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 10/28/2015 05:21 PM, Wei Liu wrote:

On Wed, Oct 28, 2015 at 04:51:05PM +0100, Juergen Gross wrote:
[...]

+static int xc_dom_alloc_pad(struct xc_dom_image *dom, xen_vaddr_t end)
+{
+unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
+xen_pfn_t pages;
+
+if ( end & (page_size - 1) )
  {
  xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
   "%s: segment start isn't page aligned (0x%" PRIx64 ")",


"segment end"?


No. This function is called to add a padding allocation before the start
of a new segment, which has to start at page boundary. Maybe a comment
should clarify this. :-)



Heh, I worked out this function was used to add padding segment but
was confused by the dissonance.

A simpler solution might be just change "end" to "start"? I think it is
sensible because it is the start of the padding.


Hmm, or use "boundary" for the variable and in the message. :-)


Juergen

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

Re: [Xen-devel] [PATCH v2] xl: log an error if libxl_cpupool_destroy() fails

[Wei Liu]

On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> In fact, right now, failing at destroying a cpupool is just
> not reported to the user in any explicit way.
> 
> Let's log an error, as it is customary for xl in these cases.
> 
> Signed-off-by: Dario Faggioli 
> Reviewed-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH RFC] tools/ocaml/xb: Correct calculations of data/space the ring

[Samuel Thibault]

Andrew Cooper, le Wed 28 Oct 2015 16:43:54 +, a écrit :
> > IIRC the test is not bogus even when prod wraps around, (prod - cons)
> > will still correctly be the difference between both, modulo 2^32.
> 
> (prod - cons) >= XENSTORE_RING_SIZE checks for the prod getting more
> than a ring's worth ahead of cons.
> 
> (cons - prod) < -XENSTORE_RING_SIZE is supposed to check for cons
> getting ahead of prod

If cons is a ahead of prod, prod-cons is way bigger than
XENSTORE_RING_SIZE, and thus the first test already catches that. In the
2^32 wrap case, the difference will still be correct.

Samuel

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

Re: [Xen-devel] [PATCH RFC] tools/ocaml/xb: Correct calculations of data/space the ring

[Andrew Cooper]

On 28/10/15 16:18, Samuel Thibault wrote:
> Andrew Cooper, le Wed 28 Oct 2015 16:05:36 +, a écrit :
>> @@ -62,22 +62,32 @@ CAMLprim value ml_interface_read(value ml_interface,
>>  
>>  xen_mb();
>>  
>> -if ((prod - cons) > XENSTORE_RING_SIZE)
>> +if (((prod - cons) > XENSTORE_RING_SIZE) ||
>> +((cons - prod) < -XENSTORE_RING_SIZE))
> prod and cons are uint32_t, so the difference will still be unsigned.

The RHS will also be promoted to unsigned, as int has insufficient range
for the LHS.

> IIRC the test is not bogus even when prod wraps around, (prod - cons)
> will still correctly be the difference between both, modulo 2^32.

(prod - cons) >= XENSTORE_RING_SIZE checks for the prod getting more
than a ring's worth ahead of cons.

(cons - prod) < -XENSTORE_RING_SIZE is supposed to check for cons
getting ahead of prod (the naive (cons > prod) fails when the ring
wraps), although I notice it still buggy in the case where cons == prod.

>
> Indeed, the read side also needs the same two-memcpy fix.
>
>> +/* Check for any pending data at all. */
>> +total_data = prod - cons;
>> +if (total_data == 0) {
> ...
>> +else if (total_data > len)
>> +/* Some data - make a partial read. */
>> +len = total_data;
>> +
>> +/* Check whether data crosses the end of the ring. */
>> +data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
>> +if (len <= data)
>> +/* Data within the remaining part of the ring. */
>> +memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
>> +else {
>> +/* Data crosses the ring boundary. Read both halves. */
>> +memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
>> +memcpy(buffer + data, intf->req, len - data);
>> +}
>> +
> That looks right and nice-looking to me.
>
>>  xen_mb();
>>  intf->req_cons += len;
>>  result = len;
>> @@ -100,7 +110,7 @@ CAMLprim value ml_interface_write(value ml_interface,
>>  
>>  struct xenstore_domain_interface *intf = interface->addr;
>>  XENSTORE_RING_IDX cons, prod;
>> -int can_write;
>> +int total_space, space;
>>  uint32_t connection;
>>  
>>  cons = *(volatile uint32_t*)&intf->rsp_cons;
>> @@ -111,17 +121,33 @@ CAMLprim value ml_interface_write(value ml_interface,
>>  caml_raise_constant(*caml_named_value("Xb.Reconnect"));
>>  
>>  xen_mb();
>> -if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
>> +
>> +if (((prod - cons) > XENSTORE_RING_SIZE) ||
>> +((cons - prod) < -XENSTORE_RING_SIZE))
> Ditto.
>
>> +/* Check for space to write the full message. */
>> +total_space = prod - cons;
>> +if (total_space == 0) {
> Shouldn't that be total_space == XENSTORE_RING_SIZE?

Yes - I think it should.  (I should probably kill my pending tests -
they are not going to get very far...)

~Andrew

>
>> +/* No space at all - exit having done nothing. */
>>  result = 0;
>>  goto exit;
>>  }
>> +else if (total_space < len)
>> +/* Some space - make a partial write. */
>> +len = total_space;
>> +
>> +/* Check for space until the ring wraps. */
>> +space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
>> +if (len <= space )
>> +/* Message fits inside the remaining part of the ring. */
>> +memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
>> +else {
>> +/* Message wraps around the end of the ring. Write both halves. 
>> */
>> +memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, space);
>> +memcpy(intf->rsp, buffer + space, len - space);
>> +}
> That looks right and nicer-looking than my attempt :)
>
> Samuel


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

Re: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli]

On Wed, 2015-10-28 at 03:03 -0600, Jan Beulich wrote:
> > > > On 28.10.15 at 03:58,  wrote:

> > We still call arch_vcpu_block() in vcpu_block(), but we don't need
> > to
> > call arch_vcpu_block_cancel(v) when local_events_need_delivery()
> > returns true. Then before VM-Entry, we can check if 'NV' field is
> > ' pi_wakeup_vector', if it is, we change the PI status and remove
> > it from the blocking list.
> > 
> > Jan, if #2 is what you mean, I think it worth a try. If I don't
> > understand
> > your comments correctly, could you please elaborate it more? Thanks
> > a lot!
> 
> Ideally we'd avoid both arch_vcpu_*() calls by doing what is needed
> in arch code (e.g. the VM entry path). 
>
+1

> If only avoiding the cancel
> hook is reasonably possible this way, then so be it - still better to
> have just one hook here than having two.
> 
+1 again

As an aside, I've spoked with some ARM people, the context being that
they will get to implement a similar feature in the nearish future.

They said that, although they can't be sure, they don't think they'll
be interested in arch hooks in the scheduling code and that, actually,
having them risk being more harmful than helpful.

Of course, that does not mean that we shouldn't add them for the sake
of this patch, if we can't avoid doing that. But if we can avoid them,
that is perhaps one more reason for doing things that way.

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



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

[Xen-devel] [PATCH v2] xl: log an error if libxl_cpupool_destroy() fails

[Dario Faggioli]

In fact, right now, failing at destroying a cpupool is just
not reported to the user in any explicit way.

Let's log an error, as it is customary for xl in these cases.

Signed-off-by: Dario Faggioli 
Reviewed-by: Juergen Gross 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes from v1:
 * avoid changing the return code to EXIT_SUCCESS/FAILURE;
   that is being taken care of in another series anyway.
---
 tools/libxl/xl_cmdimpl.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 646b281..09a6bd7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7584,8 +7584,10 @@ int main_cpupooldestroy(int argc, char **argv)
 return 1;
 }
 
-if (libxl_cpupool_destroy(ctx, poolid))
+if (libxl_cpupool_destroy(ctx, poolid)) {
+fprintf(stderr, "Can't destroy cpupool '%s'\n", pool);
 return 1;
+}
 
 return 0;
 }


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

Re: [Xen-devel] [PATCH] tools/python: Further pruning of the defuct xl bindings

[Wei Liu]

On Wed, Oct 28, 2015 at 03:55:43PM +, Andrew Cooper wrote:
> No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
> 598e97f "tools/python: remove broken xl binding"
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Wed, Oct 28, 2015 at 04:51:05PM +0100, Juergen Gross wrote:
[...]
> >>+static int xc_dom_alloc_pad(struct xc_dom_image *dom, xen_vaddr_t end)
> >>+{
> >>+unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
> >>+xen_pfn_t pages;
> >>+
> >>+if ( end & (page_size - 1) )
> >>  {
> >>  xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> >>   "%s: segment start isn't page aligned (0x%" PRIx64 
> >> ")",
> >
> >"segment end"?
> 
> No. This function is called to add a padding allocation before the start
> of a new segment, which has to start at page boundary. Maybe a comment
> should clarify this. :-)
> 

Heh, I worked out this function was used to add padding segment but
was confused by the dissonance.

A simpler solution might be just change "end" to "start"? I think it is
sensible because it is the start of the padding.

In any case, it's up to you. :-)

Wei.

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

Re: [Xen-devel] [PATCH RFC] tools/ocaml/xb: Correct calculations of data/space the ring

[Samuel Thibault]

Andrew Cooper, le Wed 28 Oct 2015 16:05:36 +, a écrit :
> @@ -62,22 +62,32 @@ CAMLprim value ml_interface_read(value ml_interface,
>  
>   xen_mb();
>  
> - if ((prod - cons) > XENSTORE_RING_SIZE)
> + if (((prod - cons) > XENSTORE_RING_SIZE) ||
> +((cons - prod) < -XENSTORE_RING_SIZE))

prod and cons are uint32_t, so the difference will still be unsigned.
IIRC the test is not bogus even when prod wraps around, (prod - cons)
will still correctly be the difference between both, modulo 2^32.

Indeed, the read side also needs the same two-memcpy fix.

> + /* Check for any pending data at all. */
> + total_data = prod - cons;
> + if (total_data == 0) {
...
> + else if (total_data > len)
> + /* Some data - make a partial read. */
> + len = total_data;
> +
> + /* Check whether data crosses the end of the ring. */
> + data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
> + if (len <= data)
> + /* Data within the remaining part of the ring. */
> + memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
> + else {
> + /* Data crosses the ring boundary. Read both halves. */
> + memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
> + memcpy(buffer + data, intf->req, len - data);
> + }
> +

That looks right and nice-looking to me.

>   xen_mb();
>   intf->req_cons += len;
>   result = len;
> @@ -100,7 +110,7 @@ CAMLprim value ml_interface_write(value ml_interface,
>  
>   struct xenstore_domain_interface *intf = interface->addr;
>   XENSTORE_RING_IDX cons, prod;
> - int can_write;
> + int total_space, space;
>   uint32_t connection;
>  
>   cons = *(volatile uint32_t*)&intf->rsp_cons;
> @@ -111,17 +121,33 @@ CAMLprim value ml_interface_write(value ml_interface,
>   caml_raise_constant(*caml_named_value("Xb.Reconnect"));
>  
>   xen_mb();
> - if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
> +
> + if (((prod - cons) > XENSTORE_RING_SIZE) ||
> +((cons - prod) < -XENSTORE_RING_SIZE))

Ditto.

> + /* Check for space to write the full message. */
> + total_space = prod - cons;
> + if (total_space == 0) {

Shouldn't that be total_space == XENSTORE_RING_SIZE?

> + /* No space at all - exit having done nothing. */
>   result = 0;
>   goto exit;
>   }
> + else if (total_space < len)
> + /* Some space - make a partial write. */
> + len = total_space;
> +
> + /* Check for space until the ring wraps. */
> + space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
> + if (len <= space )
> + /* Message fits inside the remaining part of the ring. */
> + memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
> + else {
> + /* Message wraps around the end of the ring. Write both halves. 
> */
> + memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, space);
> + memcpy(intf->rsp, buffer + space, len - space);
> + }

That looks right and nicer-looking than my attempt :)

Samuel

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

Re: [Xen-devel] [PATCH v3 7/9] libxc: split p2m allocation in domain builder from other magic pages

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:16PM +0200, Juergen Gross wrote:
> Carve out the p2m list allocation from the .alloc_magic_pages hook of
> the domain builder in order to prepare allocating the p2m list outside
> of the initial kernel mapping. This will be needed to support loading
> domains with huge memory (>512 GB).
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Ian Campbell 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH RFC] tools/ocaml/xb: Correct calculations of data/space the ring

[Andrew Cooper]

ml_interface_{read,write}() would miscalculate the quantity of
data/space in the ring if it crossed the ring boundary, and incorrectly
return a short read/write.

This causes a protocol stall, as either side of the ring ends up waiting
for what they believe to be the other side needing to take the next
action.

Correct the calculations to cope with crossing the ring boundary.

In addition, correct the error detection.  It is a hard error if the
producer index gets more than a ring size ahead of the consumer, or if
the consumer ever overtakes the producer.

Signed-off-by: Andrew Cooper 
---
RFC as untested yet, although testing is lined up.  Presented for early
review/nitpicking.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: David Scott 
CC: Samuel Thibault 
---
 tools/ocaml/libs/xb/xs_ring_stubs.c | 68 +
 1 file changed, 47 insertions(+), 21 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
b/tools/ocaml/libs/xb/xs_ring_stubs.c
index fd561a2..67e6269 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -50,7 +50,7 @@ CAMLprim value ml_interface_read(value ml_interface,
 
struct xenstore_domain_interface *intf = interface->addr;
XENSTORE_RING_IDX cons, prod; /* offsets only */
-   int to_read;
+   int total_data, data;
uint32_t connection;
 
cons = *(volatile uint32_t*)&intf->req_cons;
@@ -62,22 +62,32 @@ CAMLprim value ml_interface_read(value ml_interface,
 
xen_mb();
 
-   if ((prod - cons) > XENSTORE_RING_SIZE)
+   if (((prod - cons) > XENSTORE_RING_SIZE) ||
+((cons - prod) < -XENSTORE_RING_SIZE))
caml_failwith("bad connection");
 
-   if (prod == cons) {
+   /* Check for any pending data at all. */
+   total_data = prod - cons;
+   if (total_data == 0) {
+   /* No pending data at all. */
result = 0;
goto exit;
}
-   cons = MASK_XENSTORE_IDX(cons);
-   prod = MASK_XENSTORE_IDX(prod);
-   if (prod > cons)
-   to_read = prod - cons;
-   else
-   to_read = XENSTORE_RING_SIZE - cons;
-   if (to_read < len)
-   len = to_read;
-   memcpy(buffer, intf->req + cons, len);
+   else if (total_data > len)
+   /* Some data - make a partial read. */
+   len = total_data;
+
+   /* Check whether data crosses the end of the ring. */
+   data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
+   if (len <= data)
+   /* Data within the remaining part of the ring. */
+   memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
+   else {
+   /* Data crosses the ring boundary. Read both halves. */
+   memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
+   memcpy(buffer + data, intf->req, len - data);
+   }
+
xen_mb();
intf->req_cons += len;
result = len;
@@ -100,7 +110,7 @@ CAMLprim value ml_interface_write(value ml_interface,
 
struct xenstore_domain_interface *intf = interface->addr;
XENSTORE_RING_IDX cons, prod;
-   int can_write;
+   int total_space, space;
uint32_t connection;
 
cons = *(volatile uint32_t*)&intf->rsp_cons;
@@ -111,17 +121,33 @@ CAMLprim value ml_interface_write(value ml_interface,
caml_raise_constant(*caml_named_value("Xb.Reconnect"));
 
xen_mb();
-   if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
+
+   if (((prod - cons) > XENSTORE_RING_SIZE) ||
+((cons - prod) < -XENSTORE_RING_SIZE))
+   caml_failwith("bad connection");
+
+   /* Check for space to write the full message. */
+   total_space = prod - cons;
+   if (total_space == 0) {
+   /* No space at all - exit having done nothing. */
result = 0;
goto exit;
}
-   if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
-   can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
-   else 
-   can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
-   if (can_write < len)
-   len = can_write;
-   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   else if (total_space < len)
+   /* Some space - make a partial write. */
+   len = total_space;
+
+   /* Check for space until the ring wraps. */
+   space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
+   if (len <= space )
+   /* Message fits inside the remaining part of the ring. */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   else {
+   /* Message wraps around the end of the ring. Write both halves. 
*/
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, space);
+   memcpy(intf->rsp, buffer + space, len - space);

Re: [Xen-devel] [PATCH v3 6/9] libxc: create unmapped initrd in domain builder if supported

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:15PM +0200, Juergen Gross wrote:
> In case the kernel of a new pv-domU indicates it is supporting an
> unmapped initrd, don't waste precious virtual space for the initrd,
> but allocate only guest physical memory for it.
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxc/include/xc_dom.h |  5 +
>  tools/libxc/xc_dom_core.c| 19 +--
>  tools/libxc/xc_dom_x86.c |  8 
>  3 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index b0120a6..fa772a9 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -94,6 +94,11 @@ struct xc_dom_image {
>  xen_pfn_t pfn_alloc_end;
>  xen_vaddr_t virt_alloc_end;
>  xen_vaddr_t bsd_symtab_start;
> +
> +/* initrd parameters as specified in start_info page */
> +unsigned long initrd_start;
> +unsigned long initrd_len;
> +
>  unsigned int alloc_bootstack;
>  xen_vaddr_t virt_pgtab_end;
>  
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 8e1e17f..15e9fa3 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -1041,6 +1041,7 @@ static int xc_dom_build_ramdisk(struct xc_dom_image 
> *dom)
>  int xc_dom_build_image(struct xc_dom_image *dom)
>  {
>  unsigned int page_size;
> +bool unmapped_initrd;
>  
>  DOMPRINTF_CALLED(dom->xch);
>  
> @@ -1064,11 +1065,15 @@ int xc_dom_build_image(struct xc_dom_image *dom)
>  if ( dom->kernel_loader->loader(dom) != 0 )
>  goto err;
>  
> -/* load ramdisk */
> -if ( dom->ramdisk_blob )
> +/* Load ramdisk if initial mapping required. */
> +unmapped_initrd = dom->parms.unmapped_initrd && !dom->ramdisk_seg.vstart;

A minor suggestion, the comment is describing the reverse logic of the
statement that immediately follows it, can you make the comment and
statement match?

I think I manage to work this out: if ramdisk_seg.vstart is set that
means upper layer wants the ramdisk to be mapped at that address (ARM is
doing that), so in that case even if kernel supports unmapped initrd we
should still map the ramdisk. Correct me if I'm wrong.

The rest of code looks correct. With that understand (and whether you
follow my minor suggestion or not):

Acked-by: Wei Liu 

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

[Xen-devel] [seabios test] 63333: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63266

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 seabios  9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
baseline version:
 seabios  234210135f07cf29f8fbee687ef7bd8adcf566ef

Last test of basis63266  2015-10-23 15:41:34 Z5 days
Failing since 63319  2015-10-26 13:41:36 Z2 days2 attempts
Testing same since6  2015-10-27 13:31:29 Z1 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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=seabios
+ revision=9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
+ . ./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 seabios 
9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
+ branch=seabios
+ revision=9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ : tested/2.6.39.x
+ . ./ap-common
++ 

Re: [Xen-devel] [PATCH v12 3/3] iommu: add rmrr Xen command line option for extra rmrrs

[Jan Beulich]

>>> On 27.10.15 at 21:36,  wrote:
> +static void __init add_extra_rmrr(void)
> +{
> +struct acpi_rmrr_unit *acpi_rmrr;
> +struct acpi_rmrr_unit *rmrru;
> +unsigned int dev, seg, i;
> +unsigned long pfn;
> +bool_t overlap;
> +
> +for ( i = 0; i < nr_rmrr; i++ )
> +{
> +if ( extra_rmrr_units[i].base_pfn > extra_rmrr_units[i].end_pfn )
> +{
> +printk(XENLOG_ERR VTDPREFIX
> +   "Invalid RMRR Range "ERMRRU_FMT"\n",
> +   ERMRRU_ARG(extra_rmrr_units[i]));
> +continue;
> +}
> +
> +if ( extra_rmrr_units[i].end_pfn - extra_rmrr_units[i].base_pfn >=
> + MAX_EXTRA_RMRR_PAGES )
> +{
> +printk(XENLOG_ERR VTDPREFIX
> +   "RMRR range "ERMRRU_FMT" exceeds 
> "__stringify(MAX_EXTRA_RMRR_PAGES)" pages\n",
> +   ERMRRU_ARG(extra_rmrr_units[i]));
> +continue;
> +}
> +
> +overlap = 0;
> +list_for_each_entry(rmrru, &acpi_rmrr_units, list)
> +{
> +if ( pfn_to_paddr(extra_rmrr_units[i].base_pfn) < 
> rmrru->end_address &&
> + rmrru->base_address < 
> pfn_to_paddr(extra_rmrr_units[i].end_pfn + 1) )

Aren't both ranges inclusive? I.e. shouldn't the first one be <= (and
the second one could be <= too when dropping the +1), matching
the check acpi_parse_one_rmrr() does?

> +{
> +printk(XENLOG_ERR VTDPREFIX
> +   "Overlapping RMRRs: "ERMRRU_FMT" and [%lx-%lx]\n",
> +   ERMRRU_ARG(extra_rmrr_units[i]),
> +   paddr_to_pfn(rmrru->base_address),
> +   paddr_to_pfn(rmrru->end_address));
> +overlap = 1;
> +break;
> +}
> +}
> +/* Don't add overlapping RMRR. */
> +if ( overlap )
> +continue;
> +
> +pfn = extra_rmrr_units[i].base_pfn;
> +do
> +{
> +if ( !mfn_valid(pfn) )
> +{
> +printk(XENLOG_ERR VTDPREFIX
> +   "Invalid pfn in RMRR range "ERMRRU_FMT"\n",
> +   ERMRRU_ARG(extra_rmrr_units[i]));
> +break;
> +}
> +} while ( pfn++ < extra_rmrr_units[i].end_pfn );
> +
> +/* Invalid pfn in range as the loop ended before end_pfn was 
> reached. */
> +if ( pfn <= extra_rmrr_units[i].end_pfn )
> +continue;
> +
> +acpi_rmrr = xzalloc(struct acpi_rmrr_unit);
> +if ( !acpi_rmrr )
> +return;
> +
> +acpi_rmrr->scope.devices = xmalloc_array(u16,
> + 
> extra_rmrr_units[i].dev_count);
> +if ( !acpi_rmrr->scope.devices )
> +{
> +xfree(acpi_rmrr);
> +return;
> +}
> +
> +seg = 0;
> +for ( dev = 0; dev < extra_rmrr_units[i].dev_count; dev++ )
> +{
> +acpi_rmrr->scope.devices[dev] = extra_rmrr_units[i].sbdf[dev];
> +seg = seg | PCI_SEG(extra_rmrr_units[i].sbdf[dev]);

Once again - |= please.

> +}
> +if ( seg != PCI_SEG(extra_rmrr_units[i].sbdf[0]) )
> +{
> +printk(XENLOG_ERR VTDPREFIX
> +   "Segments are not equal for RMRR range "ERMRRU_FMT"\n",
> +   ERMRRU_ARG(extra_rmrr_units[i]));
> +scope_devices_free(&acpi_rmrr->scope);
> +xfree(acpi_rmrr);
> +continue;
> +}
> +
> +acpi_rmrr->segment = seg;
> +acpi_rmrr->base_address = pfn_to_paddr(extra_rmrr_units[i].base_pfn);
> +acpi_rmrr->end_address = pfn_to_paddr(extra_rmrr_units[i].end_pfn + 
> 1);

And this seems wrong too, unless I'm mistaken with the inclusive-ness.

Jan


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

Re: [Xen-devel] [PATCH] tools/python: Further pruning of the defuct xl bindings

[Andrew Cooper]

On 28/10/15 15:55, Andrew Cooper wrote:
> No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
> 598e97f "tools/python: remove broken xl binding"

In fact, this fixes a build error introduced with 598e97f

make -C python all
make[2]: Entering directory '/local/xen.git/tools/python'
PYTHONPATH=/local/xen.git/tools/python/../../tools/libxl python genwrap.py \
/local/xen.git/tools/python/../../tools/libxl/libxl_types.idl \
xen/lowlevel/xl/_pyxl_types.h \
xen/lowlevel/xl/_pyxl_types.c
Parsing /local/xen.git/tools/python/../../tools/libxl/libxl_types.idl
Traceback (most recent call last):
  File "genwrap.py", line 254, in 
f = open(decls, 'w')
IOError: [Errno 2] No such file or directory:
'xen/lowlevel/xl/_pyxl_types.h'
Makefile:12: recipe for target 'build' failed

which occurs when the directory tools/python/xen/lowlevel/xl doesn't exist.

~Andrew

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

[Xen-devel] [PATCH] tools/python: Further pruning of the defuct xl bindings

[Andrew Cooper]

No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
598e97f "tools/python: remove broken xl binding"

Signed-off-by: Andrew Cooper 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/python/Makefile   |   7 +-
 tools/python/genwrap.py | 332 
 2 files changed, 1 insertion(+), 338 deletions(-)
 delete mode 100644 tools/python/genwrap.py

diff --git a/tools/python/Makefile b/tools/python/Makefile
index 0395e50..2363537 100644
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -7,12 +7,7 @@ all: build
 PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)
 
 .PHONY: build
-build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-   $(XEN_ROOT)/tools/libxl/idl.py
-   PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
-   $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-   xen/lowlevel/xl/_pyxl_types.h \
-   xen/lowlevel/xl/_pyxl_types.c
+build:
CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
deleted file mode 100644
index 56fb7a4..000
--- a/tools/python/genwrap.py
+++ /dev/null
@@ -1,332 +0,0 @@
-#!/usr/bin/python
-
-import sys,os
-
-import idl
-
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, 
TYPE_AGGREGATE) = range(7)
-
-def py_type(ty):
-if ty == idl.bool:
-return TYPE_BOOL
-if ty.typename == "libxl_defbool":
-return TYPE_DEFBOOL
-if isinstance(ty, idl.Enumeration):
-return TYPE_UINT
-if isinstance(ty, idl.Number):
-if ty.signed:
-return TYPE_INT
-else:
-return TYPE_UINT
-if isinstance(ty, idl.Array):
-return TYPE_ARRAY
-if isinstance(ty, idl.Aggregate):
-return TYPE_AGGREGATE
-if ty == idl.string:
-return TYPE_STRING
-return None
-
-def py_wrapstruct(ty):
-l = []
-l.append('typedef struct {')
-l.append('PyObject_HEAD;')
-l.append('%s obj;'%ty.typename);
-l.append('}Py_%s;'%ty.rawname)
-l.append('')
-return "\n".join(l) + "\n"
-
-def fsanitize(name):
-"Sanitise a function name given a C type"
-ret = '_'.join(name.split())
-return ret.replace('*', 'ptr')
-
-def py_decls(ty):
-l = []
-if isinstance(ty, idl.Aggregate):
-l.append('_hidden Py_%s *Py%s_New(void);\n'%(ty.rawname, ty.rawname))
-l.append('_hidden int Py%s_Check(PyObject *self);\n'%ty.rawname)
-for f in ty.fields:
-if py_type(f.type) is not None:
-continue
-if py_type(f.type) == TYPE_DEFBOOL:
-continue
-if ty.marshal_out():
-l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
-fsanitize(f.type.typename), f.type.typename, f.name))
-if ty.marshal_in():
-l.append('_hidden int attrib__%s_set(PyObject *v, %s *%s);'%(\
-fsanitize(f.type.typename), f.type.typename, f.name))
-return '\n'.join(l) + "\n"
-
-def py_attrib_get(ty, f):
-t = py_type(f.type)
-l = []
-l.append('static PyObject *py_%s_%s_get(Py_%s *self, void 
*priv)'%(ty.rawname, f.name, ty.rawname))
-l.append('{')
-if t == TYPE_BOOL:
-l.append('PyObject *ret;')
-l.append('ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
-l.append('Py_INCREF(ret);')
-l.append('return ret;')
-elif t == TYPE_DEFBOOL:
-l.append('return genwrap__defbool_get(&self->obj.%s);'%f.name)
-elif t == TYPE_INT:
-l.append('return genwrap__ll_get(self->obj.%s);'%f.name)
-elif t == TYPE_UINT:
-l.append('return genwrap__ull_get(self->obj.%s);'%f.name)
-elif t == TYPE_STRING:
-l.append('return genwrap__string_get(&self->obj.%s);'%f.name)
-elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
-l.append('PyErr_SetString(PyExc_NotImplementedError, "Getting 
%s");'%ty.typename)
-l.append('return NULL;')
-else:
-tn = f.type.typename
-l.append('return attrib__%s_get((%s 
*)&self->obj.%s);'%(fsanitize(tn), tn, f.name))
-l.append('}')
-return '\n'.join(l) + "\n\n"
-
-def py_attrib_set(ty, f):
-t = py_type(f.type)
-l = []
-l.append('static int py_%s_%s_set(Py_%s *self, PyObject *v, void 
*priv)'%(ty.rawname, f.name, ty.rawname))
-l.append('{')
-if t == TYPE_BOOL:
-l.append('self->obj.%s = (NULL == v || Py_None == v || Py_False == 
v) ? 0 : 1;'%f.name)
-l.append('return 0;')
-elif t == TYPE_DEFBOOL:
-l.append('return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
-elif t == TYPE_UINT or t == TYPE_INT:
-l.append('%slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
-l.append('int ret;')
-if t == TYPE_UINT:
-l.appen

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Jan Beulich]

>>> On 28.10.15 at 16:44,  wrote:
> On 27/10/15 08:05, Jan Beulich wrote:
> On 26.10.15 at 19:08,  wrote:
>>> However, IIUC, the get_xen_guest_handle is only exposed to the tools and
>>> therefore possible to modify it in order to pass the type. Am I wrong?
>>> FWIW, I haven't seen any usage in the tools directory.
>> 
>> Indeed. Rather than worrying about getting it right, let's just drop it.
>> Patch sent a minute ago.
> 
> On the same note, is there any reason we want to expose
> XEN_GUEST_HANDLE_PARAM to the guest?
> 
> It has been introduced with ARM to represent a guest pointer as an
> hypercall pointer and only used within Xen to differentiate 32bit vs
> 64bit build.

I don't see a need for it to be exposed, but I'd like the ARM folks
who introduced it (Stefano iirc) confirm that.

Jan


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

Re: [Xen-devel] [PATCH v3 2/9] xen: add generic flag to elf_dom_parms indicating support of unmapped initrd

[Jan Beulich]

>>> On 13.10.15 at 15:11,  wrote:
> Support of an unmapped initrd is indicated by the kernel of the domain
> via elf notes. In order not to have to use raw elf data in the tools
> for support of an unmapped initrd add a flag to the parsed data area
> to indicate the kernel supporting this feature.
> 
> Switch using this flag in the hypervisor domain builder.
> 
> Suggested-by: Ian Campbell 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v3 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 10/28/2015 04:32 PM, Wei Liu wrote:

On Tue, Oct 13, 2015 at 03:11:10PM +0200, Juergen Gross wrote:

Guest memory allocation in the domain builder of libxc is done via
virtual addresses only. In order to be able to support preallocated
areas not virtually mapped reorganize the memory allocator to keep
track of allocated pages globally and in allocated segments.

This requires an interface change of the allocate callback of the
domain builder which currently is using the last mapped virtual
address as a parameter. This is no problem as the only user of this
callback is stubdom/grub/kexec.c using this virtual address to
calculate the last used pfn.

Signed-off-by: Juergen Gross 
---
  stubdom/grub/kexec.c |   6 +--
  tools/libxc/include/xc_dom.h |  11 +++--
  tools/libxc/xc_dom_core.c| 101 +--
  3 files changed, 75 insertions(+), 43 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 0b2f4f3..2300318 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -100,9 +100,9 @@ static void do_exchange(struct xc_dom_image *dom, xen_pfn_t 
target_pfn, xen_pfn_
  dom->p2m_host[target_pfn] = source_mfn;
  }

-int kexec_allocate(struct xc_dom_image *dom, xen_vaddr_t up_to)
+int kexec_allocate(struct xc_dom_image *dom)
  {
-unsigned long new_allocated = (up_to - dom->parms.virt_base) / PAGE_SIZE;
+unsigned long new_allocated = dom->pfn_alloc_end - dom->rambase_pfn;
  unsigned long i;

  pages = realloc(pages, new_allocated * sizeof(*pages));
@@ -319,8 +319,6 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char

  /* Make sure the bootstrap page table does not RW-map any of our current
   * page table frames */
-kexec_allocate(dom, dom->virt_pgtab_end);
-


Does this mean pvgrub is now able to use this shiny new feature?


That's the plan. I have to admit I didn't test this. And don't mix this
up with grub-xen (I'm just working on that beast).




  if ( (rc = xc_dom_update_guest_p2m(dom))) {
  grub_printf("xc_dom_update_guest_p2m returned %d\n", rc);
  errnum = ERR_BOOT_FAILURE;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..878dc52 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -29,6 +29,7 @@ struct xc_dom_seg {
  xen_vaddr_t vstart;
  xen_vaddr_t vend;
  xen_pfn_t pfn;
+xen_pfn_t pages;
  };

  struct xc_dom_mem {
@@ -90,6 +91,7 @@ struct xc_dom_image {
  xen_pfn_t xenstore_pfn;
  xen_pfn_t shared_info_pfn;
  xen_pfn_t bootstack_pfn;
+xen_pfn_t pfn_alloc_end;
  xen_vaddr_t virt_alloc_end;
  xen_vaddr_t bsd_symtab_start;

@@ -177,7 +179,7 @@ struct xc_dom_image {
  /* kernel loader */
  struct xc_dom_arch *arch_hooks;
  /* allocate up to virt_alloc_end */


I think you need to update this comment, too.


Hmm, yes.




-int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+int (*allocate) (struct xc_dom_image * dom);

  /* Container type (HVM or PV). */
  enum {
@@ -361,14 +363,11 @@ static inline void *xc_dom_seg_to_ptr_pages(struct 
xc_dom_image *dom,
struct xc_dom_seg *seg,
xen_pfn_t *pages_out)
  {
-xen_vaddr_t segsize = seg->vend - seg->vstart;
-unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (segsize + page_size - 1) / page_size;
  void *retval;

-retval = xc_dom_pfn_to_ptr(dom, seg->pfn, pages);
+retval = xc_dom_pfn_to_ptr(dom, seg->pfn, seg->pages);

-*pages_out = retval ? pages : 0;
+*pages_out = retval ? seg->pages : 0;
  return retval;
  }

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fbe4464..b1d7890 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -535,56 +535,75 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image 
*dom, xen_pfn_t pfn,
  return phys->ptr;
  }

-int xc_dom_alloc_segment(struct xc_dom_image *dom,
- struct xc_dom_seg *seg, char *name,
- xen_vaddr_t start, xen_vaddr_t size)
+static int xc_dom_chk_alloc_pages(struct xc_dom_image *dom, char *name,
+  xen_pfn_t pages)
  {
  unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (size + page_size - 1) / page_size;
-xen_pfn_t pfn;
-void *ptr;

-if ( start == 0 )
-start = dom->virt_alloc_end;
+if ( pages > dom->total_pages || /* multiple test avoids overflow probs */
+ dom->pfn_alloc_end - dom->rambase_pfn > dom->total_pages ||
+ pages > dom->total_pages - dom->pfn_alloc_end + dom->rambase_pfn )
+{
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: segment %s too large (0x%"PRIpfn" > "
+ "0x%"PRIpfn" - 0x%"PRIpfn" pages)", __FUNCTION__, name,
+ 

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Julien Grall]

On 27/10/15 08:05, Jan Beulich wrote:
 On 26.10.15 at 19:08,  wrote:
>> However, IIUC, the get_xen_guest_handle is only exposed to the tools and
>> therefore possible to modify it in order to pass the type. Am I wrong?
>> FWIW, I haven't seen any usage in the tools directory.
> 
> Indeed. Rather than worrying about getting it right, let's just drop it.
> Patch sent a minute ago.

On the same note, is there any reason we want to expose
XEN_GUEST_HANDLE_PARAM to the guest?

It has been introduced with ARM to represent a guest pointer as an
hypercall pointer and only used within Xen to differentiate 32bit vs
64bit build.

XEN_GUEST_HANDLE will be different when built for 32-bit/64-bit as will
not really have any meaning from the guest POV.

Regards,


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1] Add build-id to XENVER hypercall.

[Konrad Rzeszutek Wilk]

On Fri, Oct 09, 2015 at 09:14:00AM -0600, Jan Beulich wrote:
> >>> On 09.10.15 at 15:25,  wrote:
> > On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> >> On 09/10/15 09:17, Jan Beulich wrote:
> >>  On 09.10.15 at 04:56,  wrote:
> >> >> However they also change the behavior of the existing hypercall
> >> >> for XENVER_[compile_info|changeset|commandline] and make them
> >> >> dom0 accessible. This is if XSM is built in or not (though with
> >> >> XSM one can expose it to a guest if desired).
> >> > Wasn't the outcome of the previous discussion that we should not
> >> > alter default behavior for existing sub-ops?
> >> 
> >> I raised a worry that some guests might break if they suddenly have
> >> access to this information cut off.
> > 
> > Let me double-confirm that the guests are OK with this being
> > gone. I did ran tests to see if the worked, but hadn't actually tried
> > acessing (/sys/hypervisor/xen*) the values.
> 
> Well, this is the kind of thing you can't find out by testing _some_
> guest(s) - you'd need to test with all possible ones, which of course
> is not feasible. Hence we need to be very conservative when

I was thinking to test:

F19-64 F19-32 F17-64 F17-32 F16-32
F16-64 F15-32 F15-64 NetBSD FreeBSD RHEL5-64 RHEL5-32 SLES11-32 SLES12-32
OL6_X86_64_PVHVM OL6_X86_64_PV OL5_X86_64_PVHVM Win2K (with SuSE PV drivers)
WinXP (with Windows GPL drivers) and Windows 7 (with Windows GPL), SOL12

And see what happens when those are not available (poke in /sysfs or whatever
I can)

> deciding to restrict part of a so far guest-kind-indifferent ABI.

Right, so only three of them are off.

Perhaps an another option would be to return success and fill out the
value with an empty string?

That actually sounds nicer.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH v3 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:10PM +0200, Juergen Gross wrote:
> Guest memory allocation in the domain builder of libxc is done via
> virtual addresses only. In order to be able to support preallocated
> areas not virtually mapped reorganize the memory allocator to keep
> track of allocated pages globally and in allocated segments.
> 
> This requires an interface change of the allocate callback of the
> domain builder which currently is using the last mapped virtual
> address as a parameter. This is no problem as the only user of this
> callback is stubdom/grub/kexec.c using this virtual address to
> calculate the last used pfn.
> 
> Signed-off-by: Juergen Gross 
> ---
>  stubdom/grub/kexec.c |   6 +--
>  tools/libxc/include/xc_dom.h |  11 +++--
>  tools/libxc/xc_dom_core.c| 101 
> +--
>  3 files changed, 75 insertions(+), 43 deletions(-)
> 
> diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
> index 0b2f4f3..2300318 100644
> --- a/stubdom/grub/kexec.c
> +++ b/stubdom/grub/kexec.c
> @@ -100,9 +100,9 @@ static void do_exchange(struct xc_dom_image *dom, 
> xen_pfn_t target_pfn, xen_pfn_
>  dom->p2m_host[target_pfn] = source_mfn;
>  }
>  
> -int kexec_allocate(struct xc_dom_image *dom, xen_vaddr_t up_to)
> +int kexec_allocate(struct xc_dom_image *dom)
>  {
> -unsigned long new_allocated = (up_to - dom->parms.virt_base) / PAGE_SIZE;
> +unsigned long new_allocated = dom->pfn_alloc_end - dom->rambase_pfn;
>  unsigned long i;
>  
>  pages = realloc(pages, new_allocated * sizeof(*pages));
> @@ -319,8 +319,6 @@ void kexec(void *kernel, long kernel_size, void *module, 
> long module_size, char
>  
>  /* Make sure the bootstrap page table does not RW-map any of our current
>   * page table frames */
> -kexec_allocate(dom, dom->virt_pgtab_end);
> -

Does this mean pvgrub is now able to use this shiny new feature?

>  if ( (rc = xc_dom_update_guest_p2m(dom))) {
>  grub_printf("xc_dom_update_guest_p2m returned %d\n", rc);
>  errnum = ERR_BOOT_FAILURE;
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index e52b023..878dc52 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -29,6 +29,7 @@ struct xc_dom_seg {
>  xen_vaddr_t vstart;
>  xen_vaddr_t vend;
>  xen_pfn_t pfn;
> +xen_pfn_t pages;
>  };
>  
>  struct xc_dom_mem {
> @@ -90,6 +91,7 @@ struct xc_dom_image {
>  xen_pfn_t xenstore_pfn;
>  xen_pfn_t shared_info_pfn;
>  xen_pfn_t bootstack_pfn;
> +xen_pfn_t pfn_alloc_end;
>  xen_vaddr_t virt_alloc_end;
>  xen_vaddr_t bsd_symtab_start;
>  
> @@ -177,7 +179,7 @@ struct xc_dom_image {
>  /* kernel loader */
>  struct xc_dom_arch *arch_hooks;
>  /* allocate up to virt_alloc_end */

I think you need to update this comment, too.

> -int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
> +int (*allocate) (struct xc_dom_image * dom);
>  
>  /* Container type (HVM or PV). */
>  enum {
> @@ -361,14 +363,11 @@ static inline void *xc_dom_seg_to_ptr_pages(struct 
> xc_dom_image *dom,
>struct xc_dom_seg *seg,
>xen_pfn_t *pages_out)
>  {
> -xen_vaddr_t segsize = seg->vend - seg->vstart;
> -unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
> -xen_pfn_t pages = (segsize + page_size - 1) / page_size;
>  void *retval;
>  
> -retval = xc_dom_pfn_to_ptr(dom, seg->pfn, pages);
> +retval = xc_dom_pfn_to_ptr(dom, seg->pfn, seg->pages);
>  
> -*pages_out = retval ? pages : 0;
> +*pages_out = retval ? seg->pages : 0;
>  return retval;
>  }
>  
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index fbe4464..b1d7890 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -535,56 +535,75 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image 
> *dom, xen_pfn_t pfn,
>  return phys->ptr;
>  }
>  
> -int xc_dom_alloc_segment(struct xc_dom_image *dom,
> - struct xc_dom_seg *seg, char *name,
> - xen_vaddr_t start, xen_vaddr_t size)
> +static int xc_dom_chk_alloc_pages(struct xc_dom_image *dom, char *name,
> +  xen_pfn_t pages)
>  {
>  unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
> -xen_pfn_t pages = (size + page_size - 1) / page_size;
> -xen_pfn_t pfn;
> -void *ptr;
>  
> -if ( start == 0 )
> -start = dom->virt_alloc_end;
> +if ( pages > dom->total_pages || /* multiple test avoids overflow probs 
> */
> + dom->pfn_alloc_end - dom->rambase_pfn > dom->total_pages ||
> + pages > dom->total_pages - dom->pfn_alloc_end + dom->rambase_pfn )
> +{
> +xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
> + "%s: segment %s too large (0x%"PRIpfn" > "
> + "0x%"PRIpfn" - 0x%"PRIpfn" pages)

Re: [Xen-devel] [PATCH v3 2/9] xen: add generic flag to elf_dom_parms indicating support of unmapped initrd

[Wei Liu]

CC HV maintainers

On Tue, Oct 13, 2015 at 03:11:11PM +0200, Juergen Gross wrote:
> Support of an unmapped initrd is indicated by the kernel of the domain
> via elf notes. In order not to have to use raw elf data in the tools
> for support of an unmapped initrd add a flag to the parsed data area
> to indicate the kernel supporting this feature.
> 
> Switch using this flag in the hypervisor domain builder.
> 
> Suggested-by: Ian Campbell 
> Signed-off-by: Juergen Gross 
> ---
>  xen/arch/x86/domain_build.c| 4 ++--
>  xen/common/libelf/libelf-dominfo.c | 3 +++
>  xen/include/xen/libelf.h   | 1 +
>  3 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
> index c2ef87a..d02dc4b 100644
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -353,7 +353,7 @@ static unsigned long __init compute_dom0_nr_pages(
>  
>  vstart = parms->virt_base;
>  vend = round_pgup(parms->virt_kend);
> -if ( !parms->elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num )
> +if ( !parms->unmapped_initrd )
>  vend += round_pgup(initrd_len);
>  end = vend + nr_pages * sizeof_long;
>  
> @@ -1037,7 +1037,7 @@ int __init construct_dom0(
>  v_start  = parms.virt_base;
>  vkern_start  = parms.virt_kstart;
>  vkern_end= parms.virt_kend;
> -if ( parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num )
> +if ( parms.unmapped_initrd )
>  {
>  vinitrd_start  = vinitrd_end = 0;
>  vphysmap_start = round_pgup(vkern_end);
> diff --git a/xen/common/libelf/libelf-dominfo.c 
> b/xen/common/libelf/libelf-dominfo.c
> index 3de1c23..c9243e4 100644
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -190,6 +190,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
>  case XEN_ELFNOTE_INIT_P2M:
>  parms->p2m_base = val;
>  break;
> +case XEN_ELFNOTE_MOD_START_PFN:
> +parms->unmapped_initrd = !!val;
> +break;
>  case XEN_ELFNOTE_PADDR_OFFSET:
>  parms->elf_paddr_offset = val;
>  break;
> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
> index de788c7..6da4cc0 100644
> --- a/xen/include/xen/libelf.h
> +++ b/xen/include/xen/libelf.h
> @@ -423,6 +423,7 @@ struct elf_dom_parms {
>  char loader[16];
>  enum xen_pae_type pae;
>  bool bsd_symtab;
> +bool unmapped_initrd;
>  uint64_t virt_base;
>  uint64_t virt_entry;
>  uint64_t virt_hypercall;
> -- 
> 2.1.4

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

Re: [Xen-devel] [PATCH v3 5/9] libxc: use domain builder architecture private data for x86 pv domains

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:14PM +0200, Juergen Gross wrote:
> Move some data private to the x86 domain builder to the private data
> section. Remove extra_pages as they are used nowhere.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 4/9] libxc: introduce domain builder architecture specific data

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:13PM +0200, Juergen Gross wrote:
> Reorganize struct xc_dom_image to contain a pointer to domain builder
> architecture specific private data. This will abstract the architecture
> or domain type specific data from the general used data.
> 
> The new area is allocated as soon as the domain type is known.
> 
> Signed-off-by: Juergen Gross 

The code looks correct to me, so:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 3/9] libxc: rename domain builder count_pgtables to alloc_pgtables

[Wei Liu]

On Tue, Oct 13, 2015 at 03:11:12PM +0200, Juergen Gross wrote:
> Rename the count_pgtables hook of the domain builder to alloc_pgtables
> and do the allocation of the guest memory for page tables inside this
> hook. This will remove the need for accessing the x86 specific pgtables
> member of struct xc_dom_image in the generic domain builder code.
> 
> Signed-off-by: Juergen Gross 

The code looks correct to me.

With the understanding this refactoring is in preparation for later
patch.

Acked-by: Wei Liu 

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

Re: [Xen-devel] struct paging_mode's {write, cmpxchg}_guest_entry and guest_{map, get_eff}_l1e

[Tim Deegan]

At 09:10 -0600 on 27 Oct (1445937057), Jan Beulich wrote:
> >>> On 15.10.15 at 11:39,  wrote:
> > At 02:56 -0600 on 15 Oct (144484), Jan Beulich wrote:
> >> what's the reason that these aren't in struct shadow_paging_mode
> >> instead? They're only being used by shadow code, and I can't see
> >> an abstract reason why HAP would ever want to use them.
> > 
> > That seems fair.  In fact AFAICT they're only called for
> > _translated-mode_ PV guests!
> > 
> > So we should just refuse to enter a translated-but-not-external paging
> > mode, since that's not maintained and almost certainly doesn't work,
> > and then these hooks can go away entirely.
> 
> Looking more closely, I think this is true for the latter two (in the
> subject), but not the former two (and indeed migration triggers
> them).

Oh, yes, I hadn't looked at those.  Yes, we need to keep
write/cmpxchg.  I would be inclined to keep them as paging-level
operations, at least as far as non-mm code is concerned.  I have no
objection to moving the function pointers into a shadow-specific
struct and having the wrapper assert that the caller is in shadow
mode.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Jan Beulich]

>>> On 28.10.15 at 14:42,  wrote:
> On 28/10/15 13:25, Jan Beulich wrote:
> On 28.10.15 at 13:55,  wrote:
>>> On 26/10/15 11:49, Jan Beulich wrote:
 This requires adjustments to the tool generating the symbol table and
 its as well as nm's invocation.

 Note: Not warning about duplicate symbols in the EFI case for now, as
 a binutils bug causes misnamed file name entries to appear in EFI
 binaries' symbol tables when the file name is longer than 18 chars.
 (Not doing so also avoids other duplicates getting printed twice.)

 Signed-off-by: Jan Beulich 
>>> Should warn_dups become fatal once the patches to fix these...
>>>
>>> Duplicate symbol 'memory.c#get_reserved_device_memory' (82d080140183
>>> != 82d080118b5b)
>>> Duplicate symbol 'platform_hypercall.c#__maddr_to_virt'
>>> (82d08023a3a2 != 82d080167e66)
>>> Duplicate symbol 'platform_hypercall.c#__virt_to_maddr'
>>> (82d08023a401 != 82d080167ec5)
>>> Duplicate symbol 'platform_hypercall.c#cpumask_check' (82d08023a489
>>> != 82d080167f4d)
>>>
>>> have been committed, to avoid accidental reintroduction?
>> They all went in already. Or are you saying you saw these on top
>> of what is in staging right now?
> 
> Current staging right now
> 
> andrewcoop@andrewcoop:/local/xen.git/xen$ git log --oneline staging^..
> 69bdd7f symbols: prefix static symbols with their source file names
> bf0d492 x86/mm: don't call HVM-only function for PV guests
> 
> However, those duplicates are from the compat code, which I didn't
> specifically take your patch 2 for.

Ah, of course - that's what that patch is for.

>>> I note that even sysv format doesn't appear to provide directory
>>> information, so we still cant distinguish duplicate static symbols in
>>> identically named source files in difference directories, but hopefully
>>> that should be very rare.
>> ... this. I actually see one with some gcc versions (an inline function
>> not expanded inline in two different cpufreq.c).
> 
> An inline function with an ASSERT/BUG or alternative by any chance?  GCC
> appears to aggressively out-of-line these, which is why had to sprinkle
> always_inline to helpers such as stac()/clac()

cpumask_first() or one of its relatives.

Jan


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

[Xen-devel] [linux-3.10 test] 63332: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 62642
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62642
 test-amd64-amd64-xl-qcow220 guest-start/debian.repeat fail REGR. vs. 62642

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62642
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62642
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 62642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxd17332ebfb5f2010ae5d3332a52df361f28ae4a8
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   24 days
Failing since 63224  2015-10-22 22:20:05 Z5 days5 attempts
Testing same since63332  2015-10-27 12:23:40 Z1 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Al Viro 
  Alexander Couzens 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Charles Keepax 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk Müller 
  Doug Ledford 
  Eric Dumazet 
  Eric W. Biederman 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Peter Anvin 
  Herbert Xu 
  Ian Abbott 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jiri Slaby 
  Joe Perches 
  Joe Stringer 
  Joe Thornber 
  Johan Hovold 
  John Covici 
  Julian Anastasov 
  Kees Cook 
  Linus Torvalds 
  Liu.Zhao 
  Mark Brown 
  Mark Salyzyn 
  Mathias Nyman 
  Mel Gorman 
  Michael Ellerman 
  Michal Hocko 
  Michel Stam 
  Mike Marciniszyn 
  Mike Snitzer 
  Mikulas Patocka 
  Namhyung Kim 
  NeilBrown 
  Nicolas Pitre 
  Nikolay Aleksandrov 
  Oleksii Berezhniak 
  Pablo Neira Ayuso 
  Paolo Bonzini 
  Paul Bolle 
  Paul Mackerras 
  Paul Mackerras 
  Pravin B Shelar 
  Ralf Baechle 
  Reyad Attiyat 
  Richard Weinberger 
  Riku Voipio 
  Riley Andrews 
  Robert Jarzmik 
  Roger Quadros 
  Roland Dreier 
  Russell King 
  Samuel Thibault 
  Shaohua Li 
  Sheng Yong 
  shengyong 
  Simon Horman 
  Stephen Smalley 
  Steve French 
  Steve French 
  Takashi Iwai 
  Tan, Jui Nee 
  Tejun Heo 
  Thomas Gleixner 
  Tom Herbert 
  Tóth Attila 
  Vincent Palatin 
  Vitaly Kuznetsov 
  Will Deacon 
  Wolfram Sang 
  Wolfram Sang 
  Yao-Wen Mao 
  Yitian Bu 
  Yitian Bu 
  Zhang Zhen 

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-pvopsfail
 build-i386-pvops pass
 build-amd64-rumpuserxen

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[David Vrabel]

On 27/10/15 17:10, Wei Liu wrote:
> When oxenstored wrote to the ring, it wrote a chunk of contiguous data.
> Originally when it tried to write across ring boundary, it returned a
> short-write when there is still room.  That led to stalling mini-os's
> xenstore thread at times.
> 
> Fix this by calling write function for a second time when the first
> write completes partially.

What happens if the 1st write is short because there is not enough
space, and the 2nd write is short because of the ring wraparound?  You
will still stall.

David

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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Andrew Cooper]

On 28/10/15 13:34, David Scott wrote:
>
>> On 27 Oct 2015, at 17:31, Andrew Cooper  wrote:
>>
>> On 27/10/15 17:28, Samuel Thibault wrote:
>>> Andrew Cooper, le Tue 27 Oct 2015 17:21:39 +, a écrit :
 as the second attempted write could return short as well.
>>> That is fine. The second attempt will only return a short write if there
>>> was really not enough room for it, which is what we want.
>> Then surely the bug is that Xs_ring.write returns short when it shouldn’t?
>
>> On 27 Oct 2015, at 17:31, Samuel Thibault  
>> wrote:
>>
>> Another way would be to make ml_interface_write write both pieces
>> instead of just a contiguous one.  The caml code would then look less
>> suspicious :)
>>
> I agree with both Andrew and Samuel that it would be a better fix if 
> Xs_ring.write (== “ml_interface_write”) wrote both pieces at once.
>
> However I believe the ‘suspicious’ OCaml patch fixes the specific issue (— or 
> have I missed something?).

Actually the suspicious OCaml is still buggy in the case that there was
a genuine short write followed by a false short write from wrapping the
ring.

>
> Last time I meddled with the C-level ring reading/writing code I didn’t get 
> it quite right. Does anyone have time to prototype what a C-level fix would 
> look like? If we’re short of time I could live with the OCaml-level fix, 
> especially since Wei has done some stress-testing (assuming everyone believes 
> it fixes the issue)

There are several bugs in that function (the remaining size calculations
are plain wrong), and Samuels patch sadly doesn't address all of them. 

I will throw a different patch together addressing all the issues I can
spot.

~Andrew

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

Re: [Xen-devel] [PATCHv2] x86/xen: add reschedule point when mapping foreign GFNs

[Boris Ostrovsky]

On 10/28/2015 09:39 AM, David Vrabel wrote:

Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.

Signed-off-by: David Vrabel 
---
v2:
- Move cond_resched() to outer loop.
---
  arch/x86/xen/mmu.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 9c479fe..ac161db 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2888,6 +2888,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
addr += range;
if (err_ptr)
err_ptr += batch;
+   cond_resched();
}
  out:
  



Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Samuel Thibault]

David Scott, le Wed 28 Oct 2015 13:34:10 +, a écrit :
> However I believe the ‘suspicious’ OCaml patch fixes the specific issue (— or 
> have I missed something?).

It does.

> Does anyone have time to prototype what a C-level fix would look like?

Here is a try, untested though.

Signed-off-by: Samuel Thibault 

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
b/tools/ocaml/libs/xb/xs_ring_stubs.c
index fd561a2..5c771d6 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -99,12 +99,12 @@ CAMLprim value ml_interface_write(value ml_interface,
int result;

struct xenstore_domain_interface *intf = interface->addr;
-   XENSTORE_RING_IDX cons, prod;
+   XENSTORE_RING_IDX cons, old_prod, prod;
int can_write;
uint32_t connection;

cons = *(volatile uint32_t*)&intf->rsp_cons;
-   prod = *(volatile uint32_t*)&intf->rsp_prod;
+   old_prod = prod = *(volatile uint32_t*)&intf->rsp_prod;
connection = *(volatile uint32_t*)&intf->connection;

if (connection != XENSTORE_CONNECTED)
@@ -116,15 +116,30 @@ CAMLprim value ml_interface_write(value ml_interface,
goto exit;
}
if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
+   {
can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
-   else
+   if (can_write < len)
+   {
+   /* Not enough room at end of ring.  Copy what we can 
first.  */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, 
can_write);
+   prod += can_write;
+   len -= can_write;
+   buffer += can_write;
+
+   /* We are now back at beginning of ring.  */
+   can_write = MASK_XENSTORE_IDX(cons) - 
MASK_XENSTORE_IDX(prod);
+   }
+   }
+   else
can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
if (can_write < len)
+   /* Real short write: not enough room.  */
len = can_write;
memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   prod += len;
xen_mb();
-   intf->rsp_prod += len;
-   result = len;
+   intf->rsp_prod = prod;
+   result = prod - old_prod;
 exit:
ml_result = Val_int(result);
CAMLreturn(ml_result);
diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
b/tools/ocaml/libs/xb/xs_ring_stubs.c
index fd561a2..5c771d6 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -99,12 +99,12 @@ CAMLprim value ml_interface_write(value ml_interface,
int result;
 
struct xenstore_domain_interface *intf = interface->addr;
-   XENSTORE_RING_IDX cons, prod;
+   XENSTORE_RING_IDX cons, old_prod, prod;
int can_write;
uint32_t connection;
 
cons = *(volatile uint32_t*)&intf->rsp_cons;
-   prod = *(volatile uint32_t*)&intf->rsp_prod;
+   old_prod = prod = *(volatile uint32_t*)&intf->rsp_prod;
connection = *(volatile uint32_t*)&intf->connection;
 
if (connection != XENSTORE_CONNECTED)
@@ -116,15 +116,30 @@ CAMLprim value ml_interface_write(value ml_interface,
goto exit;
}
if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
+   {
can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
-   else 
+   if (can_write < len)
+   {
+   /* Not enough room at end of ring.  Copy what we can 
first.  */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, 
can_write);
+   prod += can_write;
+   len -= can_write;
+   buffer += can_write;
+
+   /* We are now back at beginning of ring.  */
+   can_write = MASK_XENSTORE_IDX(cons) - 
MASK_XENSTORE_IDX(prod);
+   }
+   }
+   else
can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
if (can_write < len)
+   /* Real short write: not enough room.  */
len = can_write;
memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   prod += len;
xen_mb();
-   intf->rsp_prod += len;
-   result = len;
+   intf->rsp_prod = prod;
+   result = prod - old_prod;
 exit:
ml_result = Val_int(result);
CAMLreturn(ml_result);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Andrew Cooper]

On 28/10/15 13:25, Jan Beulich wrote:
 On 28.10.15 at 13:55,  wrote:
>> On 26/10/15 11:49, Jan Beulich wrote:
>>> This requires adjustments to the tool generating the symbol table and
>>> its as well as nm's invocation.
>>>
>>> Note: Not warning about duplicate symbols in the EFI case for now, as
>>> a binutils bug causes misnamed file name entries to appear in EFI
>>> binaries' symbol tables when the file name is longer than 18 chars.
>>> (Not doing so also avoids other duplicates getting printed twice.)
>>>
>>> Signed-off-by: Jan Beulich 
>> Should warn_dups become fatal once the patches to fix these...
>>
>> Duplicate symbol 'memory.c#get_reserved_device_memory' (82d080140183
>> != 82d080118b5b)
>> Duplicate symbol 'platform_hypercall.c#__maddr_to_virt'
>> (82d08023a3a2 != 82d080167e66)
>> Duplicate symbol 'platform_hypercall.c#__virt_to_maddr'
>> (82d08023a401 != 82d080167ec5)
>> Duplicate symbol 'platform_hypercall.c#cpumask_check' (82d08023a489
>> != 82d080167f4d)
>>
>> have been committed, to avoid accidental reintroduction?
> They all went in already. Or are you saying you saw these on top
> of what is in staging right now?

Current staging right now

andrewcoop@andrewcoop:/local/xen.git/xen$ git log --oneline staging^..
69bdd7f symbols: prefix static symbols with their source file names
bf0d492 x86/mm: don't call HVM-only function for PV guests

However, those duplicates are from the compat code, which I didn't
specifically take your patch 2 for.

>
> However - no to the question here. For one, there's nothing fatal
> about it the absence of xSplice. And even with xSplice I'm not sure
> this really should be fatal at the build stage.

For the non-xSplice case, the worst which can happen is indeed just a
harder-to-read stack trace.

However, for the xSplice case, we really should take reasonable steps to
make patching easier, and that includes avoiding duplicate symbols.

As a future user of xSplice, I would definitely like an option to fail
the hypervisor build if it will result in a hard-to-patch binary.

>  What should force
> people to at least look closely would be a runtime patch using such
> a symbol. And second, ...
>
>> I note that even sysv format doesn't appear to provide directory
>> information, so we still cant distinguish duplicate static symbols in
>> identically named source files in difference directories, but hopefully
>> that should be very rare.
> ... this. I actually see one with some gcc versions (an inline function
> not expanded inline in two different cpufreq.c).

An inline function with an ASSERT/BUG or alternative by any chance?  GCC
appears to aggressively out-of-line these, which is why had to sprinkle
always_inline to helpers such as stac()/clac()

~Andrew

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

[Xen-devel] [PATCHv2] x86/xen: add reschedule point when mapping foreign GFNs

[David Vrabel]

Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.

Signed-off-by: David Vrabel 
---
v2:
- Move cond_resched() to outer loop.
---
 arch/x86/xen/mmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 9c479fe..ac161db 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2888,6 +2888,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
addr += range;
if (err_ptr)
err_ptr += batch;
+   cond_resched();
}
 out:
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[David Scott]

> On 27 Oct 2015, at 17:31, Andrew Cooper  wrote:
> 
> On 27/10/15 17:28, Samuel Thibault wrote:
>> Andrew Cooper, le Tue 27 Oct 2015 17:21:39 +, a écrit :
>>> as the second attempted write could return short as well.
>> That is fine. The second attempt will only return a short write if there
>> was really not enough room for it, which is what we want.
> 
> Then surely the bug is that Xs_ring.write returns short when it shouldn’t?


> On 27 Oct 2015, at 17:31, Samuel Thibault  
> wrote:
> 
> Another way would be to make ml_interface_write write both pieces
> instead of just a contiguous one.  The caml code would then look less
> suspicious :)
> 

I agree with both Andrew and Samuel that it would be a better fix if 
Xs_ring.write (== “ml_interface_write”) wrote both pieces at once.

However I believe the ‘suspicious’ OCaml patch fixes the specific issue (— or 
have I missed something?).

Last time I meddled with the C-level ring reading/writing code I didn’t get it 
quite right. Does anyone have time to prototype what a C-level fix would look 
like? If we’re short of time I could live with the OCaml-level fix, especially 
since Wei has done some stress-testing (assuming everyone believes it fixes the 
issue)

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

Re: [Xen-devel] [Xen 4.7] tmem todos

[Konrad Rzeszutek Wilk]

On Wed, Oct 28, 2015 at 04:18:56PM +0800, Yang Hongyang wrote:
> On 2015年10月28日 00:26, Konrad Rzeszutek Wilk wrote:
> >Hey,
> >
> >Way back in Shenghai we had a chat about what needs to be done
> >in tmem for the 4.6 release. Things got done, but there are other
> >things that need to be done:
> >
> >  a) Migration v2 support
> >  b) Fix the toolstack (cleanup)
> >  c) tmem tze, dedup, and zlib code drop
> >  d) simplify the internal structs
> >  e) Make it work on 5TB and higher
> >  f) And finally security audit.
> >
> >In 4.6 I did an conversion of moving the sysctl related tmem
> >to the sysctl hypercall. That cleaned up the code a bit and made
> >it fit nicer in the appropiate architecture bins.
> >
> >The next step will be to follow that and actually seperate
> >the tmem C code - one file for sysctl and the other for tmem operations.
> >
> >That will allow me to focus then on the b), and c) part.
> >a) is going to be the stretch goal that I will try to get done
> >(at least an RFC). The nice side benefit is that I will be better
> >equipped to review the REMUS patches so an extra reviewer.
> 
> That's great! :)

Yeah! BTW, I haven't seen those patches lately. Any idea when
they would be posted?
> 
> >
> >
> >___
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/xen-devel
> >
> 
> -- 
> Thanks,
> Yang

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Jan Beulich]

>>> On 28.10.15 at 13:55,  wrote:
> On 26/10/15 11:49, Jan Beulich wrote:
>> This requires adjustments to the tool generating the symbol table and
>> its as well as nm's invocation.
>>
>> Note: Not warning about duplicate symbols in the EFI case for now, as
>> a binutils bug causes misnamed file name entries to appear in EFI
>> binaries' symbol tables when the file name is longer than 18 chars.
>> (Not doing so also avoids other duplicates getting printed twice.)
>>
>> Signed-off-by: Jan Beulich 
> 
> Should warn_dups become fatal once the patches to fix these...
> 
> Duplicate symbol 'memory.c#get_reserved_device_memory' (82d080140183
> != 82d080118b5b)
> Duplicate symbol 'platform_hypercall.c#__maddr_to_virt'
> (82d08023a3a2 != 82d080167e66)
> Duplicate symbol 'platform_hypercall.c#__virt_to_maddr'
> (82d08023a401 != 82d080167ec5)
> Duplicate symbol 'platform_hypercall.c#cpumask_check' (82d08023a489
> != 82d080167f4d)
> 
> have been committed, to avoid accidental reintroduction?

They all went in already. Or are you saying you saw these on top
of what is in staging right now?

However - no to the question here. For one, there's nothing fatal
about it the absence of xSplice. And even with xSplice I'm not sure
this really should be fatal at the build stage. What should force
people to at least look closely would be a runtime patch using such
a symbol. And second, ...

> I note that even sysv format doesn't appear to provide directory
> information, so we still cant distinguish duplicate static symbols in
> identically named source files in difference directories, but hopefully
> that should be very rare.

... this. I actually see one with some gcc versions (an inline function
not expanded inline in two different cpufreq.c).

> Overall, Reviewed-by: Andrew Cooper ,
> although I haven’t vetted the symbol.c changes too carefully.

Thanks.

Jan

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

Re: [Xen-devel] [PATCHv1] x86/xen: add reschedule point when mapping foreign GFNs

[Boris Ostrovsky]

On 10/27/2015 07:50 AM, David Vrabel wrote:

Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.

Signed-off-by: David Vrabel 
---
  arch/x86/xen/mmu.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 9c479fe..734fa84 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2882,6 +2882,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
mapped += done;
batch_left -= done;
index += done;
+   cond_resched();
} while (batch_left);
  
  		nr -= batch;


Shouldn't this be done in the outer (i.e. 'while (nr)') loop? The inner 
loop always processes 16 pages.


-boris

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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Andrew Cooper]

On 26/10/15 11:50, Jan Beulich wrote:
> To make it possible to tell apart the static symbols in files built a
> second for compat guest support, arrange for their source file names to
> be prefixed by a suitable path. We can't do this without explicit .file
> directives, since gcc has always been stripping paths from file names
> handed to the internally generated .file directive. However, we can
> leverage __FILE__ if we make sure the second instance gets compiled out
> of other than the very directory the wrapper sits in.
>
> Where suitable, remove the long redundant explicit inclusions of
> xen/config.h at once.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Andrew Cooper]

On 26/10/15 11:49, Jan Beulich wrote:
> This requires adjustments to the tool generating the symbol table and
> its as well as nm's invocation.
>
> Note: Not warning about duplicate symbols in the EFI case for now, as
> a binutils bug causes misnamed file name entries to appear in EFI
> binaries' symbol tables when the file name is longer than 18 chars.
> (Not doing so also avoids other duplicates getting printed twice.)
>
> Signed-off-by: Jan Beulich 

Should warn_dups become fatal once the patches to fix these...

Duplicate symbol 'memory.c#get_reserved_device_memory' (82d080140183
!= 82d080118b5b)
Duplicate symbol 'platform_hypercall.c#__maddr_to_virt'
(82d08023a3a2 != 82d080167e66)
Duplicate symbol 'platform_hypercall.c#__virt_to_maddr'
(82d08023a401 != 82d080167ec5)
Duplicate symbol 'platform_hypercall.c#cpumask_check' (82d08023a489
!= 82d080167f4d)

have been committed, to avoid accidental reintroduction?

I note that even sysv format doesn't appear to provide directory
information, so we still cant distinguish duplicate static symbols in
identically named source files in difference directories, but hopefully
that should be very rare.

Overall, Reviewed-by: Andrew Cooper ,
although I haven’t vetted the symbol.c changes too carefully.

~Andrew

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

[Xen-devel] [qemu-mainline test] 63330: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-xsm  3 host-install(3) broken REGR. vs. 63304
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken like 63304
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 63304

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 qemuu9666248a85fd889bfb6118f769e9c73039b998ed
baseline version:
 qemuubc79082e4cd12c1241fa03b0abceacf45f537740

Last test of basis63304  2015-10-25 13:30:57 Z2 days
Failing since 63317  2015-10-26 09:49:11 Z2 days2 attempts
Testing same since63330  2015-10-27 10:13:27 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Andreas Färber 
  David Marchand 
  Eduardo Habkost 
  Fam Zheng 
  Kevin Wolf 
  Lan Tianyu 
  Marc-André Lureau 
  Max Reitz 
  Olivier Matz 
  Paolo Bonzini 
  Peter Maydell 
  Stefano Stabellini 

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

[Xen-devel] Virtualization & IaaS Devroom CFP @ FOSDEM'16

[Lars Kurth]

> Begin forwarded message:
> 
> From: Mikey Ariel 
> Subject: [devroom-managers] Virtualization & IaaS Devroom CFP
> Date: 27 October 2015 23:23:50 GMT
> To: fos...@lists.fosdem.org, devroom-manag...@lists.fosdem.org, 
> iaas-virt-devr...@lists.fosdem.org
> 
> **Please forward to any project or individual that might be interested in 
> participating in this devroom!**
> 
> -
> Call for Participation
> -
> 
> The Virtualization & IaaS devroom will feature sessions around virtualization 
> and Infrastructure-as-a-Service, with topics to include open source 
> hypervisors and virtual machine managers such as KVM, Xen, bhyve, and 
> VirtualBox, and Infrastructure-as-a-Service projects such as Apache 
> CloudStack, OpenStack, oVirt, OpenNebula, and Ganeti.
> 
> This devroom will host presentations and labs that focus on topics of shared 
> interest, such as KVM, libvirt, shared storage, virtualized networking, 
> clustering and high availability, interfacing with multiple hypervisors, and 
> scaling across hundreds or thousands of servers.
> 
> Presentations in this devroom will be aimed at developers working on these 
> platforms who are looking to collaborate and improve shared infrastructure or 
> solve common problems.
> 
> The devroom organizers will seek topics that encourage dialog between 
> projects and continued work post-FOSDEM.
> 
> -
> Important Dates
> -
> 
> Submission deadline: 1 December 2015
> Acceptance notifications: 10 December 2015
> Final schedule announcement: 17 December 2015
> Devroom: 30-31 January 2016 (two days)
> 
> -
> Submission Guidelines: READ CAREFULLY
> -
> 
> ** Please note that we expect more proposals than we can possibly accept, so 
> it is vitally important that you submit your proposal on or before the 
> deadline. Late submissions are unlikely to be considered.**
> 
> * All presentation slots are 45 minutes, with 35 minutes planned for 
> presentations, and 10 minutes for Q&A.
> 
> * All presentations *will* be recorded and made available under Creative 
> Commons licenses. In the "Submission notes" field, please indicate that you 
> agree that your presentation will be licensed under the CC-By-SA-4.0 or 
> CC-By-4.0 license and that you agree to have your presentation recorded. For 
> example:
> 
>"If my presentation is accepted for FOSDEM, I hereby agree to license all 
> recordings, slides, and other associated materials under the Creative Commons 
> Attribution Share-Alike 4.0 International License. Sincerely, ."
> 
> * In the "Submission notes" field, please also confirm that if your talk is 
> accepted, you *will* be able to attend FOSDEM and deliver your presentation. 
> We will not consider proposals from prospective speakers who are unsure 
> whether they will be able to secure funds for travel and lodging to attend 
> FOSDEM. (Sadly, we are not able to offer travel funding for prospective 
> speakers.)
> 
> -
> How to Submit
> -
> 
> All submissions must be made via the Pentabarf event planning site:
> https://penta.fosdem.org/submission/FOSDEM16
> 
> If you have not used Pentabarf before, you will need to create an account. If 
> you submitted proposals for FOSDEM in previous years, you can use your 
> existing account.
> 
> After creating the account, select "Create Event" to start the submission 
> process. Make sure to select "Virtualization & IaaS devroom" from the Track 
> list.
> 
> Please fill out all the required fields, and provide a meaningful abstract 
> and description of your proposed session.
> 
> -
> Call for Volunteers
> -
> 
> We are also looking for volunteers to help run the devroom. We need 
> assistance watching time for the speakers, and helping with video for the 
> devroom. Please contact Mikey Ariel (mariel at redhat.com) for more 
> information.
> 
> -
> Questions
> -
> 
> If you have any questions about this devroom, please send your questions to: 
> iaas-virt-devroom at lists.fosdem.org
> 
> We will respond as quickly as possible. Thanks!
> 
> -- 
> Mikey Ariel
> Community Lead, oVirt
> www.ovirt.org
> 
> "To be is to do" (Socrates)
> "To do is to be" (Jean-Paul Sartre)
> "Do be do be do" (Frank Sinatra)
> 
> Mobile: +420-702-131-141
> IRC: mariel / thatdocslady
> Twitter: @ThatDocsLady
> ___
> devroom-managers mailing list
> devroom-manag...@lists.fosdem.org
> https://lists.fosdem.org/listinfo/devroom-managers


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

Re: [Xen-devel] Xen Unikernel: from zero to Hello World!

[Andrew Cooper]

On 27/10/15 19:42, Carl Patenaude Poulin wrote:
> Hi all,
>
> Thanks to Andrew Cooper's priceless help, I've managed to put
> together a Xen PV kernel that does nothing except loop forever. I'm
> going to try making it print "Hello, world!".
>
> I was hoping someone could fact-check my research. What I've dug up
> is:
> * I need to load my unikernel with `xl -c` to get console output.

-c is a parameter to `xl create`

Alternatively, you could do `xl create` followed by `xl console` later. 
However, there are usability issues with both of these approaches in
combination with short-lived domains.

> * My kernel currently refuses to load with the `-c` option. From
> what I've read online, this is because I need to implement a console
> device driver, similar to Mini-OS's xencons_ring.c.

What is the error message you get?  A PV guest always has a console, so
there is no refusal available to happen.  I suspect you have actually
hit one of the usability issues I eluded to above.

> * On Xen debug builds, I don't need a console device driver, I can
> just do HYPERVISOR_console_io hypercalls.

Always do all development with a debug hypervisor.  Even for guests, you
get more useful information out when something goes wrong.

Longterm you will want a better way of getting logging out of the guest,
but console_io hypercalls are a good start for very early bits.

~Andrew

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

Re: [Xen-devel] OSSTest nested patch PART2 -- L1 host has no 'Suite' property

[Ian Jackson]

Hu, Robert writes ("OSSTest nested patch PART2 -- L1 host has no 'Suite' 
property"):
> Now the patch has been refined to get whole 'test-amd64-amd64-qemuu-nested' 
> pass.

How exciting :-).

> But still one trivial issue I observed in the test log: L1 host has no 
> 'Suite' property.
> Any suggestions to improve this?

Two questions:

1. I think this (missing suite) probably ought to be fatal.  Which is
the first ts-* script which complains about it ?

2. In general the suite runvars are set by make-flight.  So I think
your patch to make-flight needs adjusting.  TBH I think the suite
should be set in do_hvm_debian_test_one for all Debian HVM tests,
even though maybe nothing uses it now.

Thanks,
Ian.

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

Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure [and 1 more messages]

[Ian Jackson]

Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation failure"):
> Now another issue: after attach lvm to L1, cannot see it inside.
> vgdisplay shows nothing.
> 
> My manual test like this: 
> xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
> 
> xl block-list can see it, while inside L1 cannot.

Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation failure"):
> Tried:
> After attach, in L1 cannot see the additional disk, if L1 is nested
> Xen. After reboot, can see it.  If L1 is booted as normal guest, it
> can see the additional disk at once, after attachment.

So your two tests are:

case A case B

   1.   boot L1 nestedhvm=1nestedhvm=0
without additional disk

   2.   xl block-attach in L0 

   3.   xl block-list in L0 shows it

   4.   ??? in L1 to look for disk  not visiblevisible

   5.   reboot L1 with same nestedhvm
setting

   6.   ??? in L1 to look for disk  visiblevisible

Is that right ?

I think this may be because the L1 booted with nestedhvm=1 gets its
disks solely via the emulated IDE controller supplied by qemu in L0.
And that IDE controller does not support hotplug.

(I don't quite understand why merely setting nestedhvm=1 stops the L1
from finding its Xen platform PCI device and initialising itself as a
Xen guest in a way that would prevent it also being a host.  I'm not
sure this is relevant, though.)

Ian.

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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Jan Beulich]

>>> On 28.10.15 at 11:50,  wrote:
> On Wed, Oct 28, 2015 at 8:53 AM, Jan Beulich  wrote:
> On 27.10.15 at 18:41,  wrote:
>>> And in line with my response to Andrew -- could we enable -Wshadow
>>> until we find a use for shadowing whose value outweighs the risks of
>>> building without it?
>>
>> Risking - along the lines of what Andrew said - build breakage for
>> random people, just due to the gcc version they happen to use?
>> I'm usually getting pretty upset when running into problems specific
>> to certain gcc versions, where people fairly clearly didn't think about
>> making their code sufficiently general. I don't know how people will
>> feel if we intentionally break their build (well, not really intentionally,
>> but we'd intentionally take the risk of doing so).
> 
> I don't really see the difference between this and what we do now with
> regard to other warning options.  Every few months someone reports
> some issue or other wrt compilers throwing out errors, and we either
> change the code so it works with that version, or provide a
> work-around.

The main difference is that the reports you refer to result from
changes to the compiler, whereas you suggest enabling a previously
disabled warning, i.e. us taking active action that incurs this risk.

>> And then, simply based on the patches that Julien sent so far: Are
>> we suspecting any bugs because of shadowing variables? None of
>> his patches fixed anything; they were just cleanup for cases where
>> the shadowing was pointless (and perhaps not even intended).
> 
> So your suggestion is, rather than wait until we find a positive
> example where -Wshadow breaks something, we should wait until we find
> a positive example where the lack of -Wshadow breaks something?

I wouldn't go _that_ far; I'm just wondering whether enabling the
warning would buy us anything (and enough to outweigh the hassle
it at least may cause).

> [snip from another email]
>> I do
>> appreciate the basic rule of writing simple code whenever possible,
>> but I don't think this should go to the extent of forbidding anything
>> more complicated (and hence more difficult to understand).
> 
> It's not so much about forbidding things that are complicated, but
> considering the cost/benefits trade-off.  So far the benefits of
> shadowing are:
> 
> * Macros that declare local variables are properly abstracted: you
> don't need to worry about conflicts between variables at the call site
> accidentally matching variables inside the declaration

No, that paints too nice a picture: The risk of problematic collisions
exists no matter how you write a macro. That's why people like to
prefix (or suffix, which at least doesn't clash with the language spec)
underscores to local variable names.

Jan


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

Re: [Xen-devel] [PATCH v6 6/6] tools: enable xenpm to control the intel_pstate driver

[Wei Liu]

On Wed, Oct 28, 2015 at 11:21:18AM +0800, Wei Wang wrote:
> The intel_pstate driver receives percentage values to set the
> performance limits. This patch adds interfaces to support the
> input of percentage values to control the intel_pstate driver.
> The "get-cpufreq-para" is modified to show percentage
> based feedback info.
> Also, some changes in identation are made to make the printed
> info looks tidy.
> 
> Signed-off-by: Wei Wang 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 5/6] x86/intel_pstate: support the use of intel_pstate in pmstat.c

[Wei Liu]

On Wed, Oct 28, 2015 at 11:21:17AM +0800, Wei Wang wrote:
> Add support in the pmstat.c so that the xenpm tool can request to
> access the intel_pstate driver.
> 
> Signed-off-by: Wei Wang 
> ---
>  changes in v6:
>  1) add the NON_INTERNAL_GOV macro to replace literal 0;
>  2) code consolidation (e.g. merging some code into if/else, as required in 
> v5);
>  3) somewhere, change to use clamp, instead of clamp_t;
>  4) xen_perf_alias, instead of perf_alias.
> 
>  tools/libxc/include/xenctrl.h  |  20 ++--
>  tools/libxc/xc_pm.c|  16 ++--
>  tools/misc/xenpm.c |   4 +-

I think all changes to toolstack code are merely trying to mirror
hypervisor side changes and there are no functional changes.

With that understanding and subject to an ack from hypervisor side
maintainer:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [BUG] mistakenly wake in Xen's credit scheduler

[George Dunlap]

On Wed, Oct 28, 2015 at 6:08 AM, Dario Faggioli
 wrote:
> On Wed, 2015-10-28 at 07:01 +0100, Juergen Gross wrote:
>> On 10/28/2015 06:54 AM, Dario Faggioli wrote:
>
>> > Yeah, well, sorry, but even if we both (me and George) encouraged
>> > you
>> > to try Credit2, that wasn't a great idea. :-(  In fact, you're
>> > using
>> > pinning for this test, and Credit2 does not have pinning (yet)! :-P
>> >
>> > That explains why utilizations are summing up to higher than 100%:
>> > vCPUs are just not being confined to one processor.
>> >
>> > Pinning for Credit2 is just around the corner. Let's try this again
>> > when it will be there, ok? :-D
>>
>> Or try it in a cpupool with just one pcpu?
>>
> Oh, well, yes. That is certainly an alternative. :-)
>
> I'm curious about how it'd go, so I'm probably going to give it a try
> later...

I was going to say, using cpupools rather than pinning is probably a
better idea anyway.  I might go so far as to say that if you're trying
to test the actual scheduling algorithms, you should *only* use
cpupools and *never* pinning.  The whole reason we invented cpupools
in the first place was that pinning tends to break the assumptions of
the scheduling algorithms in ways it's not really cost-effective to
work around.

 -George

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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[George Dunlap]

On Wed, Oct 28, 2015 at 8:53 AM, Jan Beulich  wrote:
 On 27.10.15 at 18:41,  wrote:
>> On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich  wrote:
>> On 27.10.15 at 16:39,  wrote:
 I'd like to have some input to know whether turning on -Wshadow would be
 sensible in the future.
>>>
>>> I think there are cases where using a shadowed variable might make
>>> sense, and hence I wouldn't want to see the warning turned on by
>>> default.
>>
>> Hmm, I'm having trouble coming up with good uses off the top of my
>> head.  And are there any uses for which the value outweighs the value
>> of having the warning?
>
> First of all - macros using the ({}) gcc extension.

Right -- so if we turn on -Wshadow, then it breaks the nice
"abstraction" provided by macros, since now suddenly calling any macro
might give you a random warning because the variable it used happened
to be the same as the variable name you wanted to use.  And you're
suggest elsewhere that simply adding an underscore or two at the front
is suboptimal, since that is reserved for language and library
constructs.  That is certainly an amount of hassle that's worth taking
into account.

>  And second variables
> whose name is kind of natural (e.g. "d" for struct domain * instances)
> but which are intentionally shadowing a larger scope one in order to
> not clobber that one's value.

This one, however, I think is probably something we should try to
avoid doing.  If there's a global d which is set to some domain, and
you have a local variable you want to point to a different domain,
then there must be something different about the two domains -- in
which case giving it a different variable name (e.g., "rd" for "remote
domain") isn't really that much of a burden, and certainly makes the
code easier to understand and less likely to introduce the kind of
bugs that Julien described.

>> And in line with my response to Andrew -- could we enable -Wshadow
>> until we find a use for shadowing whose value outweighs the risks of
>> building without it?
>
> Risking - along the lines of what Andrew said - build breakage for
> random people, just due to the gcc version they happen to use?
> I'm usually getting pretty upset when running into problems specific
> to certain gcc versions, where people fairly clearly didn't think about
> making their code sufficiently general. I don't know how people will
> feel if we intentionally break their build (well, not really intentionally,
> but we'd intentionally take the risk of doing so).

I don't really see the difference between this and what we do now with
regard to other warning options.  Every few months someone reports
some issue or other wrt compilers throwing out errors, and we either
change the code so it works with that version, or provide a
work-around.

> And then, simply based on the patches that Julien sent so far: Are
> we suspecting any bugs because of shadowing variables? None of
> his patches fixed anything; they were just cleanup for cases where
> the shadowing was pointless (and perhaps not even intended).

So your suggestion is, rather than wait until we find a positive
example where -Wshadow breaks something, we should wait until we find
a positive example where the lack of -Wshadow breaks something?

[snip from another email]
> I do
> appreciate the basic rule of writing simple code whenever possible,
> but I don't think this should go to the extent of forbidding anything
> more complicated (and hence more difficult to understand).

It's not so much about forbidding things that are complicated, but
considering the cost/benefits trade-off.  So far the benefits of
shadowing are:

* Macros that declare local variables are properly abstracted: you
don't need to worry about conflicts between variables at the call site
accidentally matching variables inside the declaration

* You can use a metavariable like "d" in a context where "d" is
already defined at a higher level, instead of giving it a different
name, like "rd".

* We avoid the risk that maybe somewhere there might be a gcc version
where variable shadow detection is broken.

And the costs are

* Risk of bugs where variables that used to be shadowed suddenly
become un-shadowed and vice versa

* Risk of bugs where people didn't realize that a particular variable
was being shadowed

On the whole, absent a specific example where gcc is completely broken
wrt -Wshadow, I'm inclined to agree with Julien, that the cost of
shadowing is higher than the benefits.

 -George

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

[Xen-devel] [xen-4.5-testing test] 63329: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu  3 host-install(3)broken REGR. vs. 63099
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 63099
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 63099
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 63099
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 63099

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 63099
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 63099
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 63099
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 63099
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 63099
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63099

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  47db4b088d18d900b5613ecb872283804320dde9
baseline version:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17

Last test of basis63099  2015-10-20 17:40:41 Z7 days
Failing since 63155  2015-10-21 15:43:44 Z6 days6 attempts
Testing same since63329  2015-10-27 05:11:23 Z1 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Wei Liu 
  Yang Zhang 

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

Re: [Xen-devel] memory balloon feature on Citrix XenServer 6.5 does not work for guest RHEL/CENTOS 6.X with default kernel 2.6.32.XX

[David Vrabel]

[CC'ing xs-devel, xen-devel to BCC]

On 28/10/15 08:07, Kiran Aher wrote:
> Hello,
> 
> We have noticed that the memory balloon feature on Citrix XenServer 6.5
> does
> not work for guest RHEL/CentOS 6.X with default kernel 2.6.32.XX.

This is a bug in the guest kernel.  It does not allow it to increase its
memory above it's initial allocation.

> A bugzilla ticket has beeb opened with  RedHat but they have come with a
> answer as Citrix XenServer is not a certified hypervisor for RHEL6.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1267507

David



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

[Xen-devel] [distros-debian-squeeze test] 38217: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38186

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Juergen Gross]

On 10/28/2015 10:31 AM, Jan Beulich wrote:

On 28.10.15 at 10:12,  wrote:

On 10/28/2015 09:53 AM, Jan Beulich wrote:

And second variables
whose name is kind of natural (e.g. "d" for struct domain * instances)
but which are intentionally shadowing a larger scope one in order to
not clobber that one's value.


Hmm, wouldn't something like tmp_d or d_tmp be a proper solution?


Ugly. Really ugly.


Maybe. OTOH I'm quite sure there is a name which would be acceptable.
Otherwise we couldn't write code referencing two different domains via
local variables without making it ugly.


There are other cases where more than one domain reference are needed
and it was possible to find proper variable names.


Yes, resulting in e.g. "e" being used for a struct domain * in grant
table code. Very natural a name for this kind of object.


Bad examples are always possible. This is no excuse not to use compiler
features which help us to avoid bugs.


Juergen

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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Jan Beulich]

>>> On 28.10.15 at 10:12,  wrote:
> On 10/28/2015 09:53 AM, Jan Beulich wrote:
>> And second variables
>> whose name is kind of natural (e.g. "d" for struct domain * instances)
>> but which are intentionally shadowing a larger scope one in order to
>> not clobber that one's value.
> 
> Hmm, wouldn't something like tmp_d or d_tmp be a proper solution?

Ugly. Really ugly.

> There are other cases where more than one domain reference are needed
> and it was possible to find proper variable names.

Yes, resulting in e.g. "e" being used for a struct domain * in grant
table code. Very natural a name for this kind of object.

>> Risking - along the lines of what Andrew said - build breakage for
>> random people, just due to the gcc version they happen to use?
>> I'm usually getting pretty upset when running into problems specific
>> to certain gcc versions, where people fairly clearly didn't think about
>> making their code sufficiently general. I don't know how people will
>> feel if we intentionally break their build (well, not really intentionally,
>> but we'd intentionally take the risk of doing so).
> 
> Is it really true that an older gcc might barf while a new one doesn't
> in case of shadowing? I don't think so. A test build with -Wshadow using
> the most recent gcc succeeding should do so with an older gcc as well.

Perhaps Andrew can give an example or two. I'm not myself
aware of issues in this area (perhaps largely because I don't often
work with code turning on -Wshadow).

Jan


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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Jan Beulich]

>>> On 28.10.15 at 10:10,  wrote:
> On 28/10/2015 08:53, Jan Beulich wrote:
>> First of all - macros using the ({}) gcc extension. And second variables
>> whose name is kind of natural (e.g. "d" for struct domain * instances)
>> but which are intentionally shadowing a larger scope one in order to
>> not clobber that one's value.
> 
> IHMO using variable is a very bad practice. It make patch review more 
> difficult as you need to check that you effectively modify the correct 
> version of the variable. I've got in mind patch #3 where we have 
> something like that:
> 
> int frame;
> 
> [...]
> 
> if ( foo )
> {
> int frame;
> 
> 
> frame = smth;
> }
> 
> frame = smth;
> 
> While I agree that shadow variable could make sense in macros using 
> ({}), all the variables in it are prefixed with _ and we can ensure that 
> the variable name is never re-used in other variables.

Note that identifiers starting with an underscore and a lower case
letter have a different purpose as per the language spec. Yes,
macro variable names do generally get chosen to avoid clashes,
but as long as people also consider it right to name other variables,
function parameters or macro parameters in a similar way, we won't
be able to fully exclude the risk of shadowed variables. And namely
for macros with a very special purpose (and perhaps narrow scope)
I don't think considering possible shadowing issues really is
warranted.

>> And then, simply based on the patches that Julien sent so far: Are
>> we suspecting any bugs because of shadowing variables? None of
>> his patches fixed anything; they were just cleanup for cases where
>> the shadowing was pointless (and perhaps not even intended).
> 
> FWIW, I haven't yet removed all the shadow variables because the other 
> are more complex to understand.
> 
> My main concern with shadow variables is we may introduce at some point 
> a bug because the patch doesn't show which version of the variable you 
> are modifying. Worth, you may not spot there is a shadow version even if 
> you apply the patch to the tree and look at the code.

Yes, there is a risk of bugs _solely_ because of shadowed variables.
But you realize that's no different from any other not exactly trivial
use of advanced language features (or quirks, if you take the
position of things like shadowed variables being a mis-feature)? I do
appreciate the basic rule of writing simple code whenever possible,
but I don't think this should go to the extent of forbidding anything
more complicated (and hence more difficult to understand).

Jan


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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Juergen Gross]

On 10/28/2015 09:53 AM, Jan Beulich wrote:

On 27.10.15 at 18:41,  wrote:

On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich  wrote:

On 27.10.15 at 16:39,  wrote:

I'd like to have some input to know whether turning on -Wshadow would be
sensible in the future.


I think there are cases where using a shadowed variable might make
sense, and hence I wouldn't want to see the warning turned on by
default.


Hmm, I'm having trouble coming up with good uses off the top of my
head.  And are there any uses for which the value outweighs the value
of having the warning?


First of all - macros using the ({}) gcc extension.


This case is easy to avoid: name local variables prefixed with the
macro name. While this isn't true today, I think this would be a good
policy for future changes.


And second variables
whose name is kind of natural (e.g. "d" for struct domain * instances)
but which are intentionally shadowing a larger scope one in order to
not clobber that one's value.


Hmm, wouldn't something like tmp_d or d_tmp be a proper solution?
There are other cases where more than one domain reference are needed
and it was possible to find proper variable names.


And in line with my response to Andrew -- could we enable -Wshadow
until we find a use for shadowing whose value outweighs the risks of
building without it?


I have seen hard to find bugs before which were caused by shadowing
variables. Shadowing variables even on purpose is something we should
avoid IMO.


Risking - along the lines of what Andrew said - build breakage for
random people, just due to the gcc version they happen to use?
I'm usually getting pretty upset when running into problems specific
to certain gcc versions, where people fairly clearly didn't think about
making their code sufficiently general. I don't know how people will
feel if we intentionally break their build (well, not really intentionally,
but we'd intentionally take the risk of doing so).


Is it really true that an older gcc might barf while a new one doesn't
in case of shadowing? I don't think so. A test build with -Wshadow using
the most recent gcc succeeding should do so with an older gcc as well.


And then, simply based on the patches that Julien sent so far: Are
we suspecting any bugs because of shadowing variables? None of
his patches fixed anything; they were just cleanup for cases where
the shadowing was pointless (and perhaps not even intended).


Risking to repeat myself: I think shadowing on purpose is evil and leads
to code which is harder to maintain.


Just my 0.02€


Juergen


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

Re: [Xen-devel] ELF Notes for kernel image

[Lars Kurth]

Guys,
given that you "concur [that] the Xen elf note documentation is in a poor 
state", I was wondering whether we could fix this based on this discussion. 
Lars

> On 27 Oct 2015, at 16:17, Andrew Cooper  wrote:
> 
> On 27/10/15 16:03, Carl Patenaude Poulin wrote:
>> Hi Andrew,
>> 
>> Thank you so much for your help! In particular, I find your
>> xen-test-framework code to be very instructive.
> 
> It is intended to be so, but I have a few more bits and pieces to
> complete before I declare it v1 and formally release it to the public. 
> (Looks like that boat has sailed now.)
> 
>> I have a question about that code, though. I can't find any place
>> where you're specifying that .note should be loaded as a PT_NOTE ELF
>> header. Do you do that anywhere? Or is it done implicitly somehow?
> 
> The linker file (arch/x86/link.lds.S) places all .note.* sections into
> the top level .note section.
> 
> ~Andrew
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Julien Grall]

Hi Jan,

On 28/10/2015 08:53, Jan Beulich wrote:

On 27.10.15 at 18:41,  wrote:

On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich  wrote:

On 27.10.15 at 16:39,  wrote:

I'd like to have some input to know whether turning on -Wshadow would be
sensible in the future.


I think there are cases where using a shadowed variable might make
sense, and hence I wouldn't want to see the warning turned on by
default.


Hmm, I'm having trouble coming up with good uses off the top of my
head.  And are there any uses for which the value outweighs the value
of having the warning?


First of all - macros using the ({}) gcc extension. And second variables
whose name is kind of natural (e.g. "d" for struct domain * instances)
but which are intentionally shadowing a larger scope one in order to
not clobber that one's value.


IHMO using variable is a very bad practice. It make patch review more 
difficult as you need to check that you effectively modify the correct 
version of the variable. I've got in mind patch #3 where we have 
something like that:


int frame;

[...]

if ( foo )
{
   int frame;


   frame = smth;
}

frame = smth;

While I agree that shadow variable could make sense in macros using 
({}), all the variables in it are prefixed with _ and we can ensure that 
the variable name is never re-used in other variables.


For instance min_t and max_t are using _x/_y. We could rename 
_min1/_min2 for min_t and then _max1/_max2 for max_t.



And in line with my response to Andrew -- could we enable -Wshadow
until we find a use for shadowing whose value outweighs the risks of
building without it?


Risking - along the lines of what Andrew said - build breakage for
random people, just due to the gcc version they happen to use?
I'm usually getting pretty upset when running into problems specific
to certain gcc versions, where people fairly clearly didn't think about
making their code sufficiently general. I don't know how people will
feel if we intentionally break their build (well, not really intentionally,
but we'd intentionally take the risk of doing so).

And then, simply based on the patches that Julien sent so far: Are
we suspecting any bugs because of shadowing variables? None of
his patches fixed anything; they were just cleanup for cases where
the shadowing was pointless (and perhaps not even intended).


FWIW, I haven't yet removed all the shadow variables because the other 
are more complex to understand.


My main concern with shadow variables is we may introduce at some point 
a bug because the patch doesn't show which version of the variable you 
are modifying. Worth, you may not spot there is a shadow version even if 
you apply the patch to the tree and look at the code.


--
Julien Grall

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

Re: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> On 28.10.15 at 03:58,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, October 27, 2015 5:52 PM
>> To: Wu, Feng 
>> Cc: Andrew Cooper ; Dario Faggioli
>> ; GeorgeDunlap ;
>> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>> 
>> Subject: RE: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core 
>> logic
>> handling
>> 
>> >>> On 27.10.15 at 06:19,  wrote:
>> >> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> >> Sent: Monday, October 26, 2015 10:40 PM
>> >> In any case, it would have been nice, given the situation, if you'd have 
> put a
>> few
>> >> words about, e.g., which solution you ended up implementing and why,
>> either in
>> >> the cover or here (e.g., in the '---' area).
>> >
>> > Thanks for the suggestion. As I mentioned before, updating the PI 
> descriptor
>> > needs
>> > to be atomic, I think it should be a little expensive. So doing it every
>> > VM-exit seems
>> > not a good idea to me.
>> 
>> You could check whether any update is needed before doing the
>> (atomic) cmpxchg16b.
> 
> I am not sure why you mentioned (atomic) cmpxchg16b here, for atomically
> Update PI descriptor, we don't need use cmpxchg16b, right?

To be honest I'm not sure which entity was the one needing
compxchg16b. Just take that comment in a more general form:
If there is an update to be done (by whatever means) that is
expensive, try avoiding the update by first checking whether
an update is actually needed. Just like we e.g. do for a couple
of MSR writes, where we keep the last written value in a per-
CPU variable.

> In my understanding, It seems there were two suggestions about this:
> 
> #1: Set 'SN' on each VM-Exit and clear 'SN' on each VM-Entry, so we don't
> need to care about the status of 'SN' in root mode. This is what I mean "not
> a good idea", since we add an atomic operation on each VM-Exit/VM-Entry.
> 
> #2: For the blocking cancel case, let's take the following code for example:
> 
> void vcpu_block(void)
> {
> struct vcpu *v = current;
> 
> set_bit(_VPF_blocked, &v->pause_flags);
> 
> arch_vcpu_block(v);
> 
> /* Check for events /after/ blocking: avoids wakeup waiting race. */
> if ( local_events_need_delivery() )
> {
> clear_bit(_VPF_blocked, &v->pause_flags);
> /* arch_vcpu_block_cancel(v); */ 
> }
> else
> {
> TRACE_2D(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id);
> raise_softirq(SCHEDULE_SOFTIRQ);
> }
> }
> 
> We still call arch_vcpu_block() in vcpu_block(), but we don't need to
> call arch_vcpu_block_cancel(v) when local_events_need_delivery()
> returns true. Then before VM-Entry, we can check if 'NV' field is
> ' pi_wakeup_vector', if it is, we change the PI status and remove
> it from the blocking list.
> 
> Jan, if #2 is what you mean, I think it worth a try. If I don't understand
> your comments correctly, could you please elaborate it more? Thanks
> a lot!

Ideally we'd avoid both arch_vcpu_*() calls by doing what is needed
in arch code (e.g. the VM entry path). If only avoiding the cancel
hook is reasonably possible this way, then so be it - still better to
have just one hook here than having two.

Jan


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf f40577c3563fcad7fc512617925d0574a7c64e2f
baseline version:
 ovmf 5d3a9896f0cbb0c8c3d375d9f82a7e397be862a7

Last test of basis38214  2015-10-27 03:50:14 Z1 days
Testing same since38216  2015-10-28 06:20:55 Z0 days1 attempts


People who touched revisions under test:
  Jaben Carsey 
  Jin Eric 
  Laszlo Ersek 
  Liming Gao 
  Michael Kinney 
  Qiu Shumin 

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 f40577c3563fcad7fc512617925d0574a7c64e2f
Author: Michael Kinney 
Date:   Mon Oct 26 16:40:52 2015 +

UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib

The PiSmmCpuDxeSmm module does not use any services from the SmmLib.
This change removes the SmmLib from PiSmmCpuDxeSmm module and also
removes the lib mapping in the UefiCpuPkg DSC file because no other
modules in the UefiCpuPkg use the SmmLib.

Removal of SmmLib is now possible because the only API call to it,
ClearSmi(), was ultimately removed from PiSmmCpuDxeSmm -- see the
"BUGBUG" comment in git commit 529a5a86.

Cc: "Yao, Jiewen" 
Cc: Jeff Fan 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Reviewed-by: "Yao, Jiewen" 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18673 
6f19259b-4bc3-4df7-8a09-765794883524

commit 0f2eb31c764685a1919b52f414bea44ea37580a2
Author: Laszlo Ersek 
Date:   Mon Oct 26 14:58:46 2015 +

OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and libraries

Before introducing the SMM driver interface, clean up #include directives
and [LibraryClasses] by:
- removing what's not directly used (HobLib and UefiLib),
- adding what's used but not spelled out (DevicePathLib),
- sorting the result.

This helps with seeing each source file's dependencies and with
determining the library classes for the SMM driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18672 
6f19259b-4bc3-4df7-8a09-765794883524

commit 1767877a31b3ce191ddae6cb9aefba99a733fe20
Author: Laszlo Ersek 
Date:   Mon Oct 26 14:58:39 2015 +

OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specifics

In preparation for introducing an SMM interface to this driver, move the
following traits to separate files, so that we can replace them in the new
SMM INF file:

- Protocol installations. The SMM driver will install protocol interfaces
  in the SMM protocol database, using SMM services.

- Virtual address change handler and pointer conversions. SMM drivers run
  with physical mappings and pointers must not be converted.

There are further restrictions and changes for an SMM driver, but the rest
of the code either complies with those already, or will handle the changes
transparently. For example:

- SMM drivers have access to both UEFI and SMM protocols in their entry
  points (see the PI spec 1.4, "1.7 SMM Driver Initialization"),

- MemoryAllocationLib has an SMM instance that serves allocation requests
  with the gSmst->SmmAllocatePool() service transparently, allocating
  runtime-marked SMRAM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18671 
6f19259b-4bc3

Re: [Xen-devel] [PATCH 0/6] Remove some usage of shadow variable

[Jan Beulich]

>>> On 27.10.15 at 18:41,  wrote:
> On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich  wrote:
> On 27.10.15 at 16:39,  wrote:
>>> I'd like to have some input to know whether turning on -Wshadow would be
>>> sensible in the future.
>>
>> I think there are cases where using a shadowed variable might make
>> sense, and hence I wouldn't want to see the warning turned on by
>> default.
> 
> Hmm, I'm having trouble coming up with good uses off the top of my
> head.  And are there any uses for which the value outweighs the value
> of having the warning?

First of all - macros using the ({}) gcc extension. And second variables
whose name is kind of natural (e.g. "d" for struct domain * instances)
but which are intentionally shadowing a larger scope one in order to
not clobber that one's value.

> And in line with my response to Andrew -- could we enable -Wshadow
> until we find a use for shadowing whose value outweighs the risks of
> building without it?

Risking - along the lines of what Andrew said - build breakage for
random people, just due to the gcc version they happen to use?
I'm usually getting pretty upset when running into problems specific
to certain gcc versions, where people fairly clearly didn't think about
making their code sufficiently general. I don't know how people will
feel if we intentionally break their build (well, not really intentionally,
but we'd intentionally take the risk of doing so).

And then, simply based on the patches that Julien sent so far: Are
we suspecting any bugs because of shadowing variables? None of
his patches fixed anything; they were just cleanup for cases where
the shadowing was pointless (and perhaps not even intended).

Jan


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

Re: [Xen-devel] memory balloon feature on Citrix XenServer 6.5, does not work for guest RHEL/CENTOS 6.X with default kernel 2.6.32.XX

[Kiran Aher]

we have created a RHEL6 guest with 4 VCPUS then memory static min as 4 
GB and memory static as 8 GB and memory target as 6 GB. In this case we 
can change the balloon target to 5 GB which works but if we change the 
balloon target to 7 GB, it balloon memory only till initial startup 
value which is 6 GB.


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

Re: [Xen-devel] [Xen 4.7] tmem todos

[Yang Hongyang]

On 2015年10月28日 00:26, Konrad Rzeszutek Wilk wrote:

Hey,

Way back in Shenghai we had a chat about what needs to be done
in tmem for the 4.6 release. Things got done, but there are other
things that need to be done:

  a) Migration v2 support
  b) Fix the toolstack (cleanup)
  c) tmem tze, dedup, and zlib code drop
  d) simplify the internal structs
  e) Make it work on 5TB and higher
  f) And finally security audit.

In 4.6 I did an conversion of moving the sysctl related tmem
to the sysctl hypercall. That cleaned up the code a bit and made
it fit nicer in the appropiate architecture bins.

The next step will be to follow that and actually seperate
the tmem C code - one file for sysctl and the other for tmem operations.

That will allow me to focus then on the b), and c) part.
a) is going to be the stretch goal that I will try to get done
(at least an RFC). The nice side benefit is that I will be better
equipped to review the REMUS patches so an extra reviewer.


That's great! :)




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



--
Thanks,
Yang

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

[Xen-devel] memory balloon feature on Citrix XenServer 6.5 does not work for guest RHEL/CENTOS 6.X with default kernel 2.6.32.XX

[Kiran Aher]

Hello,

We have noticed that the memory balloon feature on Citrix XenServer 6.5 does
not work for guest RHEL/CentOS 6.X with default kernel 2.6.32.XX.

A bugzilla ticket has beeb opened with  RedHat but they have come with a
answer as Citrix XenServer is not a certified hypervisor for RHEL6.

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


Regards,
Kiran A.


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 63211
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 63211
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 63211
 test-amd64-amd64-pygrub   5 xen-install   fail REGR. vs. 63211

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken REGR. vs. 63211
 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 63211
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 63211
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 63211
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 63211
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63211

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  d8ba3a9e444c6943199130eea32904bc245a6d27
baseline version:
 xen  e08f3834c2f375153f104c827dd7c2fea93b288e

Last test of basis63211  2015-10-22 08:57:53 Z5 days
Failing since 63250  2015-10-23 10:45:56 Z4 days4 attempts
Testing same since63327  2015-10-27 02:14:16 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  George Dunlap 
  He Chen 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Wei Liu 
  Zhigang Wang 

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