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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 38452

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-xsm 21 guest-start/debian.repeat fail blocked in 38452
 test-amd64-amd64-xl  21 guest-start/debian.repeatfail   like 38452

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

Last test of basis38452  2015-12-05 12:51:55 Z2 days
Testing same since38462  2015-12-08 00:51:40 Z0 days1 attempts


People who touched revisions under test:
  Andreas Färber 
  Cao jin 
  Marc-André Lureau 
  Markus Armbruster 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  fail
 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-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
65114

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-amd  3 host-install(3)  broken pass in 65463
 test-amd64-amd64-libvirt-pair  3 host-install/src_host(3) broken pass in 65463
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken pass in 65463
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 65463 pass in 
65488
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 65463 pass in 65488
 test-armhf-armhf-libvirt-xsm 11 guest-startfail in 65463 pass in 65488
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 65463

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) broken blocked in 
65114
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail blocked in 65114
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 65463 like 65114
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 65114
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 65114
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 65114
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 65114
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 65114

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

version targeted for testing:
 xen  0d0f28455d9c019475575d7a36f3c98fa4f0342d
baseline version:
 xen  713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1

Last test of basis65114  2015-11-25 19:42:37 Z   12 days
Failing since 65141  2015-11-26 20:45:33 Z   11 days   17 attempts
Testing same since65372  2015-12-04 12:52:08 Z3 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Daniel De Graaf 
  David Scott 
  David Vrabel 
  Doug Goldstein 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Juerg

Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL

[Hu, Robert]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Saturday, December 5, 2015 4:10 PM
> To: Hu, Robert ; Ian Jackson
> ; Nakajima, Jun ;
> Tian, Kevin 
> Cc: xen-de...@lists.xensource.com; osstest service owner
> ; Jan Beulich ;
> Andrew Cooper 
> Subject: Re: [xen-unstable test] 65141: regressions - FAIL
> 
> On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote:
> 
> > http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/
> >
> > I think that ought to give a baseline for the bisector to work with. I'll
> > prod it to do so.
> 
> Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine
> address" is somehow at fault.
> 
> It appears to be somewhat machine specific, the one this has been
> failing on is godello* which says "CPU0: Intel(R) Xeon(R) CPU E3-1220
> v3 @ 3.10GHz stepping 03" in its serial log.
> 
> Andy suggested this might be related to cpu_has_vmx_vmcs_shadowing
> so Haswell and newer vs IvyBridge and older.
> 
> Ian.
> 
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-qemuu-nested-intel
> testid debian-hvm-install/l1/l2
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  d02e84b9d9d16b6b56186f0dfdcb3c90b83c82a3
>   Bug not present: 3b47431691409004c7218f6a6ba5c9c0bcf483ea
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65388/
> 
> 
>   commit d02e84b9d9d16b6b56186f0dfdcb3c90b83c82a3
>   Author: Jan Beulich 
>   Date:   Tue Nov 24 12:07:27 2015 +0100
> 
>   vVMX: use latched VMCS machine address
> 
>   Instead of calling domain_page_map_to_mfn() over and over, latch
> the
>   guest VMCS machine address unconditionally (i.e. independent of
> whether
>   VMCS shadowing is supported by the hardware).
> 
>   Since this requires altering the parameters of __[gs]et_vmcs{,_real}()
>   (and hence all their callers) anyway, take the opportunity to also drop
>   the bogus double underscores from their names (and from
>   __[gs]et_vmcs_virtual() as well).
> 
>   Signed-off-by: Jan Beulich 
>   Acked-by: Kevin Tian 
> 
> 
> For bisection revision-tuple graph see:
> 
> http://logs.test-lab.xenproject.org/osstest/results-adhoc/bisect/xen-unstabl
> e/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Running cs-bisection-step
> --graph-out=/home/logs/results-adhoc/bisect/xen-unstable/test-amd64-am
> d64-qemuu-nested-intel.debian-hvm-install--l1--l2
> --summary-out=tmp/65388.bisection-summary
> --blessings=real,real-bisect,adhoc-bisect --basis-template=65301
> --basis-flight=65301 xen-unstable test-amd64-amd64-qemuu-nested-intel
> debian-hvm-install/l1/l2
> Searching for failure / basis pass:
>  65314 fail [host=godello1] / template as basis? using template as basis.
> Failure / basis pass flights: 65314 / 65301
> (tree with no url: ovmf)
> (tree with no url: seabios)
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 769b79eb206ad5b0249a08665fefb913c3d1998e
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> bc00cad75d8bcc3ba696992bec219c21db8406aa
> 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> 2c4f313a7e62c7e559a469d4af4c3d03c49afa43
> Basis pass 1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> bc00cad75d8bcc3ba696992bec219c21db8406aa
> 816609b2841297925a223ec377c336360e044ee5
> d07f63fa6e70350b23e7acbde06129247c4e655d
> Generating revisions with ./adhoc-revtuple-generator
> git://xenbits.xen.org/linux-pvops.git#1230ae0e99e05ced8a945a1a2c5762ce
> 5c6c97c9-769b79eb206ad5b0249a08665fefb913c3d1998e
> git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb955
> 8310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
> git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992b
> ec219c21db8406aa-bc00cad75d8bcc3ba696992bec219c21db8406aa
> git://xenbits.xen.org/qemu-xen.git#816609b2841297925a223ec377c336360
> e044ee5-3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> git://xenbits.xen.org/xen.git#d07f63fa6e70350b23e7acbde06129247c4e655
> d-2c4f313a7e62c7e559a469d4af4c3d03c49afa43
> Loaded 17133 nodes in revision graph
> Searching for test results:
>  65114 [host=italia0]
>  65141 fail 769b79eb206ad5b0249a08665fefb913c3d1998e
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> bc00cad75d8bcc3ba696992bec219c21db8406

Re: [Xen-devel] blkback feature announcement

[Jan Beulich]

>>> On 08.12.15 at 02:08,  wrote:
> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>>> Hello,
>>>
>>> is there a particular reason why "max-ring-page-order" gets written in
>>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>>> "feature-persistent" get written only in connect(), despite both having
>>> constant values (and hence the node value effectively being known as
>>> soon as the device exists)?
>> 
>> No, AFAIK there's no specific reason.
>> 
> 
> AFAIR, that's for the blkfront resume path.
> 
> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
> that we can know how many ring pages to be used before setup_blkring().

I don't follow - the proposal is to have the backend announce the
feature _earlier_, so how could frontend resume be affected?

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 65468
 build-i386-xsm5 xen-build fail REGR. vs. 65468
 build-amd64-xsm   5 xen-build fail REGR. vs. 65468
 build-amd64   5 xen-build fail REGR. vs. 65468

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e
baseline version:
 ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116

Last test of basis65468  2015-12-07 08:14:46 Z1 days
Failing since 65485  2015-12-07 18:14:23 Z0 days7 attempts
Testing same since65489  2015-12-07 22:43:16 Z0 days6 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Heyi Guo 
  Yonghong Zhu 

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



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

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

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

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


Not pushing.


commit fb48e7780e1e0e0a7702ed8772e68150a9f8d10e
Author: Heyi Guo 
Date:   Mon Dec 7 16:51:35 2015 +

ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol

Load File protocol requires remaining device path rather than whole
device path. For PXE, it actually requires end node device path only,
or else invalid parameter will be returned directly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Reviewed-by: Leif Lindholm 

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

commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5
Author: Ard Biesheuvel 
Date:   Mon Dec 7 09:22:21 2015 +

CryptoPkg/OpensslLib: comment out unused code

This comments out the pqueue and ts_* source files from the OpensslLib
build, since they have no users.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Qin Long 

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

commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d
Author: Ard Biesheuvel 
Date:   Mon Dec 7 09:20:20 2015 +

CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC

Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting
with other variables of the same name that may be defined in other
libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe)
This also removes the risk of mVirtualAddressChangeEvent being merged with
other uninitialized variables with external linkage by toolchains that 
perform
COMMON allocation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Qin Long 

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

commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b
Author: Ard Biesheuvel 
Date:   Mon Dec 7 09:20:09 2015 +

CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc

In order to build the ARM version of CryptoPkg from its own .DSC file,
it n

Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid

[Jan Beulich]

>>> On 07.12.15 at 17:48,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu 
> *v, uint64_t value,
>  {
>  unsigned int level;
>  
> -ASSERT(v == current);
> +ASSERT(v->domain == current->domain);
>  hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
>  if ( level >= 0x8001 )
>  {
> @@ -1912,7 +1912,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const 
> struct vcpu *v,
>  {
>  unsigned int level;
>  
> -ASSERT(v == current);
> +ASSERT(v->domain == current->domain);
>  hvm_cpuid(0, &level, NULL, NULL, NULL);
>  if ( level >= 1 )
>  hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);

The only reason both functions get v passed are the two ASSERT()s.
Relaxing them means you should now be passing a const struct
domain * instead.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)broken REGR. vs. 65474
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
65474
 test-amd64-amd64-xl-multivcpu 22 leak-check/check fail REGR. vs. 65474

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 65474
 test-armhf-armhf-libvirt  6 xen-boot fail blocked in 65474
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 65474

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

version targeted for testing:
 qemuuc3626ca7df027dabf0568284360a23faf18f0884
baseline version:
 qemuua5582eac15171ffea99f9962dd9a4bf3c1dd2f1c

Last test of basis65474  2015-12-07 11:13:35 Z0 days
Testing same since65498  2015-12-08 00:43:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Baumann 
  Denis V. Lunev 
  Fam Zheng 
  Jason Wang 
  Markus Armbruster 
  Michael S. Tsirkin 
  Peter Maydell 
  Prasad J Pandit 

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-

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-debianhvm-amd64-xsm
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  527e9316f8ec44bd53d90fb9f611fa752bb9
  Bug not present: 8a70dd2669200ce83255ed8c5ebef7e59f9e8707
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65539/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64-xsm.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64-xsm.xen-boot
 --summary-out=tmp/65539.bisection-summary --basis-template=59254 
--blessings=real,real-bisect linux-linus 
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm xen-boot
Searching for failure / basis pass:
 65459 fail [host=huxelrebe1] / 63536 [host=italia0] 63398 [host=italia1] 63372 
[host=pinot1] 63354 [host=rimava1] 63339 [host=chardonnay0] 63208 ok.
Failure / basis pass flights: 65459 / 63208
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 527e9316f8ec44bd53d90fb9f611fa752bb9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Basis pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
1c8d43cbdf0fc01a8f05acfbf55b805a83da34bb 
816609b2841297925a223ec377c336360e044ee5 
3a95c3f9c26a4b877598d45886eae95963c5d793
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#8a70dd2669200ce83255ed8c5ebef7e59f9e8707-527e9316f8ec44bd53d90fb9f611fa752bb9
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#1c8d43cbdf0fc01a8f05acfbf55b805a83da34bb-bc00cad75d8bcc3ba696992bec219c21db8406aa
 
git://xenbits.xen.org/qemu-xen.git#816609b2841297925a223ec377c336360e044ee5-f6787aedc9043bffc5ee5b64c6d46b8fc7298a96
 
git://xenbits.xen.org/xen.git#3a95c3f9c26a4b877598d45886eae95963c5d793-713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 15438 nodes in revision graph
Searching for test results:
 64026 fail irrelevant
 64147 fail irrelevant
 64197 fail irrelevant
 64484 fail irrelevant
 64874 fail irrelevant
 65024 fail irrelevant
 64985 fail irrelevant
 65086 fail irrelevant
 65059 fail irrelevant
 65109 fail irrelevant
 65156 fail irrelevant
 65132 fail irrelevant
 65220 fail irrelevant
 65234 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
3b47431691409004c7218f6a6ba5c9c0bcf483ea
 65223 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
c87303c04738b0e837da6e891eb561de0bf1b64e
 65218 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
1c8d43cbdf0fc01a8f05acfbf55b805a83da34bb 
816609b2841297925a223ec377c336360e044ee5 
3a95c3f9c26a4b877598d45886eae95963c5d793
 65225 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
816609b2841297925a223ec377c336360e044ee5 
abdf3c5b2b971dc12e665e8e0cda184b416efffe
 65230 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
816609b2841297925a223ec377c336360e044ee5 
acd9bd133c04766b8457f55e072c39f38eec5a43
 65228 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
816609b2841297925a223ec377c336360e044ee5 
32b31c17da1ba0da970cd182a8865ac20fabd0fa
 65236 pass 8a70dd2669200ce83255ed8c5ebef7e59f9e8707 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
3fb401edbd8e9741c611bfddf6a2032

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

[Ian Campbell]

On Fri, 2015-11-20 at 14:55 +, Anthony PERARD wrote:
> This script runs the OpenStack integration test suite, Tempest.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Ian Campbell 


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

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

[Ian Campbell]

On Fri, 2015-11-20 at 14:55 +, Anthony PERARD wrote:

I think this will also add a devstack job to most other flights? That's a
good thing, I think.

I wonder if the flight ought to be called openstack-nova, to leave open the
possibility of other openstack-$foo flights in the future?

> Signed-off-by: Anthony PERARD 
> 
> ---
> Change in V4:
> - also skip build-*-oldkern in make flight

Those should already be caught by cr-daily-branch
setting REVISION_LINUX_OLD=disable for all but the xen-unstable flight
(arguably that default ought to be inverted, such that make-flight by
default doesn't make such flights unless asked to, but that's not your Yakk
I think)

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

The sort of info in this last bullet would be useful in the commit message,
I think.

> diff --git a/make-flight b/make-flight
> index 8523995..5a4fc0c 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -54,6 +54,12 @@ job_create_build_filter_callback () {
>  *)   return 1 ;;
>    esac
>  ;;
> +openstack)
> +  case "$job" in
> +*-xsm) return 1;;

I wonder, would a test-$xenarch$kern-$dom0arch-devstack-xsm be a useful
think to have though?

> +*-oldkern) return 1;;

See above.

> diff --git a/mfi-common b/mfi-common
> index 5fbe195..f11302b 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -59,6 +59,7 @@ xenbranch_xsm_variants () {
>  xen-4.3-testing) echo "false";;
>  xen-4.4-testing) echo "false";;
>  xen-4.5-testing) echo "false";;
> +openstack)   echo "false";;
>  *) echo "false true";
>  esac
>  }
> @@ -102,6 +103,7 @@ create_build_jobs () {
>    rumpuserxen) continue;;
>    seabios) continue;;
>    ovmf) continue;;
> +  openstack) continue;;
>    esac
>    case "$xenbranch" in
>    xen-3.*-testing) continue;;
> @@ -127,6 +129,9 @@ create_build_jobs () {
>    "
>    ;;
>  esac
> +if [ "$arch" = i386 ] && [ "$branch" = openstack ]; then
> +  continue

This accepts ARM, but I think you filter the test cases for that? The
filtering of build vs. test jobs in make-flight/mfi-common is a bit of a
mess, recently e21625f79d33 "make-flight: move in-lined branch vs arch
filtering into callbacks" make it a bit less bad, which might be useful to
you here?

> +fi
>  
>  case "$arch" in
>  *) suite=$defsuite;;

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

Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL

[Ian Campbell]

On Tue, 2015-12-08 at 08:06 +, Hu, Robert wrote:
> > 
> [...]

Please trim your quotes.

> For your failure, as Kevin mentioned in other mail, we will find someone
> to look into.
> Would you find out the detailed log of ' debian-hvm-install--l1--l2'
> step? so that he
> can start analyze, as I cannot reproduce it right now.
> (I didn't managed to find out the log in your web links)

From
http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/

(in this thread, or any other relevant logs/N/ link), you can click the
"test -amd64 -amd64 -qemuu -nested -intel" header to go to
http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/test-amd64-amd64-qemuu-nested-intel/info.html

Then click the result of the "debian-hvm-install/l1/l2" step from that
table to go to the step log:
http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/test-amd64-amd64-qemuu-nested-intel/16.ts-debian-hvm-install.log

Which I think is what you were after?

All of the other related logs are at the end of the same
http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/test-amd64-amd64-qemuu-nested-intel/info.html
page.

See also README in osstest.git which explains the structure of the log
pages/grids/etc.

Ian.



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

Re: [Xen-devel] [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen

[Daniel P. Berrange]

On Mon, Dec 07, 2015 at 10:59:32PM -0700, Jim Fehlig wrote:
> On 12/07/2015 11:52 AM, Daniel P. Berrange wrote:
> > On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote:
> >> In commit d2e5538b1, the libxl driver was changed to copy interface
> >> names autogenerated by libxl to the corresponding network def in the
> >> domain's virDomainDef object. The copied name is freed when the domain
> >> transitions to the shutoff state. But when migrating a domain, the
> >> autogenerated name is included in the XML sent to the destination host.
> >> It is possible an interface with the same name already exists on the
> >> destination host, causing migration to fail. Indeed the Xen project's
> >> OSSTEST CI already encountered such a failure.
> >>
> >> This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
> >> the autogenerated names to be excluded when parsing and formatting
> >> inactive config.
> >>
> >> Signed-off-by: Jim Fehlig 
> >> ---
> >>
> >> This is an alternative approach to Joao's fix for this regression
> >>
> >> https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html
> >>
> >> I think it is the same approach used by the qemu driver. My only
> >> reservation is that it expands the potential for clashes with
> >> user-defined names. I.e. with this change both 'vnet' and 'vif' are
> >> reserved prefixes.
> > Hmm, yes, tricky one.
> >
> > If we only care about XML parsing, then you could register a post
> > parse callback instead to do this.
> 
> AFAIK, XML parsing is all that's in play here.
> 
> > I'm not clear why we also have it in the virDomainNetDefFormat
> > method - and we can't solve that with a post-parse callback.
> >
> >
> > The other option would be to make the reserved prefix be a
> > capability that the parser/formatter could read.
> 
> This seems like the best option, since a post-parse callback doesn't solve the
> problem in virDomainNetDefFormat. It also has the upshot of making the prefix
> visible and known to users. But I doubt such a change is suitable during 1.3.0
> freeze.  With the freeze in mind, seems the best solution to the libxl 
> migration
> regression is revert d2e5538b1. It can be added again post-1.3.0 release, 
> after
> adding the prefix to capabilities.
> 
> DV, since you may be making the release soon, feel free to revert d2e5538b1 if
> you agree.

Yeah, just go ahead & revert it Jim,  DV isn't doing the releae until
tomorrow morning

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Xen-devel] [PATCH v2 1/4] xen/MSI-X: latch MSI-X table writes

[Stefano Stabellini]

On Mon, 7 Dec 2015, Jan Beulich wrote:
> >>> On 07.12.15 at 13:41,  wrote:
> > I know that in your opinion is superfluous, nonetheless could you please
> > add 2-3 lines of in-code comment right here, to explain what you are
> > doing with the check?  Something like:
> > 
> > /*
> >  * Update the entry addr and data to the latest values only when the
> >  * entry is masked or they are all masked, as required by the spec.
> >  * Addr and data changes while the MSI-X entry is unmasked will be
> >  * delayed until the next masking->unmasking.
> >  */
> 
> Btw, will it be okay to just resend this one patch as v3, or do I need
> to resend the whole series (the rest of which didn't change)?

Just this patch is fine.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  3c80d6f3c61eb0f8072f70b0a9a8c8c7adf17572
baseline version:
 xen  0d0f28455d9c019475575d7a36f3c98fa4f0342d

Last test of basis65335  2015-12-03 18:00:54 Z4 days
Testing same since65545  2015-12-08 09:00:48 Z0 days1 attempts


People who touched revisions under test:
  Ed Swierk 
  Haozhong Zhang 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] x86/time: Don't use EFI's GetTime call by default

[Ian Campbell]

On Wed, 2015-12-02 at 02:33 -0700, Jan Beulich wrote:
> > > > On 01.12.15 at 20:26,  wrote:
> > On 01/12/15 17:26, Jan Beulich wrote:
> > > > > > On 01.12.15 at 17:57,  wrote:
> > > > When EFI is used, don't use EFI's GetTime() to get the time,
> > > > because it
> > > > is broken on many platforms. From Linux commit 7efe665903d0 ("rtc:
> > > > Disable EFI rtc for x86"):
> > > > "Disable it explicitly for x86 so that we don't give users false
> > > > hope that this driver will work - it won't, and your machine is
> > > > likely
> > > > to crash."
> > > > 
> > > > Signed-off-by: Ross Lagerwall 
> > > NAK, since being conceptually wrong (and both of my systems work
> > > fine). Vendors should get their firmware fixed, and by not using
> > > runtime service functions we would give them even less reason to
> > > do so. Until then we have "efi=no-rs".
> > 
> > This is completely unreasonable.
> > 
> > It is not conceptually wrong.
> 
> I'm sorry, but no. Otherwise you mean to state that specifications
> don't even need to be written, since if people don't play by them,
> workarounds will get implemented anyway.

In an ideal world such specifications would indeed be worth the paper they
are written on. But the reality is that firmware implementations are often
complete rubbish and the Xen project has nowhere near the leverage needed
to actually get this fixed, even Linux lacks such leverage AFAICT.

In reality only Microsoft (and perhaps to a lesser extent Apple) have any
sort of ability to force things in this way (even so it is alleged in this
thread that even Windows avoids the GetTime call as too broken in the field
as well).

Given we have no leverage in this it seems to me that punishing our users
by ensuring that Xen won't work on the majority of EFI systems (based on
anecdotal evidence from both Andrew and yourself) is counter productive.
All it means is that at best we will get a continuous stream of bug reports
from such users, or worse those users will just silently disappear and use
something else which Just Works on their hardware and tell their friends
that Xen is broken on modern hardware.

There is only the smallest chance they will actually report a bug to their
firmware vendor and even if they do there is basically an infinitesimal
chance that the vendor will care in the slightest given that Windows
presumably boots and works on that system.

Realistically about all we can do is support efforts such as
http://biosbits.org/
https://wiki.ubuntu.com/Kernel/Reference/fwts
https://01.org/linux-uefi-validation
and hope that they gain sufficient momentum, we certainly cannot effect any
kind of change in the x86 firmware world directly ourselves by holding
basic Xen functionality to ransom.

> >  GetTime() is very well known completely
> > broken, especially after ExitBootServices(), to the point that every
> > other EFI implementation (including windows) completely avoids it.
> 
> I'm not sure about the order of things. I started working with EFI on
> IA64, where using runtime services is a must. Windows started
> using EFI on IA64 too, so I'm pretty convinced they used GetTime()
> there. Whether they didn't on x86 because x86 implementations
> were broken, or whether x86 implementations end up broken
> because Windows never used those functions is simply an unknown.

I don't think it is relevant to use why x86 UEFI implementations are broken
in this way, just that it seems that the reality is that they mostly are.

> > Vendors will not fix their firmware.  Disabling all runtime services is
> > not a reasonable alternative.
> 
> Then we should see about adding support for "efi=no-time".

And based on what I'm reading in this thread about the reliability of the
time RS in the field it seems to me we should make it the default (on x86
at least) and provide efi=time to opt in.

Ian.

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

Re: [Xen-devel] blkback feature announcement

[Bob Liu]

On 12/08/2015 04:13 PM, Jan Beulich wrote:
 On 08.12.15 at 02:08,  wrote:
>> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
 Hello,

 is there a particular reason why "max-ring-page-order" gets written in
 xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
 "feature-persistent" get written only in connect(), despite both having
 constant values (and hence the node value effectively being known as
 soon as the device exists)?
>>>
>>> No, AFAIK there's no specific reason.
>>>
>>
>> AFAIR, that's for the blkfront resume path.
>>
>> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
>> that we can know how many ring pages to be used before setup_blkring().
> 
> I don't follow - the proposal is to have the backend announce the
> feature _earlier_, so how could frontend resume be affected?
> 

The frontend resume is like this:

blkfront_resume()
 > blkif_free()
 > talk_to_blkback()
 > setup_blkring() etc.

blkback_changed()
 > blkfront_connect()


Sometimes the "max-ring-page-order" of backend may have changed after the 
guest(frontend) migrated to a different machine,
the frontend must aware of this change so that have to get the new value of 
"max-ring-page-order" in blkfront_resume().

But it would be too late if the backend announces the "max-ring-page-order" in 
connect(), this situation is like:

blkfront_resume()
 > blkif_free()
 > talk_to_blkback()
 ^^^ Get a wrong "max-ring-page-order"
 > setup_blkring() etc. but using the wrong value!!

blkback_changed()
 > blkfront_connect()
   ^^^ Then the connect() in backend will be called(after frontend enter 
XenbusStateConnected) and write the correct "max-ring-page-order", but it's too 
late.

Bob

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

Re: [Xen-devel] [OSSTEST PATCH 09/16] mg-schema-test-database: New script

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> This allows a user in non-standalone mode to make a whole new test
> database, which is largely a clone of the original database.
> 
> The new db refers to the same resources (hosts), and more-or-less
> safely borrows some of those hosts.
> 
> Currently we don't do anything about the queue and owner daemons.
> This means that queue-daemon-based resource allocation is broken when
> clients are pointed at the test db.  But non-queue-based allocation
> (eg, ./mg-allocate without -U) works, and the test db can be used for
> db-related experiments and even support individual ts-* scripts (other
> than ts-hosts-allocate of course).
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 11/16] mg-schema-test-database: Sort out daemons; provide `daemons' subcommand

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> We arrange for the test configuration to look for the daemons on a
> different host and port, and we provide a convenient way to run such a
> pair of daemons.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

[Xen-devel] [PATCH v3 1/4] xen/MSI-X: latch MSI-X table writes

[Jan Beulich]

The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
guest having done so). Plus these writes shouldn't be dropped even when
an entry gets unmasked. Instead, if they can't be made take effect
right away, they should take effect on the next unmasking or enabling
operation - the specification explicitly describes such caching
behavior.

Signed-off-by: Jan Beulich 
---
v3: Add comment to xen_pt_msix_update_one().
v2: Pass original vec_ctrl to xen_pt_msix_update_one() instead of
(ab)using latch[].

--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1499,6 +1499,8 @@ static int xen_pt_msixctrl_reg_write(Xen
 xen_pt_msix_disable(s);
 }
 
+s->msix->maskall = *val & PCI_MSIX_FLAGS_MASKALL;
+
 debug_msix_enabled_old = s->msix->enabled;
 s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
 if (s->msix->enabled != debug_msix_enabled_old) {
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -187,13 +187,13 @@ typedef struct XenPTMSIXEntry {
 int pirq;
 uint64_t addr;
 uint32_t data;
-uint32_t vector_ctrl;
+uint32_t latch[4];
 bool updated; /* indicate whether MSI ADDR or DATA is updated */
-bool warned;  /* avoid issuing (bogus) warning more than once */
 } XenPTMSIXEntry;
 typedef struct XenPTMSIX {
 uint32_t ctrl_offset;
 bool enabled;
+bool maskall;
 int total_entries;
 int bar_index;
 uint64_t table_base;
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -25,6 +25,7 @@
 #define XEN_PT_GFLAGSSHIFT_DELIV_MODE 12
 #define XEN_PT_GFLAGSSHIFT_TRG_MODE   15
 
+#define latch(fld) latch[PCI_MSIX_ENTRY_##fld / sizeof(uint32_t)]
 
 /*
  * Helpers
@@ -314,7 +315,8 @@ static int msix_set_enable(XenPCIPassthr
enabled);
 }
 
-static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr,
+  uint32_t vec_ctrl)
 {
 XenPTMSIXEntry *entry = NULL;
 int pirq;
@@ -332,6 +334,19 @@ static int xen_pt_msix_update_one(XenPCI
 
 pirq = entry->pirq;
 
+/*
+ * Update the entry addr and data to the latest values only when the
+ * entry is masked or they are all masked, as required by the spec.
+ * Addr and data changes while the MSI-X entry is unmasked get deferred
+ * until the next masked -> unmasked transition.
+ */
+if (pirq == XEN_PT_UNASSIGNED_PIRQ || s->msix->maskall ||
+(vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+entry->addr = entry->latch(LOWER_ADDR) |
+  ((uint64_t)entry->latch(UPPER_ADDR) << 32);
+entry->data = entry->latch(DATA);
+}
+
 rc = msi_msix_setup(s, entry->addr, entry->data, &pirq, true, entry_nr,
 entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
 if (rc) {
@@ -357,7 +372,7 @@ int xen_pt_msix_update(XenPCIPassthrough
 int i;
 
 for (i = 0; i < msix->total_entries; i++) {
-xen_pt_msix_update_one(s, i);
+xen_pt_msix_update_one(s, i, msix->msix_entry[i].latch(VECTOR_CTRL));
 }
 
 return 0;
@@ -406,35 +421,15 @@ int xen_pt_msix_update_remap(XenPCIPasst
 
 static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
 {
-switch (offset) {
-case PCI_MSIX_ENTRY_LOWER_ADDR:
-return e->addr & UINT32_MAX;
-case PCI_MSIX_ENTRY_UPPER_ADDR:
-return e->addr >> 32;
-case PCI_MSIX_ENTRY_DATA:
-return e->data;
-case PCI_MSIX_ENTRY_VECTOR_CTRL:
-return e->vector_ctrl;
-default:
-return 0;
-}
+return !(offset % sizeof(*e->latch))
+   ? e->latch[offset / sizeof(*e->latch)] : 0;
 }
 
 static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
 {
-switch (offset) {
-case PCI_MSIX_ENTRY_LOWER_ADDR:
-e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
-break;
-case PCI_MSIX_ENTRY_UPPER_ADDR:
-e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
-break;
-case PCI_MSIX_ENTRY_DATA:
-e->data = val;
-break;
-case PCI_MSIX_ENTRY_VECTOR_CTRL:
-e->vector_ctrl = val;
-break;
+if (!(offset % sizeof(*e->latch)))
+{
+e->latch[offset / sizeof(*e->latch)] = val;
 }
 }
 
@@ -454,39 +449,26 @@ static void pci_msix_write(void *opaque,
 offset = addr % PCI_MSIX_ENTRY_SIZE;
 
 if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
-const volatile uint32_t *vec_ctrl;
-
 if (get_entry_value(entry, offset) == val
 && entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
 return;
 }
 
+entry->updated = true;
+} else if (msix->enabled && entry->updated &&
+   !(val & PCI_MSIX_ENTRY_CTRL_M

Re: [Xen-devel] [OSSTEST PATCH 12/16] Configuration: Introduce $c{Username}

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> This makes it easier to share the output of whoami.  As a beneficial
> side effect it can now be overridden.
> 
> Replace many open-coded calls to `whoami` etc. with references to
> $c{Username}.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 13/16] mg-schema-test-database: Change username for back-to-main-db xref

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> The `username' of the xdbref task in the test db, referring to the
> main db, is changed to `PARENT' (from `@').
> 
> Currently this is purely cosmetic, but it is going to be useful to
> distinguish the two cases:
>  * This is a test DB and contains references to a parent
>  * This is a parent DB (probably the main DB) which contains
>    references to child test DBS.

Did you mean "DBS" or just "DB"?

> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 14/16] mg-schema-test-database: Bump flight sequence number in test DB

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> This makes test flights have different numbers to those currently in
> production, which will help avoid accidents.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] blkback feature announcement

[Jan Beulich]

>>> On 08.12.15 at 12:06,  wrote:

> On 12/08/2015 04:13 PM, Jan Beulich wrote:
> On 08.12.15 at 02:08,  wrote:
>>> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
 El 07/12/15 a les 13.00, Jan Beulich ha escrit:
> Hello,
>
> is there a particular reason why "max-ring-page-order" gets written in
> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
> "feature-persistent" get written only in connect(), despite both having
> constant values (and hence the node value effectively being known as
> soon as the device exists)?

 No, AFAIK there's no specific reason.

>>>
>>> AFAIR, that's for the blkfront resume path.
>>>
>>> We need to get the "max-ring-page-order" in blkfront_resume() in advance, 
>>> so 
> 
>>> that we can know how many ring pages to be used before setup_blkring().
>> 
>> I don't follow - the proposal is to have the backend announce the
>> feature _earlier_, so how could frontend resume be affected?
>> 
> 
> The frontend resume is like this:
> 
> blkfront_resume()
>  > blkif_free()
>  > talk_to_blkback()
>  > setup_blkring() etc.
> 
> blkback_changed()
>  > blkfront_connect()
> 
> 
> Sometimes the "max-ring-page-order" of backend may have changed after the 
> guest(frontend) migrated to a different machine,
> the frontend must aware of this change so that have to get the new value of 
> "max-ring-page-order" in blkfront_resume().
> 
> But it would be too late if the backend announces the "max-ring-page-order" 
> in connect(), this situation is like:
> 
> blkfront_resume()
>  > blkif_free()
>  > talk_to_blkback()
>^^^ Get a wrong "max-ring-page-order"
>  > setup_blkring() etc. but using the wrong value!!
> 
> blkback_changed()
>  > blkfront_connect()
>^^^ Then the connect() in backend will be called(after frontend enter 
> XenbusStateConnected) and write the correct "max-ring-page-order", but it's 
> too late.

Oh, you're arguing for why "max-ring-page-order" is written early,
but the question really was why others aren't written early too.

Jan

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

Re: [Xen-devel] [OSSTEST PATCH 15/16] mg-schema-test-database: Safety catch in JobDB database open

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> When we open the `osstest' database, see whether this is a parent DB
> (main DB) from which a test DB has been spawned by this user.
> 
> If it has, bomb out, unless the user has specified a suitable regexp
> matching the DB name in the env var
>   OSSTEST_DB_USEREAL_IGNORETEST
> 
> This means that when a test database is in play, the user who created
> it cannot accidentally operate on the real DB.
> 
> The safety catch does not affect Tcl programs, which get the DB config
> directly, but in general that just means sg-execute-flight and
> sg-run-job which already have a fair amount of safety catch because
> they demand flight numbers.
> 
> mg-schema-test-database hits this feature over the head.  We assume
> that the caller of mg-schema-test-database knows what they are doing;
> particularly, that if they create nested test DBs (!), they do not
> need the assitance of this feature to stop themselves operating
> mg-schema-test-database incorrectly.  Anyone who creates nested test
> DBs will hopefully recognise the potential for confusion!
> 
> Signed-off-by: Ian Jackson 
> ---
>  Osstest/JobDB/Executive.pm |   33 -
>  mg-schema-test-database|2 ++
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
> index 2572f5f..29dbc6f 100644
> --- a/Osstest/JobDB/Executive.pm
> +++ b/Osstest/JobDB/Executive.pm
> @@ -51,8 +51,39 @@ sub current_flight ($) { #method
>  return $ENV{'OSSTEST_FLIGHT'};
>  }
>  
> +sub _check_testdbs ($) {
> +my ($dbh) = @_;
> +
> +my $re = $ENV{OSSTEST_DB_USEREAL_IGNORETEST} // '';
> +return if $re eq '.*'; # needed by mg-schema-test-database during
> setup
> +
> +# mg-schema-test-database creates a task
> +#   xdbref/DBNAME with username ${Username}@

Was there intended to be a wildcard or pattern of some sort after the @ in
this comment?

> +my $sth = $dbh->prepare(< +SELECT refkey AS dbname,
> +   username, comment
> +FROM tasks
> + WHERE type = 'xdbref'
> +   AND live
> +   AND username LIKE (? || '@%')

Nice of them to pick "||" as the string concatenation operator. It's almost
like they hate us C programmers...

Other than the comment thing above:
Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 12/16] Configuration: Introduce $c{Username}

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> This makes it easier to share the output of whoami.  As a beneficial
> side effect it can now be overridden.
> 
> Replace many open-coded calls to `whoami` etc. with references to
> $c{Username}.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] blkback feature announcement

[Bob Liu]

On 12/08/2015 07:13 PM, Jan Beulich wrote:
 On 08.12.15 at 12:06,  wrote:
> 
>> On 12/08/2015 04:13 PM, Jan Beulich wrote:
>> On 08.12.15 at 02:08,  wrote:
 On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>> Hello,
>>
>> is there a particular reason why "max-ring-page-order" gets written in
>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>> "feature-persistent" get written only in connect(), despite both having
>> constant values (and hence the node value effectively being known as
>> soon as the device exists)?
>
> No, AFAIK there's no specific reason.
>

 AFAIR, that's for the blkfront resume path.

 We need to get the "max-ring-page-order" in blkfront_resume() in advance, 
 so 
>>
 that we can know how many ring pages to be used before setup_blkring().
>>>
>>> I don't follow - the proposal is to have the backend announce the
>>> feature _earlier_, so how could frontend resume be affected?
>>>
>>
>> The frontend resume is like this:
>>
>> blkfront_resume()
>>  > blkif_free()
>>  > talk_to_blkback()
>>  > setup_blkring() etc.
>>
>> blkback_changed()
>>  > blkfront_connect()
>>
>>
>> Sometimes the "max-ring-page-order" of backend may have changed after the 
>> guest(frontend) migrated to a different machine,
>> the frontend must aware of this change so that have to get the new value of 
>> "max-ring-page-order" in blkfront_resume().
>>
>> But it would be too late if the backend announces the "max-ring-page-order" 
>> in connect(), this situation is like:
>>
>> blkfront_resume()
>>  > blkif_free()
>>  > talk_to_blkback()
>>   ^^^ Get a wrong "max-ring-page-order"
>>  > setup_blkring() etc. but using the wrong value!!
>>
>> blkback_changed()
>>  > blkfront_connect()
>>^^^ Then the connect() in backend will be called(after frontend enter 
>> XenbusStateConnected) and write the correct "max-ring-page-order", but it's 
>> too late.
> 
> Oh, you're arguing for why "max-ring-page-order" is written early,
> but the question really was why others aren't written early too.
> 

Oh, sorry for misunderstood your point.
Yes, I agree that others can be written early too.

-- 
Regards,
-Bob

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

Re: [Xen-devel] [OSSTEST PATCH 16/16] mg-schema-test-database: Add workflow doc comment

[Ian Campbell]

On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [RESEND][PATCH V9 3/7] libxl: add pvusb API

[George Dunlap]

On 08/12/15 05:50, Chun Yan Liu wrote:
> Any comments?

I'd just started looking at this yesterday. :-)

One comment for future reference: This series doesn't apply to staging,
nor to staging the date which you sent it (25 November); I had to apply
it to a commit before 5 November before it would apply cleanly.  In the
future please be sure when you send a series to rebase it to staging.

(No need to rebase it now until you have some comments to address.)

 -George

> 
 On 11/25/2015 at 05:46 PM, in message
> <1448444775-6974-4-git-send-email-cy...@suse.com>, Chunyan Liu 
> 
> wrote: 
>> Add pvusb APIs, including: 
>>  - attach/detach (create/destroy) virtual usb controller. 
>>  - attach/detach usb device 
>>  - list usb controller and usb devices 
>>  - some other helper functions 
>>  
>> Signed-off-by: Chunyan Liu  
>> Signed-off-by: Simon Cao  
>>  
>> --- 
>> changes: 
>>   - update naming, all places indicating usb controller named 
>> as usbctrl, all places indicating usb device named as usbdev 
>>   - update DEFINE_DEVICE_REMOVE instead of creating a new 
>> DEFINE_DEVICE_REMOVE_EXT 
>>   - use libxl__xs_read_checked instead of libxl__xs_read 
>>   - update local READ_SUBPATH(_INT) macros to include more common codes 
>>   - save drvpath before unbind 
>>   - get_assigned_devices: call libxl__device_usbdev_list_for_ctrl 
>> instead of doing all things from scratch 
>>   - usb_interface_xenstore_encode: use special char to avoid confusion 
>>   - usb readdir_r instead of readdir 
>>   - check syscall errno 
>>   - remove usbinfo definition 
>>   - address other comments except: 
>> libxl__device_usbdev_add/remove and do_usbdev_add/remove, in previous 
>> discussion, we'd like to get usbctrlinfo once and pass usbctrlinfo to 
>> do_usbdev_add/remove. However, during update, adding usbdev process 
>> still needs to try twice to get usbctrlinfo. (Before set_default, 
>> if usbctrl doesn't exist it doesn't doing getting usbctrlinfo actually; 
>> after set_default, needs to get usbctrlinfo then). So, finally, just 
>> change codes to make adding/removing process symmetrical. 
>>  
>>  tools/libxl/Makefile |2 +- 
>>  tools/libxl/libxl.c  |   50 +- 
>>  tools/libxl/libxl.h  |   77 ++ 
>>  tools/libxl/libxl_device.c   |5 +- 
>>  tools/libxl/libxl_internal.h |   18 + 
>>  tools/libxl/libxl_osdeps.h   |   13 + 
>>  tools/libxl/libxl_pvusb.c| 1534  
>> ++ 
>>  tools/libxl/libxl_types.idl  |   46 + 
>>  tools/libxl/libxl_types_internal.idl |1 + 
>>  tools/libxl/libxl_utils.c|   18 + 
>>  tools/libxl/libxl_utils.h|5 + 
>>  11 files changed, 1766 insertions(+), 3 deletions(-) 
>>  create mode 100644 tools/libxl/libxl_pvusb.c 
>>  
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
>> index 6ff5bee..a36145a 100644 
>> --- a/tools/libxl/Makefile 
>> +++ b/tools/libxl/Makefile 
>> @@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o  
>> libxl_dm.o libxl_pci.o \ 
>>  libxl_stream_read.o libxl_stream_write.o \ 
>>  libxl_save_callout.o _libxl_save_msgs_callout.o \ 
>>  libxl_qmp.o libxl_event.o libxl_fork.o \ 
>> -libxl_dom_suspend.o $(LIBXL_OBJS-y) 
>> +libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y) 
>>  LIBXL_OBJS += libxl_genid.o 
>>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
>>   
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
>> index eaa7d75..a479465 100644 
>> --- a/tools/libxl/libxl.c 
>> +++ b/tools/libxl/libxl.c 
>> @@ -4144,6 +4144,36 @@ out: 
>>  return rc; 
>>  } 
>>   
>> +static void libxl__initiate_device_disk_remove(libxl__egc *egc, 
>> +   libxl__ao_device *aodev) 
>> +{ 
>> +return libxl__initiate_device_remove(egc, aodev); 
>> +} 
>> + 
>> +static void libxl__initiate_device_nic_remove(libxl__egc *egc, 
>> +  libxl__ao_device *aodev) 
>> +{ 
>> +return libxl__initiate_device_remove(egc, aodev); 
>> +} 
>> + 
>> +static void libxl__initiate_device_vtpm_remove(libxl__egc *egc, 
>> +   libxl__ao_device *aodev) 
>> +{ 
>> +return libxl__initiate_device_remove(egc, aodev); 
>> +} 
>> + 
>> +static void libxl__initiate_device_vkb_remove(libxl__egc *egc, 
>> +  libxl__ao_device *aodev) 
>> +{ 
>> +return libxl__initiate_device_remove(egc, aodev); 
>> +} 
>> + 
>> +static void libxl__initiate_device_vfb_remove(libxl__egc *egc, 
>> +  libxl__ao_device *aodev) 
>> +{ 
>> +return libxl__initiate_device_remove(egc, aodev); 
>> +} 
>> + 
>>   
>> /*

Re: [Xen-devel] Double gnttab_end_access in mini-os netfront

[Ian Campbell]

On Sun, 2015-12-06 at 03:19 +0100, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> When running HVM on Xen 4.6 with qemu in stubdom, I've found that
> something goes wrong with disk frontend (at least that was visible
> problem - a lot of read and write errors in stubdom log). But further
> debugging (including -DGNT_DEBUG) leads to double gnttab_end_access in
> netfront. 
> 
> The stack trace is:
> ASSERTION FAILED: !(!inuse[ref]) at gnttab.c:42.
> Do_exit called!
> 0x000f3ffb: get_time_values_from_xen at xen-4.6.0/extras/mini-
> os/arch/x86/time.c:134 (discriminator 1)
> 0x000d74a8: HYPERVISOR_sched_op at xen-4.6.0/extras/mini-
> os/include/x86/x86_64/hypercall-x86_64.h:180
> 0x000d6a2e: put_free_entry at xen-4.6.0/extras/mini-
> os/gnttab.c:43
> 0x000d6bff: gnttab_end_access at xen-4.6.0/extras/mini-
> os/gnttab.c:115
> 0x000d8a50: network_rx at xen-4.6.0/extras/mini-os/netfront.c:134
> 0x000d9ec4: netfront_receive at xen-4.6.0/extras/mini-
> os/netfront.c:671
> 0x000dd302: get_current at xen-4.6.0/extras/mini-
> os/include/x86/arch_sched.h:16
> 0x00079f72: tap_send at xen-4.6.0/stubdom/../tools/qemu-xen-
> traditional/net.c:756
> 0x69f9: main_loop_wait at xen-4.6.0/stubdom/../tools/qemu-
> xen-traditional/vl.c:3826
> 0x00021f27: main_loop at xen-4.6.0/stubdom/../tools/qemu-xen-
> traditional/i386-dm/helper2.c:612 (discriminator 1)
> 0x950d: quit_timers at xen-4.6.0/stubdom/../tools/qemu-xen-
> traditional/vl.c:1866
> 0x000d7f57: call_main at xen-4.6.0/extras/mini-os/main.c:163
> 0x3423: thread_starter at :?
> 0x: _start at ??:?
> 
> It was working in Xen 4.4. The only commit touching xenfront.c (in any
> meaningful way) from that time is this one:
> http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f348390652a67e
> 9356eec9cd2b0f76a9c7c72
> 
> With that commit reverted, issue vanishes.
> 
> I guess it's because before this commit, there was "if (rx->status ==
> NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)", but now
> that case is handled after gnttab_end_access (using "if (rx->status >
> NETIF_RSP_NULL)"). I think the fix would be to restore that "continue"
> line.

That sounds pretty plausible to me (FWIW). Have you tried it?

> PS What is the correct place for such reports? minios-devel? xen-devel?
> both?

Formally I suppose the former, but realistically including xen-devel as
well is likely to attract more eyes.

Ian.

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

Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid

[Andrew Cooper]

On 08/12/15 08:28, Jan Beulich wrote:
 On 07.12.15 at 17:48,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu 
>> *v, uint64_t value,
>>  {
>>  unsigned int level;
>>  
>> -ASSERT(v == current);
>> +ASSERT(v->domain == current->domain);
>>  hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
>>  if ( level >= 0x8001 )
>>  {
>> @@ -1912,7 +1912,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const 
>> struct vcpu *v,
>>  {
>>  unsigned int level;
>>  
>> -ASSERT(v == current);
>> +ASSERT(v->domain == current->domain);
>>  hvm_cpuid(0, &level, NULL, NULL, NULL);
>>  if ( level >= 1 )
>>  hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
> The only reason both functions get v passed are the two ASSERT()s.
> Relaxing them means you should now be passing a const struct
> domain * instead.

v is correct here.  cpuid information is genuinely per-vcpu, although
this isn't currently reflected in Xen's understanding of the matter.

Part of my further cpuid improvements will be to fix Xen's
understanding. i.e. domain_cpuid() will soon start taking a vcpu parameter.

~Andrew

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

Re: [Xen-devel] Double gnttab_end_access in mini-os netfront

[Marek Marczykowski-Górecki]

On Tue, Dec 08, 2015 at 11:33:49AM +, Ian Campbell wrote:
> On Sun, 2015-12-06 at 03:19 +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > When running HVM on Xen 4.6 with qemu in stubdom, I've found that
> > something goes wrong with disk frontend (at least that was visible
> > problem - a lot of read and write errors in stubdom log). But further
> > debugging (including -DGNT_DEBUG) leads to double gnttab_end_access in
> > netfront. 
> > 
> > The stack trace is:
> > ASSERTION FAILED: !(!inuse[ref]) at gnttab.c:42.
> > Do_exit called!
> > 0x000f3ffb: get_time_values_from_xen at xen-4.6.0/extras/mini-
> > os/arch/x86/time.c:134 (discriminator 1)
> > 0x000d74a8: HYPERVISOR_sched_op at xen-4.6.0/extras/mini-
> > os/include/x86/x86_64/hypercall-x86_64.h:180
> > 0x000d6a2e: put_free_entry at xen-4.6.0/extras/mini-
> > os/gnttab.c:43
> > 0x000d6bff: gnttab_end_access at xen-4.6.0/extras/mini-
> > os/gnttab.c:115
> > 0x000d8a50: network_rx at xen-4.6.0/extras/mini-os/netfront.c:134
> > 0x000d9ec4: netfront_receive at xen-4.6.0/extras/mini-
> > os/netfront.c:671
> > 0x000dd302: get_current at xen-4.6.0/extras/mini-
> > os/include/x86/arch_sched.h:16
> > 0x00079f72: tap_send at xen-4.6.0/stubdom/../tools/qemu-xen-
> > traditional/net.c:756
> > 0x69f9: main_loop_wait at xen-4.6.0/stubdom/../tools/qemu-
> > xen-traditional/vl.c:3826
> > 0x00021f27: main_loop at xen-4.6.0/stubdom/../tools/qemu-xen-
> > traditional/i386-dm/helper2.c:612 (discriminator 1)
> > 0x950d: quit_timers at xen-4.6.0/stubdom/../tools/qemu-xen-
> > traditional/vl.c:1866
> > 0x000d7f57: call_main at xen-4.6.0/extras/mini-os/main.c:163
> > 0x3423: thread_starter at :?
> > 0x: _start at ??:?
> > 
> > It was working in Xen 4.4. The only commit touching xenfront.c (in any
> > meaningful way) from that time is this one:
> > http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f348390652a67e
> > 9356eec9cd2b0f76a9c7c72
> > 
> > With that commit reverted, issue vanishes.
> > 
> > I guess it's because before this commit, there was "if (rx->status ==
> > NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)", but now
> > that case is handled after gnttab_end_access (using "if (rx->status >
> > NETIF_RSP_NULL)"). I think the fix would be to restore that "continue"
> > line.
> 
> That sounds pretty plausible to me (FWIW). Have you tried it?

I've tried moving gnttab_end_access into that if branch. And it didn't
worked.

> > PS What is the correct place for such reports? minios-devel? xen-devel?
> > both?
> 
> Formally I suppose the former, but realistically including xen-devel as
> well is likely to attract more eyes.
> 
> Ian.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


pgpoNWwNfJQpJ.pgp
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Double gnttab_end_access in mini-os netfront

[Samuel Thibault]

Ian Campbell, on Tue 08 Dec 2015 11:33:49 +, wrote:
> > http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f348390652a67e
> > 9356eec9cd2b0f76a9c7c72
> > 
> > With that commit reverted, issue vanishes.
> > 
> > I guess it's because before this commit, there was "if (rx->status ==
> > NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)", but now
> > that case is handled after gnttab_end_access (using "if (rx->status >
> > NETIF_RSP_NULL)"). I think the fix would be to restore that "continue"
> > line.
> 
> That sounds pretty plausible to me (FWIW). Have you tried it?

That looks right, indeed.

Samuel

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

Re: [Xen-devel] Double gnttab_end_access in mini-os netfront

[Samuel Thibault]

Marek Marczykowski-Górecki, on Tue 08 Dec 2015 12:46:31 +0100, wrote:
> > > http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f348390652a67e
> > > 9356eec9cd2b0f76a9c7c72
> > > 
> > > With that commit reverted, issue vanishes.
> > > 
> > > I guess it's because before this commit, there was "if (rx->status ==
> > > NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)", but now
> > > that case is handled after gnttab_end_access (using "if (rx->status >
> > > NETIF_RSP_NULL)"). I think the fix would be to restore that "continue"
> > > line.
> > 
> > That sounds pretty plausible to me (FWIW). Have you tried it?
> 
> I've tried moving gnttab_end_access into that if branch. And it didn't
> worked.

Which if branch?  Please show the code, C is less ambiguous than english
:)

Samuel

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

[Xen-devel] Xen Security Advisory 158 (CVE-2015-8338) - long running memory operations on ARM

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2015-8338 / XSA-158
  version 3

long running memory operations on ARM

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

Certain HYPERVISOR_memory_op subops take page order inputs, with so far
insufficient enforcement of limits thereof. In particular, for all of
XENMEM_increase_reservation, XENMEM_populate_physmap, and
XENMEM_exchange the order was limited to 9 only for guests without
physical devices assigned. Guests with assigned devices were allowed up
to order 18 (x86) or 20 (ARM). XENMEM_decrease_reservation enforced
only the latter, higher limit uniformly on all kinds of guests.

All of these operations involve loops over individual pages (possibly
nested, with only the iteration count of the innermost loop being of
interest here), resulting in iteration counts of up to 1 million on
ARM. Total execution time of these operations obviously depends on
system speed, but have been measured to get into the seconds range.

IMPACT
==

A malicious guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant period.
Other attacks, namely privilege escalation, cannot be ruled out.

If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host.  If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.

VULNERABLE SYSTEMS
==

All Xen versions supporting ARM are affected.

x86 versions of Xen are unaffected.

MITIGATION
==

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.  On
ARM, controlling the guest's kernel may involve locking down the
bootloader.

Exposure may be limited by not passing through physical devices to
untrusted guests.

(However, where device pass-through is being used to enhance security,
for example, by disaggregating device drivers, users should not change
their configuration: moving the drivers from a separate domain, to
dom0, does NOT mitigate this vulnerability.  Rather, it simply
recategorises the additional exposure, regarding it "as designed" and
therefore "not a bug".  Users and vendors of disaggregated systems
should not change their configuration.)

CREDITS
===

This issue was discovered by Julien Grall of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa158.patch  xen-unstable, Xen 4.6.x, Xen 4.5.x
xsa158-4.4.patch  Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa158*
50d7431cbad8faa631e2057ddd795b880f79b96d126a0b83afef3eceacf0026d  xsa158.patch
54b538905e66227bf7f326006a7c322bdf35c76ad8600ff462e61d6e2eab6f04  
xsa158-4.4.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the PATCH (or others which are substantially similar) is
permitted during the embargo, even on public-facing systems with
untrusted guest users and administrators.


However deployment of the NO PASS-THROUGH partial MITIGATION is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

This is because altering the set of devices observable in a guest in
connection with a security issue would be a user-visible change which
could lead to the rediscovery of the vulnerability.

Deployment of the mitigation is permitted only AFTER the embargo ends.


Also: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWZr8FAAoJEIP+FMlX6CvZS7UIAKtjK/KGZxAv3L38qTlldHhF
BAYuZvlDt4wJEKYd9wUbN5nqXAL23muKj+oOLjS4PRHnsNKAjyKicJEFDIpLGr9z
fLKqmWvxnDexP3tjiUqz5z8IOpGTMgFPPl9kosYXhBiQAIrrlTigL+umYSGlIsB1
MkLfW1ZST3H7eoBzNkFEpGsMTjAtnYJfYwZp2MLC8sbdNq04RWbiIqljEb61ULdi
CXAFoiVcDiNbRrT2LRFwfAIM2mtzi6Me0GUMmGrdsfg0rlmgxHVItPLEd8

[Xen-devel] Xen Security Advisory 159 (CVE-2015-8339, CVE-2015-8340) - XENMEM_exchange error handling issues

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Xen Security Advisory CVE-2015-8339,CVE-2015-8340 / XSA-159
  version 4

 XENMEM_exchange error handling issues

UPDATES IN VERSION 4


Public release.

ISSUE DESCRIPTION
=

Error handling in the operation may involve handing back pages to
the domain. This operation may fail when in parallel the domain gets
torn down. So far this failure unconditionally resulted in the host
being brought down due to an internal error being assumed. This is
CVE-2015-8339.

Furthermore error handling so far wrongly included the release of a
lock. That lock, however, was either not acquired or already released
on all paths leading to the error handling sequence. This is
CVE-2015-8340.

IMPACT
==

A malicious guest administrator may be able to deny service by
crashing the host or causing a deadlock.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Older
versions have not been inspected.

MITIGATION
==

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.  In
Xen HVM, controlling the guest's kernel would involve locking down the
bootloader.

CREDITS
===

This issue was discovered by Julien Grall of Citrix and
Jan Beulich of SUSE.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa159.patch  xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa159*
05c35871c1430e9cfdbee049411b23fca6c64c5bc9f112d7508afe5cbd289cef  xsa159.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWZr8HAAoJEIP+FMlX6CvZXp8IAMNhe/G7435bJNiwMbWIT6vt
8piJPArKxhd3yohEiAx0wG7BXTQ7ockAKFCjdSL8ZGPQuaxwuYrdm4wH14ucxRY6
wgHyU2766g5VuP1bJ1eU/XxZpNGWCqDQaaMzbwQLKVO7rhsZc14txY2nYFZ5cvLT
nMDR8rfcNSeGMSCzg9vrdnFhmmslT797fgRXrCnZ2+bEDerTiYu5nDlS+aIZPiSt
WwKbiYN/RJLIo4EThvYfPdbm9SPeSdNYNUws2MVkl50x2h4hm33eqKDNxAtUMgDq
CZzHQGCMjAtrhK/64AQePiXRHO4SHYbX4FmeO9Yrkbgf971PqpEYed79UJ2a0SA=
=sIvq
-END PGP SIGNATURE-


xsa159.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 160 (CVE-2015-8341) - libxl leak of pv kernel and initrd on error

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2015-8341 / XSA-160
  version 3

  libxl leak of pv kernel and initrd on error

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

When constructing a guest which is configured to use a PV bootloader
which runs as a userspace process in the toolstack domain
(e.g. pygrub) libxl creates a mapping of the files to be used as
kernel and initial ramdisk when building the guest domain.

However if building the domain subsequently fails these mappings would
not be released leading to a leak of virtual address space in the
calling process, as well as preventing the recovery of the temporary
disk files containing the kernel and initial ramdisk.

IMPACT
==

For toolstacks which manage multiple domains within the same process,
an attacker who is able to repeatedly start a suitable domain (or many
such domains) can cause an out-of-memory condition in the toolstack
process, leading to a denial of service.

Under the same circumstances an attacker can also cause files to
accumulate on the toolstack domain filesystem (usually under /var in
dom0) used to temporarily store the kernel and initial ramdisk,
perhaps leading to a denial of service against arbitrary other
services using that filesystem.

VULNERABLE SYSTEMS
==

Both ARM and x86 systems using a libxl based toolstack are potentially
vulnerable.

Only libxl-based toolstacks which manage multiple domains in the same
process (such as `libvirt') are vulnerable.

libxl-based toolstacks which manage only a single domain per process
and which exit on failure to create a domain (such as `xl') are not
vulnerable.

Toolstacks not using libxl are not vulnerable to this issue.

Only domains configured to use a PV bootloader in the toolstack domain
(e.g. pygrub) will expose this issue.  Domains configured to use
pvgrub (a totally different program) are not vulnerable.

x86 HVM domains are not vulnerable.

Systems where the kernel and initial ramdisk are provided by the host
administrator from files in domain 0 are not vulnerable.

Xen versions 4.1.x and later are vulnerable.

MITIGATION
==

Avoiding the use of the PV bootloader mechanisms which run as
processes in the toolstack domain (pygrub), either by providing
kernels directly from the toolstack domain or using a PV bootloader
which runs in guest context (such as pvgrub) will prevent exposure of
this issue.

CREDITS
===

This issue was discovered by George Dunlap of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa160.patch   xen-unstable
xsa160-4.6.patch   Xen 4.5.x, 4.6.x
xsa160-4.4.patch   Xen 4.3.x, 4.4.x

$ sha256sum xsa160*
470811aeead5e942d6fedad5b4e21bee85f2160b022bcab315520014b6aa39a6  xsa160.patch
d0ce9e3c2b951ac3d25da4a0f6f232b13980625a249ed9c4cd6e9484721943a5  
xsa160-4.4.patch
40362873b7fa2c1450596ef9ea23c73f80608b77ca50b89e62daf46c131fcee6  
xsa160-4.6.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patch described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

However deployment of the mitigations described above is not permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because such a change to the bootloader arrangements of a PV
guest would be a user-visible change which could lead to the
rediscovery of the vulnerability.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWZr8JAAoJEIP+FMlX6CvZfEYH/Rg7X9HdB+937h81tq30nrkE
/PazyPDB8DprHL0X/IjPEQFvGOazCf45uzSzkrPXaFwu27yhbAxx/m8s94FxUjWb
EiWwYKsb0Gh9OBejRkgiB3VMQmySWqkcjzUR1f2hk4iJ3yX8q2peRECK/Ba9aYPu
lHN9aycnh1ORPmWPUUo8cMFhRVag1P5E77mqrxXo2nfed23xDA5GeZceg8XoT67n
T2m59xAEwrSrHypb/XESuwtEU67CnowRcxlH7Z3EEk+ljvxOBvdovNp0yztOtArK
EnV3UAwM+YMXvoYB4YZUQ/q9tZ1dIgyeTosOSoNHI471lBYL9QTlO22bc4+qKCE=
=IjJr
-END PGP SIGNATURE-


xsa1

Re: [Xen-devel] [PATCH OSSTEST] mg-hosts: document "power" command

[Ian Campbell]

On Mon, 2015-12-07 at 17:24 +, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
>  mg-hosts | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mg-hosts b/mg-hosts
> index a911099..0d02c56 100755
> --- a/mg-hosts
> +++ b/mg-hosts
> @@ -24,6 +24,13 @@
>  #   of osstest.  Will use "sudo". The HOST(s) must be
>  #   allocated (via mg-allocate HOST).
>  #
> +#  ./mg-hosts power HOST ACTION
> +#   Power cycles the host. Host must be allocated to the
> current
> +#   user.  Actions are:
> +#"0" or "on": power on
> +#"1" or "off"   : power off
> +#"c" or "r" : reboot

I think in reality the ACTION needs merely to start with any of those
strings, but in the interests of not making the docs too confusing I think
the above is good.

Acked-by: Ian Campbell 

(c is for "cycle" I guess?)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] Double gnttab_end_access in mini-os netfront

[Ian Campbell]

On Tue, 2015-12-08 at 13:00 +0100, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Tue 08 Dec 2015 12:46:31 +0100, wrote:
> > > > http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f3483906
> > > > 52a67e
> > > > 9356eec9cd2b0f76a9c7c72
> > > > 
> > > > With that commit reverted, issue vanishes.
> > > > 
> > > > I guess it's because before this commit, there was "if (rx->status
> > > > ==
> > > > NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)",
> > > > but now
> > > > that case is handled after gnttab_end_access (using "if (rx->status 
> > > > >
> > > > NETIF_RSP_NULL)"). I think the fix would be to restore that
> > > > "continue"
> > > > line.
> > > 
> > > That sounds pretty plausible to me (FWIW). Have you tried it?
> > 
> > I've tried moving gnttab_end_access into that if branch. And it didn't
> > worked.
> 
> Which if branch?  Please show the code, C is less ambiguous than english
> :)

Details of in which way it didn't work would also be useful, I expect.

Ian.

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

Re: [Xen-devel] [PATCH v3 1/6] xl: Return proper error codes for block-attach and block-detach

[George Dunlap]

On Tue, Dec 1, 2015 at 11:53 AM, George Dunlap
 wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
>
> Also while we're at it, normalize init and dispose of
> libxl_device_disk structures.  This means calling init and dispose in
> the actual functions where they are declared.
>
> This in turn means changing parse_disk_config_multistring() to not
> call libxl_device_disk_init.  And that in turn means changes to
> callers of parse_disk_config().
>
> It also means removing libxl_device_disk_init() from
> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> xl_cmdimpl.c.
>
> Signed-off-by: George Dunlap 

Ping?
 -George

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Wilk 
>
> v3:
>  - Rebased to tip
>
> v2:
>  - Restructure functions to make sure init and dispose are properly
>  called.
> ---
>  tools/libxl/libxl.c  |  2 --
>  tools/libxl/xl_cmdimpl.c | 29 -
>  2 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index bd3aac8..814d056 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2738,8 +2738,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t 
> domid,
>  if (devid < 0)
>  return ERROR_INVAL;
>
> -libxl_device_disk_init(disk);
> -
>  dompath = libxl__xs_get_dompath(gc, domid);
>  if (!dompath) {
>  goto out;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2b6371d..2ba2393 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -570,8 +570,6 @@ static void parse_disk_config_multistring(XLU_Config 
> **config,
>  {
>  int e;
>
> -libxl_device_disk_init(disk);
> -
>  if (!*config) {
>  *config = xlu_cfg_init(stderr, "command line");
>  if (!*config) { perror("xlu_cfg_init"); exit(-1); }
> @@ -3340,6 +3338,8 @@ static int cd_insert(uint32_t domid, const char 
> *virtdev, char *phys)
>  xasprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
>virtdev, phys ? phys : "");
>
> +libxl_device_disk_init(&disk);
> +
>  parse_disk_config(&config, buf, &disk);
>
>  /* ATM the existence of the backing file is not checked for qdisk
> @@ -6649,6 +6649,7 @@ int main_blockattach(int argc, char **argv)
>  uint32_t fe_domid;
>  libxl_device_disk disk;
>  XLU_Config *config = 0;
> +int rc = 0;
>
>  SWITCH_FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
>  /* No options */
> @@ -6660,6 +6661,8 @@ int main_blockattach(int argc, char **argv)
>  }
>  optind++;
>
> +libxl_device_disk_init(&disk);
> +
>  parse_disk_config_multistring
>  (&config, argc-optind, (const char* const*)argv + optind, &disk);
>
> @@ -6668,14 +6671,17 @@ int main_blockattach(int argc, char **argv)
>  printf("disk: %s\n", json);
>  free(json);
>  if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
> -return 0;
> +goto out;
>  }
>
>  if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
>  fprintf(stderr, "libxl_device_disk_add failed.\n");
> -return 1;
> +rc = 1;
>  }
> -return 0;
> +out:
> +libxl_device_disk_dispose(&disk);
> +
> +return rc;
>  }
>
>  int main_blocklist(int argc, char **argv)
> @@ -6726,18 +6732,23 @@ int main_blockdetach(int argc, char **argv)
>  /* No options */
>  }
>
> +libxl_device_disk_init(&disk);
> +
>  domid = find_domain(argv[optind]);
>
>  if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
>  fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
> -return 1;
> +rc = 1;
> +goto out;
>  }
> -rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
> -if (rc) {
> +if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
>  fprintf(stderr, "libxl_device_disk_remove failed.\n");
> -return 1;
> +rc = 1;
>  }
> +
> +out:
>  libxl_device_disk_dispose(&disk);
> +
>  return rc;
>  }
>
> --
> 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

Re: [Xen-devel] [PATCH v2] libxl: Introduce a template for devices with a controller

[George Dunlap]

On Tue, Dec 1, 2015 at 12:09 PM, George Dunlap
 wrote:
> We have several outstanding patch series which add devices that have
> two levels: a controller and individual devices attached to that
> controller.
>
> In the interest of consistency, this patch introduces a section that
> sketches out a template for interfaces for such devices.
>
> Signed-off-by: George Dunlap 
> Acked-by: Juergen Gross 

Committers,

Is there anything else that needs to be done for this to be checked in?

 -George

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> CC: Chun Yan Liu 
> CC: Olaf Hering 
>
> Changes in v2:
> - Fixed typos
>
> Changes in v1 (since the RFC):
>
> - Use  rather than , and  rather than specifying
>   controller and device.  The idea being to allow SCSI to use
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
>   rather than naming things after USB (controller & device).
>
> - Do not require each  to have a deviceid, but just a unique
>   naming schema.
>
> - Allow multiple levels.
>
> - Include the paragraph about domain configuration lists.
> ---
>  tools/libxl/libxl.h | 65 
> +
>  1 file changed, 65 insertions(+)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b73848..44e2951 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
> nr_vtpms);
>   *
>   *   This function does not interact with the guest and therefore
>   *   cannot block on the guest.
> + *
> + * Controllers
> + * ---
> + *
> + * Most devices are treated individually.  Some classes of device,
> + * however, like USB or SCSI, inherently have the need to have a
> + * hierarchy of different levels, with lower-level devices "attached"
> + * to higher-level ones.  USB for instance has "controllers" at the
> + * top, which have buses, on which are devices, which consist of
> + * multiple interfaces.  SCSI has "hosts" at the top, then buses,
> + * targets, and LUNs.
> + *
> + * In that case, for each , there will be a set of functions
> + * and types for each .  For example, for =usb, there
> + * may be  ctrl (controller) and dev (device), with ctrl being
> + * level 0.
> + *
> + * libxl_device__ will act more or
> + * less like top-level non-bus devices: they will either create or
> + * accept a libxl_devid which will be unique within the
> + *  libxl_devid namespace.
> + *
> + * Lower-level devices must have a unique way to be identified.  One
> + * way to do this would be to name it via the name of the next level
> + * up plus an index; for instance, .  Another
> + * way would be to have another devid namespace for that level.  This
> + * identifier will be used for queries and removals.
> + *
> + * Lower-level devices will include in their
> + * libxl_device_ struct a field referring to the unique
> + * index of the level above.  For instance, libxl_device_usbdev might
> + * contain the controller devid.
> + *
> + * In the case where there are multiple different ways to implement a
> + * given device -- for instance, one which is fully PV and one which
> + * uses an emulator -- the controller will contain a field which
> + * specifies what type of implementation is used.  The implementations
> + * of individual devices will be known by the controller to which they
> + * are attached.
> + *
> + * If libxl_device__add receives an empty reference to
> + * the level above, it may return an error.  Or it may (but is not
> + * required to) automatically choose a suitable device in the level
> + * above to which to attach the new device at this level.  It may also
> + * (but is not required to) automatically create a new device at the
> + * level above if no suitable devices exist.  Each class should
> + * document its behavior.
> + *
> + * libxl_device__list will list all devices of 
> + * at  in the domain.  For example, libxl_device_usbctrl_list
> + * will list all usb controllers; libxl_class_usbdev_list will list
> + * all usb devices across all controllers.
> + *
> + * For each class, the domain config file will contain a single list
> + * for each level.  libxl will first iterate through the list of
> + * top-level devices, then iterate through each level down in turn,
> + * adding devices to devices in the level above.  For instance, there
> + * will be one list for all usb controllers, and one list for all usb
> + * devices.
> + *
> + * If libxl_device__add automatically creates
> + * higher-level devices as necessary, then it is permissible for the
> + * higher-level lists to be empty and the device list to have devices
> + * with the field containing a reference to the higher level device
> + * uninitialized.
>   */
>
>  /* Disks */
> --
> 2.1.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_

Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

[Julien Grall]

Hi Konrad,

The rebase of my patch is not correct. It now contains an unused variable and
missing one change.

I will post the rebase of the two patches.

On 01/12/15 18:52, Konrad Rzeszutek Wilk wrote:
> +static unsigned long blkif_ring_get_request(struct blkfront_ring_info *rinfo,
> + struct request *req,
> + struct blkif_request **ring_req)
> +{
> + unsigned long id;
> + struct blkfront_info *info = rinfo->dev_info;

This variable is unused within the function.

> +
> + *ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> + rinfo->ring.req_prod_pvt++;
> +
> + id = get_id_from_freelist(rinfo);
> + rinfo->shadow[id].request = req;
> +
> + (*ring_req)->u.rw.id = id;
> +
> + return id;
> +}
> +
>  static int blkif_queue_discard_req(struct request *req, struct 
> blkfront_ring_info *rinfo)
>  {
>   struct blkfront_info *info = rinfo->dev_info;
> @@ -488,9 +506,7 @@ static int blkif_queue_discard_req(struct request *req, 
> struct blkfront_ring_inf
>   unsigned long id;
>  
>   /* Fill out a communications ring structure. */
> - ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> - id = get_id_from_freelist(rinfo);
> - rinfo->shadow[id].request = req;
> + id = blkif_ring_get_request(rinfo, req, &ring_req);
>  
>   ring_req->operation = BLKIF_OP_DISCARD;
>   ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
> @@ -501,8 +517,6 @@ static int blkif_queue_discard_req(struct request *req, 
> struct blkfront_ring_inf
>   else
>   ring_req->u.discard.flag = 0;
>  
> - rinfo->ring.req_prod_pvt++;
> -
>   /* Keep a private copy so we can reissue requests when recovering. */
>   rinfo->shadow[id].req = *ring_req;
>  
> @@ -635,9 +649,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
> blkfront_ring_info *ri
>   }
>  
>   /* Fill out a communications ring structure. */
> - ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
> - id = get_id_from_freelist(rinfo);
> - rinfo->shadow[id].request = req;
> + id = blkif_ring_get_request(rinfo, req, &ring_req);
>  
>   BUG_ON(info->max_indirect_segments == 0 &&
>  GREFS(req->nr_phys_segments) > BLKIF_MAX_SEGMENTS_PER_REQUEST);

@@ -650,7 +661,6 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
for_each_sg(rinfo->shadow[id].sg, sg, num_sg, i)
   num_grant += gnttab_count_grant(sg->offset, sg->length);
 
-   ring_req->u.rw.id = id;
rinfo->shadow[id].num_sg = num_sg;
if (num_grant > BLKIF_MAX_SEGMENTS_PER_REQUEST) {
/*

> @@ -716,8 +728,6 @@ static int blkif_queue_rw_req(struct request *req, struct 
> blkfront_ring_info *ri
>   if (setup.segments)
>   kunmap_atomic(setup.segments);
>  
> - rinfo->ring.req_prod_pvt++;
> -
>   /* Keep a private copy so we can reissue requests when recovering. */
>   rinfo->shadow[id].req = *ring_req;

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [Minios-devel] Double gnttab_end_access in mini-os netfront

[Marek Marczykowski-Górecki]

On Tue, Dec 08, 2015 at 12:11:34PM +, Ian Campbell wrote:
> On Tue, 2015-12-08 at 13:00 +0100, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Tue 08 Dec 2015 12:46:31 +0100, wrote:
> > > > > http://xenbits.xen.org/gitweb/?p=mini-os.git;a=commit;h=7c8f3483906
> > > > > 52a67e
> > > > > 9356eec9cd2b0f76a9c7c72
> > > > > 
> > > > > With that commit reverted, issue vanishes.
> > > > > 
> > > > > I guess it's because before this commit, there was "if (rx->status
> > > > > ==
> > > > > NETIF_RSP_NULL) continue" before "gnttab_end_access(buf->gref)",
> > > > > but now
> > > > > that case is handled after gnttab_end_access (using "if (rx->status 
> > > > > >
> > > > > NETIF_RSP_NULL)"). I think the fix would be to restore that
> > > > > "continue"
> > > > > line.
> > > > 
> > > > That sounds pretty plausible to me (FWIW). Have you tried it?
> > > 
> > > I've tried moving gnttab_end_access into that if branch. And it didn't
> > > worked.
> > 
> > Which if branch?  Please show the code, C is less ambiguous than english
> > :)
> 
> Details of in which way it didn't work would also be useful, I expect.

I don't have my test environment handy, but the change was:
--- netfront.c.orig 2015-12-08 13:29:04.91300 +0100
+++ netfront.c  2015-12-08 13:29:24.06000 +0100
@@ -122,10 +122,10 @@
 
 buf = &dev->rx_buffers[id];
 page = (unsigned char*)buf->page;
-gnttab_end_access(buf->gref);
 
 if (rx->status > NETIF_RSP_NULL)
 {
+gnttab_end_access(buf->gref);
 #ifdef HAVE_LIBC
if (dev->netif_rx == NETIF_SELECT_RX) {
int len = rx->status;


But to be frank, I'm not entirely sure that the tested version was
really with this patch, as stubdom building code is quite convolved...
The crash was the same, but I'll test it again to be sure.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


pgpOPq0xI6iCf.pgp
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages

[Julien Grall]

Hi Royger,

On 01/12/15 15:30, Roger Pau Monné wrote:
> Just a couple of cosmetic comments below. Unless anyone else has real
> comments I don't think you need to resend.

Well, I'm considering those kind of comestic comments as minor. They are
not necessary and doesn't improve the readability of the code. It even
make it worth in the two cases.

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

[Julien Grall]

Hi Konrad,

On 07/12/15 15:01, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 07, 2015 at 02:21:46PM +, Julien Grall wrote:
>> Thank you, the changes look good to me. What about patch #2?
> 
> Oh, I thought you said you would rebase it - so I had been waiting
> for that.
> 
> Should have communicated that much better.
> 
> If it wouldn't be too much trouble - could you rebase #2 please?

I'm also providing a rebase of #1 because your wasn't correct. See
attachments.

git://xenbits.xen.org/people/julieng/linux-arm.git
branch blkfront-64-indirect-v4

Regards,

-- 
Julien Grall
>From 2e3c97be628f010891c5e1ce807bd649ede32b93 Mon Sep 17 00:00:00 2001
From: Julien Grall 
Date: Thu, 13 Aug 2015 19:23:10 +0100
Subject: [PATCH 1/2] block/xen-blkfront: Introduce blkif_ring_get_request
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The code to get a request is always the same. Therefore we can factorize
it in a single function.

Signed-off-by: Julien Grall 
Acked-by: Roger Pau Monné 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Bob Liu 

Changes in v4:
- Rebase on top of konrad/devel/for-jens-4.5

Changes in v2:
- Add Royger's acked-by
---
 drivers/block/xen-blkfront.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 4f77d36..33a80d5 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -481,6 +481,23 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
 	return 0;
 }

+static unsigned long blkif_ring_get_request(struct blkfront_ring_info *rinfo,
+	struct request *req,
+	struct blkif_request **ring_req)
+{
+	unsigned long id;
+
+	*ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
+	rinfo->ring.req_prod_pvt++;
+
+	id = get_id_from_freelist(rinfo);
+	rinfo->shadow[id].request = req;
+
+	(*ring_req)->u.rw.id = id;
+
+	return id;
+}
+
 static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_info *rinfo)
 {
 	struct blkfront_info *info = rinfo->dev_info;
@@ -488,9 +505,7 @@ static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_inf
 	unsigned long id;

 	/* Fill out a communications ring structure. */
-	ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
-	id = get_id_from_freelist(rinfo);
-	rinfo->shadow[id].request = req;
+	id = blkif_ring_get_request(rinfo, req, &ring_req);

 	ring_req->operation = BLKIF_OP_DISCARD;
 	ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
@@ -501,8 +516,6 @@ static int blkif_queue_discard_req(struct request *req, struct blkfront_ring_inf
 	else
 		ring_req->u.discard.flag = 0;

-	rinfo->ring.req_prod_pvt++;
-
 	/* Keep a private copy so we can reissue requests when recovering. */
 	rinfo->shadow[id].req = *ring_req;

@@ -635,9 +648,7 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
 		}

 	/* Fill out a communications ring structure. */
-	ring_req = RING_GET_REQUEST(&rinfo->ring, rinfo->ring.req_prod_pvt);
-	id = get_id_from_freelist(rinfo);
-	rinfo->shadow[id].request = req;
+	id = blkif_ring_get_request(rinfo, req, &ring_req);

 	BUG_ON(info->max_indirect_segments == 0 &&
 	   GREFS(req->nr_phys_segments) > BLKIF_MAX_SEGMENTS_PER_REQUEST);
@@ -650,7 +661,6 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
 	for_each_sg(rinfo->shadow[id].sg, sg, num_sg, i)
 	   num_grant += gnttab_count_grant(sg->offset, sg->length);

-	ring_req->u.rw.id = id;
 	rinfo->shadow[id].num_sg = num_sg;
 	if (num_grant > BLKIF_MAX_SEGMENTS_PER_REQUEST) {
 		/*
@@ -716,8 +726,6 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
 	if (setup.segments)
 		kunmap_atomic(setup.segments);

-	rinfo->ring.req_prod_pvt++;
-
 	/* Keep a private copy so we can reissue requests when recovering. */
 	rinfo->shadow[id].req = *ring_req;

--
2.1.4

>From c8623233b85a34cfc603da0cba3111f4365e275f Mon Sep 17 00:00:00 2001
From: Julien Grall 
Date: Thu, 13 Aug 2015 13:13:35 +0100
Subject: [PATCH 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB
 pages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The minimal size of request in the block framework is always PAGE_SIZE.
It means that when 64KB guest is support, the request will at least be
64KB.

Although, if the backend doesn't support indirect descriptor (such as QDISK
in QEMU), a ring request is only able to accommodate 11 segments of 4KB
(i.e 44KB).

The current frontend is assuming that an I/O request will always fit in
a ring request. This is not true any more when using 64KB page
granularity and will therefore crash during boot.

On ARM64, the ABI is completely neutral to the page granularity used by
the domU. The guest has the choice between different page granularit

Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid

[Jan Beulich]

>>> On 08.12.15 at 12:37,  wrote:
> On 08/12/15 08:28, Jan Beulich wrote:
> On 07.12.15 at 17:48,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu 
> *v, uint64_t value,
>>>  {
>>>  unsigned int level;
>>>  
>>> -ASSERT(v == current);
>>> +ASSERT(v->domain == current->domain);
>>>  hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
>>>  if ( level >= 0x8001 )
>>>  {
>>> @@ -1912,7 +1912,7 @@ static unsigned long 
>>> hvm_cr4_guest_reserved_bits(const 
> struct vcpu *v,
>>>  {
>>>  unsigned int level;
>>>  
>>> -ASSERT(v == current);
>>> +ASSERT(v->domain == current->domain);
>>>  hvm_cpuid(0, &level, NULL, NULL, NULL);
>>>  if ( level >= 1 )
>>>  hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
>> The only reason both functions get v passed are the two ASSERT()s.
>> Relaxing them means you should now be passing a const struct
>> domain * instead.
> 
> v is correct here.  cpuid information is genuinely per-vcpu, although
> this isn't currently reflected in Xen's understanding of the matter.

You can't have both: Either the ASSERT() remains as it was, or
you stand on the position voiced along with your R-b that only
the domain matters here (in which case passing around v just to
obtain v->domain is bogus).

Jan


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

Re: [Xen-devel] vcpu state are all paused

[Big Strong]

After update dom0 kernel to 3.19, all vcpus act normal. Thanks very much.

2015-12-07 21:02 GMT+08:00 Jan Beulich :

> >>> On 07.12.15 at 13:56,  wrote:
> > On 07/12/15 12:39, Big Strong wrote:
> >> I set the xen.efi directly boot without grub2 to be able to list all
> >> the cpu cores.
> >> However, after that all the vcpus are in paused state except one for
> dom0.
> >>
> >> ~$ sudo xl vcpu-list
> >> NameID  VCPU   CPU State   Time(s)
> >> Affinity (Hard / Soft)
> >> Domain-0 0 00   r--  64.7
> >>  0 / all
> >> Domain-0 0 1-   *--p *
> >> 0.0  1 / all
> >> Domain-0 0 2-   -*-p*
> >> 0.0  2 / all
> >> Domain-0 0 3-   -*-p *
> >> 0.0  3 / all
> >> ubuntu-hvm   1 05   -b-  16.9
> >>  4-5 / all
> >>
> >>
> >> The full logs during xen booting is at
> http://paste.ubuntu.com/13786410/
> >> It looks like some of the ACPI tables are disabled and there is two
> >> errors:
> >> "ACPI BIOS Error (bug): A valid RSDP was not found
> (20131115/tbxfroot-211)
> >> ioapic: probe of :00:05.4 failed with error -22"
> >> I'm not sure if it's a users' problem or dev problem. If I'm wrong,
> >> please point it out. Any help will be great appreciated.
> >
> > Xen itself gets a proper set of ACPI tables and boots sensibly.
> > However, dom0 fails to retrieve any APCI tables.
>
> Because 3.13 doesn't have Dom0 EFI support yet; this got
> introduced in 3.17.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 65523: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 63340
 build-amd64-xsm   5 xen-build fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  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

version targeted for testing:
 libvirt  5cce775e92784d30692055bbc8b52b2aa0c9d496
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   41 days
Failing since 63352  2015-10-29 04:20:29 Z   40 days   36 attempts
Testing same since65523  2015-12-08 04:22:04 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Chen Hanxiao 
  Christian Loehle 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  Dmitry Andreev 
  Erik Skultety 
  Guido Günther 
  Ian Campbell 
  Jim Fehlig 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Marc-André Lureau 
  Martin Kletzander 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard Weinberger 
  Roman Bogorodskiy 
  Stefan Berger 
  Stefan Berger 
  Wang Yufei 
  Wei Jiangang 

jobs:
 build-amd64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  broken
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  blocked
 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   blocked
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked
 test-amd64-amd64-libvirt-xsm blocked
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  blocked
 test-amd64-amd64-libvirt blocked
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  blocked
 test-amd64-amd64-libvirt-pairblocked
 test-amd64-i386-libvirt-pair blocked
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd blocked



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=

[Xen-devel] [PATCH] x86/HVM: Merge HVM and PVH hypercall tables

[Boris Ostrovsky]

The tables are almost identical and therefore there is little reason to
keep both sets.

PVH needs 3 extra hypercalls:
* mmuext_op. PVH uses MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to
  optimize TLB flushing. Since HVMlite guests may decide to use them as
  well we can allow these two commands for all guests in an HVM container.
* platform_op. These are only available to privileged domains. We will
  (eventually) have privileged HVMlite guests and therefore shouldn't
  limit this to PVH only.
* xenpmu_op. any guest with !has_vlapic() (i.e. PV, PVH and HVMlite)
  should be able to use it.

Signed-off-by: Boris Ostrovsky 
---

This patch is intended to go on top of Roger's HVMlite series

 xen/arch/x86/hvm/hvm.c |   65 ++-
 xen/arch/x86/mm.c  |9 ++
 2 files changed, 23 insertions(+), 51 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 08cef1f..38293d1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5173,12 +5173,21 @@ static hvm_hypercall_t *const 
hvm_hypercall64_table[NR_hypercalls] = {
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
 HYPERCALL(tmem_op),
+HYPERCALL(platform_op),
+HYPERCALL(mmuext_op),
+HYPERCALL(xenpmu_op),
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
 #define COMPAT_CALL(x)\
 [ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) compat_ ## x
 
+extern int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(void) cmp_uops,
+unsigned int count,
+XEN_GUEST_HANDLE_PARAM(uint) pdone,
+unsigned int foreigndom);
+extern int compat_platform_op(XEN_GUEST_HANDLE_PARAM(void) u_xenpf_op);
+
 static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] = {
 [ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op_compat32,
 [ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t 
*)hvm_grant_table_op_compat32,
@@ -5194,48 +5203,8 @@ static hvm_hypercall_t *const 
hvm_hypercall32_table[NR_hypercalls] = {
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
 HYPERCALL(tmem_op),
-[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
-};
-
-static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
-HYPERCALL(platform_op),
-HYPERCALL(memory_op),
-HYPERCALL(xen_version),
-HYPERCALL(console_io),
-[ __HYPERVISOR_grant_table_op ]  = (hvm_hypercall_t *)hvm_grant_table_op,
-HYPERCALL(vcpu_op),
-HYPERCALL(mmuext_op),
-HYPERCALL(xsm_op),
-HYPERCALL(sched_op),
-HYPERCALL(event_channel_op),
-[ __HYPERVISOR_physdev_op ]  = (hvm_hypercall_t *)hvm_physdev_op,
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
-HYPERCALL(xenpmu_op),
-[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
-};
-
-extern int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(void) cmp_uops,
-unsigned int count,
-XEN_GUEST_HANDLE_PARAM(uint) pdone,
-unsigned int foreigndom);
-static hvm_hypercall_t *const pvh_hypercall32_table[NR_hypercalls] = {
-HYPERCALL(platform_op),
-COMPAT_CALL(memory_op),
-HYPERCALL(xen_version),
-HYPERCALL(console_io),
-[ __HYPERVISOR_grant_table_op ]  =
-(hvm_hypercall_t *)hvm_grant_table_op_compat32,
-COMPAT_CALL(vcpu_op),
+COMPAT_CALL(platform_op),
 COMPAT_CALL(mmuext_op),
-HYPERCALL(xsm_op),
-COMPAT_CALL(sched_op),
-HYPERCALL(event_channel_op),
-[ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
 HYPERCALL(xenpmu_op),
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
@@ -5269,9 +5238,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 if ( (eax & 0x8000) && is_viridian_domain(currd) )
 return viridian_hypercall(regs);
 
-if ( (eax >= NR_hypercalls) ||
- !(is_pvh_domain(currd) ? pvh_hypercall32_table[eax]
-: hvm_hypercall32_table[eax]) )
+if ( (eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
 {
 regs->eax = -ENOSYS;
 return HVM_HCALL_completed;
@@ -5305,9 +5272,8 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 #endif
 
 curr->arch.hvm_vcpu.hcall_64bit = 1;
-regs->rax = (is_pvh_domain(currd)
- ? pvh_hypercall64_table
- : hvm_hypercall64_table)[eax](rdi, rsi, rdx, r10, r8, r9);
+regs->rax = hvm_hypercall64_table[eax](rdi, rsi, rdx, r10, r8, r9);
+
 curr->arch.hvm_vcpu.hcall_64bit = 0;
 
 #ifndef NDEBUG
@@ -5351,10 +5317,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 }
 #endif
 
-regs->_eax = (is_pvh_vcpu(curr)
-  ? pvh_hypercall32_table
-  

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/8/15 1:32 AM, Jan Beulich wrote:
 On 07.12.15 at 22:27,  wrote:
>> On 12/3/15 2:57 AM, Jan Beulich wrote:
>> On 03.12.15 at 01:34,  wrote:
 On 12/1/15 5:22 AM, Jan Beulich wrote:
 On 30.11.15 at 18:53,  wrote:
>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>> On 24.11.15 at 18:51,  wrote:
 +config ARCH_DEFCONFIG
 +  string
 +  default "arch/x86/configs/x86_64_defconfig"
>>>
>>> x86_defconfig perhaps?
>>
>> No. I was told to drop support for x86 entirely in an earlier review.
>> Its not possible to configure for 32-bit x86 in v6.
>
> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
> Here I consider x86 as to basic architecture without any
> particular bit width in mind.

 ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
 the original is correct. There is no defconfig for the ambiguous x86
 family. You're either building for x86_64 or x86_32 (which I referred to
 as x86 in my original response).

 This defconfig is for the 64-bit architecture of x86 (x86_64) and there
 for its named correctly.
>>>
>>> But there is no x86_32 architecture form the hypervisor build's
>>> point of view, and hence x86 isn't ambiguous. In fact the mid-term
>>> plan is to remove leftovers of references to x86_64 (like the
>>> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
>>> possible. The only place they need to be kept are in the public
>>> interface.
>>
>> That's fine but you don't build things for "x86". You build them for
>> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
> 
> The XEN_TARGET_ARCH value is of no interest here. The only fact
> that I care about is that there's only one x86 configuration, and
> hence I can't see why it shouldn't be named x86_defconfig.
> 
> Jan
> 

This is just how the upstream stuff works. Are we forking upstream's
kconfig just so we can call it "x86" instead of "x86_64"?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH] Executive: Permit OSSTEST_TASK= (for static tasks)

[Ian Jackson]

If OSSTEST_TASK is not set, we construct a  from the username
and the nodename, and look for a such a static task.  If OSSTEST_TASK
/is/ set would require it to contain `  '.

In this patch, permit OSSTEST_TASK to be set simply to the .
This is much more convenient and doesn't involve manually looking up
taskids.  The risk of error seems negligible.

Signed-off-by: Ian Jackson 
---
 Osstest/Executive.pm |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index fcef83f..84c7d46 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -446,13 +446,15 @@ sub findtask () {
 if (!defined $spec) {
 $!=0; $?=0; my $node=   `uname -n`; defined $node   or die "$? $!";
 chomp($node); $node =~ s/\..*//;
-my $refkey= "$c{Username}\@$node";
-$what= "static $refkey";
+   $spec= "$c{Username}\@$node";
+}
+if ($spec !~ m/\s/) {
+$what= "static $spec";
 $q= $dbh_tests->prepare(execute($spec);
 } else {
 my @l = split /\s+/, $spec;
 @l==3 or die "$spec ".scalar(@l)." ?";
-- 
1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 13/16] mg-schema-test-database: Change username for back-to-main-db xref

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 13/16] mg-schema-test-database: Change 
username for back-to-main-db xref"):
> On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> > Currently this is purely cosmetic, but it is going to be useful to
> > distinguish the two cases:
> >  * This is a test DB and contains references to a parent
> >  * This is a parent DB (probably the main DB) which contains
> >    references to child test DBS.
> 
> Did you mean "DBS" or just "DB"?

I meant `DB(s)' (possibly several).  Fixed.

> Acked-by: Ian Campbell 

Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 15/16] mg-schema-test-database: Safety catch in JobDB database open

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 15/16] mg-schema-test-database: Safety 
catch in JobDB database open"):
> On Mon, 2015-12-07 at 17:27 +, Ian Jackson wrote:
> > +# mg-schema-test-database creates a task
> > +#   xdbref/DBNAME with username ${Username}@
> 
> Was there intended to be a wildcard or pattern of some sort after the @ in
> this comment?

Yes.  I have changed this to read:

#   xdbref/DBNAME with username ${Username}@NODENAME

> Other than the comment thing above:
> Acked-by: Ian Campbell 

Thanks,
Ian.

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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 08.12.15 at 15:16,  wrote:
> On 12/8/15 1:32 AM, Jan Beulich wrote:
> On 07.12.15 at 22:27,  wrote:
>>> On 12/3/15 2:57 AM, Jan Beulich wrote:
>>> On 03.12.15 at 01:34,  wrote:
> On 12/1/15 5:22 AM, Jan Beulich wrote:
> On 30.11.15 at 18:53,  wrote:
>>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>>> On 24.11.15 at 18:51,  wrote:
> +config ARCH_DEFCONFIG
> + string
> + default "arch/x86/configs/x86_64_defconfig"

 x86_defconfig perhaps?
>>>
>>> No. I was told to drop support for x86 entirely in an earlier review.
>>> Its not possible to configure for 32-bit x86 in v6.
>>
>> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
>> Here I consider x86 as to basic architecture without any
>> particular bit width in mind.
>
> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
> the original is correct. There is no defconfig for the ambiguous x86
> family. You're either building for x86_64 or x86_32 (which I referred to
> as x86 in my original response).
>
> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
> for its named correctly.

 But there is no x86_32 architecture form the hypervisor build's
 point of view, and hence x86 isn't ambiguous. In fact the mid-term
 plan is to remove leftovers of references to x86_64 (like the
 arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
 possible. The only place they need to be kept are in the public
 interface.
>>>
>>> That's fine but you don't build things for "x86". You build them for
>>> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
>> 
>> The XEN_TARGET_ARCH value is of no interest here. The only fact
>> that I care about is that there's only one x86 configuration, and
>> hence I can't see why it shouldn't be named x86_defconfig.
> 
> This is just how the upstream stuff works. Are we forking upstream's
> kconfig just so we can call it "x86" instead of "x86_64"?

I don't think using

config ARCH_DEFCONFIG
string
default "arch/x86/configs/x86_defconfig"

instead of

config ARCH_DEFCONFIG
string
default "arch/x86/configs/x86_64_defconfig"

in a Kconfig file of ours is a fork. Or am I overlooking some other
aspect?

Jan


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

Re: [Xen-devel] [PATCH OSSTEST v2] standalone: Log things we are running via with_logging

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v2] standalone: Log things we are running 
via with_logging"):
> Turning on set -x generally in this script is too verbose, so run the
> command in a subshell which sets -x.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Ian Jackson 

(I will pick this up into my queue)

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

Re: [Xen-devel] [OSSTEST PATCH] Executive: Permit OSSTEST_TASK= (for static tasks)

[Ian Campbell]

On Tue, 2015-12-08 at 14:19 +, Ian Jackson wrote:
> If OSSTEST_TASK is not set, we construct a  from the username
> and the nodename, and look for a such a static task.  If OSSTEST_TASK
> /is/ set would require it to contain `  '.
> 
> In this patch, permit OSSTEST_TASK to be set simply to the .
> This is much more convenient and doesn't involve manually looking up
> taskids.  The risk of error seems negligible.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

[Xen-devel] Success with pv guest and ATI Radeon HD4550

[Geoffrey McRae]

Hi All,

This is just a heads up on the steps involved in getting a HD4550 
working with the ATI driver as a pv guest on a Dom0 with no IOMMU 
support. The main issue with making this work was providing a way for 
the guest to read the vga bios.


[2.127078] [drm] Initialized drm 1.1.0 20060810
[2.140666] snd_hda_intel :00:00.1: Xen PCI mapped GSI19 to IRQ51
[2.140950] snd_hda_intel :00:00.1: Handle VGA-switcheroo audio 
client

[2.143196] [drm] radeon kernel modesetting enabled.
[2.143856] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
[2.144583] [drm] initializing kernel modesetting (RV710 
0x1002:0x9540 0x1043:0x0298).

[2.144608] [drm] register mmio base: 0xFBDF
[2.144612] [drm] register mmio size: 65536
[2.144693] radeon :00:00.0: Invalid ROM contents
[2.144703] radeon :00:00.0: Invalid ROM contents
[2.144707] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[2.144712] radeon :00:00.0: Fatal error during GPU init
[2.144717] [drm] radeon: finishing device.
[2.144720] [TTM] Memory type 2 has not been initialized

To resolve this I dumped the BIOS on dom0 to a file and copied it into 
the guest, then patched radeon_bios.c to provide a means to load it from 
userspace with the following result.



[  997.220370] [drm] radeon kernel modesetting enabled.
[  997.220743] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 53 
for gsi 18

[  997.220753] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
[  997.221304] [drm] initializing kernel modesetting (RV710 
0x1002:0x9540 0x1043:0x0298).

[  997.221329] [drm] register mmio base: 0xFBDF
[  997.221333] [drm] register mmio size: 65536
[  997.222605] radeon :00:00.0: firmware: direct-loading firmware 
radeon.bios

[  997.222652] ATOM BIOS: 9540.11.17.0.18.AS02
[  997.222691] radeon :00:00.0: VRAM: 512M 0x - 
0x1FFF (512M used)
[  997.222702] radeon :00:00.0: GTT: 1024M 0x2000 - 
0x5FFF
[  997.222708] Failed to add WC MTRR for 
[d000-dfff]; performance may suffer.

[  997.222713] [drm] Detected VRAM RAM=512M, BAR=256M
[  997.222717] [drm] RAM width 64bits DDR
[  997.222815] [TTM] Zone  kernel: Available graphics memory: 509996 kiB
[  997.222821] [TTM] Initializing pool allocator
[  997.222829] [TTM] Initializing DMA pool allocator
[  997.222862] [drm] radeon: 512M of VRAM memory ready
[  997.222866] [drm] radeon: 1024M of GTT memory ready.
[  997.222884] [drm] Loading RV710 Microcode
[  997.231622] radeon :00:00.0: firmware: direct-loading firmware 
radeon/RV710_pfp.bin
[  997.249253] radeon :00:00.0: firmware: direct-loading firmware 
radeon/RV710_me.bin
[  997.272966] radeon :00:00.0: firmware: direct-loading firmware 
radeon/R700_rlc.bin
[  997.290901] radeon :00:00.0: firmware: direct-loading firmware 
radeon/RV710_smc.bin

[  997.290915] [drm] Internal thermal controller without fan control
[  997.291866] [drm] radeon: dpm initialized
[  997.306236] radeon :00:00.0: firmware: direct-loading firmware 
radeon/RV710_uvd.bin

[  997.306409] [drm] GART: num cpu pages 262144, num gpu pages 262144
[  997.320178] [drm] PCIE GART of 1024M enabled (table at 
0x0025D000).

[  997.320240] radeon :00:00.0: WB enabled
[  997.320246] radeon :00:00.0: fence driver on ring 0 use gpu addr 
0x2c00 and cpu addr 0x88003c79cc00
[  997.320253] radeon :00:00.0: fence driver on ring 3 use gpu addr 
0x2c0c and cpu addr 0x88003c79cc0c
[  997.323053] radeon :00:00.0: fence driver on ring 5 use gpu addr 
0x0005c598 and cpu addr 0xc931c598

[  997.323060] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  997.323063] [drm] Driver supports precise vblank timestamp query.
[  997.323067] radeon :00:00.0: radeon: MSI limited to 32-bit
[  997.323285] radeon :00:00.0: radeon: using MSI.
[  997.323322] [drm] radeon: irq initialized.
[  997.369642] [drm] ring test on 0 succeeded in 1 usecs
[  997.369651] [drm] ring test on 3 succeeded in 2 usecs
[  997.564145] [drm] ring test on 5 succeeded in 1 usecs
[  997.564153] [drm] UVD initialized successfully.
[  997.564580] [drm] ib test on ring 0 succeeded in 0 usecs
[  997.564614] [drm] ib test on ring 3 succeeded in 0 usecs
[  997.723870] [drm] ib test on ring 5 succeeded
[  997.724326] [drm] Radeon Display Connectors
[  997.724332] [drm] Connector 0:
[  997.724335] [drm]   VGA-1
[  997.724338] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 
0x7e4c 0x7e4c

[  997.724342] [drm]   Encoders:
[  997.724345] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[  997.724348] [drm] Connector 1:
[  997.724350] [drm]   HDMI-A-1
[  997.724353] [drm]   HPD1
[  997.724355] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 
0x7e5c 0x7e5c

[  997.724359] [drm]   Encoders:
[  997.724362] [drm] DFP1: INTERNAL_UNIPHY
[  997.724365] [drm] Connector 2:
[  997.724367] [drm

Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid

[Andrew Cooper]

On 08/12/15 12:54, Jan Beulich wrote:
 On 08.12.15 at 12:37,  wrote:
>> On 08/12/15 08:28, Jan Beulich wrote:
>> On 07.12.15 at 17:48,  wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu 
>> *v, uint64_t value,
  {
  unsigned int level;
  
 -ASSERT(v == current);
 +ASSERT(v->domain == current->domain);
  hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
  if ( level >= 0x8001 )
  {
 @@ -1912,7 +1912,7 @@ static unsigned long 
 hvm_cr4_guest_reserved_bits(const 
>> struct vcpu *v,
  {
  unsigned int level;
  
 -ASSERT(v == current);
 +ASSERT(v->domain == current->domain);
  hvm_cpuid(0, &level, NULL, NULL, NULL);
  if ( level >= 1 )
  hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
>>> The only reason both functions get v passed are the two ASSERT()s.
>>> Relaxing them means you should now be passing a const struct
>>> domain * instead.
>> v is correct here.  cpuid information is genuinely per-vcpu, although
>> this isn't currently reflected in Xen's understanding of the matter.
> You can't have both: Either the ASSERT() remains as it was, or
> you stand on the position voiced along with your R-b that only
> the domain matters here (in which case passing around v just to
> obtain v->domain is bogus).

hvm_cpuid() uses current.

This behavior is problematic and I will be removing its dependence on
current with future work (passing v instead and tweaking some of the
lower level bits), but at the moment it is hard requirement.

As a result, the ASSERT(v == current) was correct.

Roger is introducing a new codepath where v != current, but v->domain ==
current->domain.  The specific cpuid leafs requested from hvm_cpuid() do
indeed only use current->domain, which is the basis of my R-b

It is very definitely wrong to remove the current check; the ASSERT()
needs to stay.  However, the relaxation of the constraint is acceptable
until the cpuid infrastructure gets fixed up, at which point the
ASSERT() can disappear.

As v is the eventual correct parameter to be passed here, I do not want
to see it changed to a domain, just for me to revert that change shortly.

Therefore, the original patch is correct and I stand by my R-b.

~Andrew

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

[Xen-devel] xenstore domain

[Juergen Gross]

I'm just playing a little bit with xenstore in an own domain.

I've come across some questions I'd like to have some answers to before
presenting official patches to make this an easy configurable option:

a) As this would need a boot time configuration item I'd like to add
   e.g. /etc/xen/server.conf where such global configuration options
   could be set via directives. Is this generally okay? If yes, which
   format? Easiest way would be entries like
   VAR=value
   which can be either sourced in from shell scripts or can easily be
   parsed in all programming languages. What are the preferences here?

b) Today init-xenstore-domain will require flask to be enabled. An
   alternative would be to add a new domain creation flag to allow the
   domains with that flag set calling xc_domain_getinfo(). Thoughts?

c) In order to be as flexible as possible I think the xenstore domain
   should be allowed to auto-balloon according to it's needs. Is anyone
   already working on ballooning support for mini-os?


Juergen

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

Re: [Xen-devel] Success with pv guest and ATI Radeon HD4550

[Andrew Cooper]

On 08/12/15 14:37, Geoffrey McRae wrote:
> Hi All,
>
> This is just a heads up on the steps involved in getting a HD4550
> working with the ATI driver as a pv guest on a Dom0 with no IOMMU
> support. The main issue with making this work was providing a way for
> the guest to read the vga bios.
>
> [2.127078] [drm] Initialized drm 1.1.0 20060810
> [2.140666] snd_hda_intel :00:00.1: Xen PCI mapped GSI19 to IRQ51
> [2.140950] snd_hda_intel :00:00.1: Handle VGA-switcheroo audio
> client
> [2.143196] [drm] radeon kernel modesetting enabled.
> [2.143856] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
> [2.144583] [drm] initializing kernel modesetting (RV710
> 0x1002:0x9540 0x1043:0x0298).
> [2.144608] [drm] register mmio base: 0xFBDF
> [2.144612] [drm] register mmio size: 65536
> [2.144693] radeon :00:00.0: Invalid ROM contents
> [2.144703] radeon :00:00.0: Invalid ROM contents
> [2.144707] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
> [2.144712] radeon :00:00.0: Fatal error during GPU init
> [2.144717] [drm] radeon: finishing device.
> [2.144720] [TTM] Memory type 2 has not been initialized
>
> To resolve this I dumped the BIOS on dom0 to a file and copied it into
> the guest, then patched radeon_bios.c to provide a means to load it
> from userspace with the following result.
>
>
> [  997.220370] [drm] radeon kernel modesetting enabled.
> [  997.220743] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 53
> for gsi 18
> [  997.220753] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
> [  997.221304] [drm] initializing kernel modesetting (RV710
> 0x1002:0x9540 0x1043:0x0298).
> [  997.221329] [drm] register mmio base: 0xFBDF
> [  997.221333] [drm] register mmio size: 65536
> [  997.222605] radeon :00:00.0: firmware: direct-loading firmware
> radeon.bios
> [  997.222652] ATOM BIOS: 9540.11.17.0.18.AS02
> [  997.222691] radeon :00:00.0: VRAM: 512M 0x -
> 0x1FFF (512M used)
> [  997.222702] radeon :00:00.0: GTT: 1024M 0x2000 -
> 0x5FFF
> [  997.222708] Failed to add WC MTRR for
> [d000-dfff]; performance may suffer.
> [  997.222713] [drm] Detected VRAM RAM=512M, BAR=256M
> [  997.222717] [drm] RAM width 64bits DDR
> [  997.222815] [TTM] Zone  kernel: Available graphics memory: 509996 kiB
> [  997.222821] [TTM] Initializing pool allocator
> [  997.222829] [TTM] Initializing DMA pool allocator
> [  997.222862] [drm] radeon: 512M of VRAM memory ready
> [  997.222866] [drm] radeon: 1024M of GTT memory ready.
> [  997.222884] [drm] Loading RV710 Microcode
> [  997.231622] radeon :00:00.0: firmware: direct-loading firmware
> radeon/RV710_pfp.bin
> [  997.249253] radeon :00:00.0: firmware: direct-loading firmware
> radeon/RV710_me.bin
> [  997.272966] radeon :00:00.0: firmware: direct-loading firmware
> radeon/R700_rlc.bin
> [  997.290901] radeon :00:00.0: firmware: direct-loading firmware
> radeon/RV710_smc.bin
> [  997.290915] [drm] Internal thermal controller without fan control
> [  997.291866] [drm] radeon: dpm initialized
> [  997.306236] radeon :00:00.0: firmware: direct-loading firmware
> radeon/RV710_uvd.bin
> [  997.306409] [drm] GART: num cpu pages 262144, num gpu pages 262144
> [  997.320178] [drm] PCIE GART of 1024M enabled (table at
> 0x0025D000).
> [  997.320240] radeon :00:00.0: WB enabled
> [  997.320246] radeon :00:00.0: fence driver on ring 0 use gpu
> addr 0x2c00 and cpu addr 0x88003c79cc00
> [  997.320253] radeon :00:00.0: fence driver on ring 3 use gpu
> addr 0x2c0c and cpu addr 0x88003c79cc0c
> [  997.323053] radeon :00:00.0: fence driver on ring 5 use gpu
> addr 0x0005c598 and cpu addr 0xc931c598
> [  997.323060] [drm] Supports vblank timestamp caching Rev 2
> (21.10.2013).
> [  997.323063] [drm] Driver supports precise vblank timestamp query.
> [  997.323067] radeon :00:00.0: radeon: MSI limited to 32-bit
> [  997.323285] radeon :00:00.0: radeon: using MSI.
> [  997.323322] [drm] radeon: irq initialized.
> [  997.369642] [drm] ring test on 0 succeeded in 1 usecs
> [  997.369651] [drm] ring test on 3 succeeded in 2 usecs
> [  997.564145] [drm] ring test on 5 succeeded in 1 usecs
> [  997.564153] [drm] UVD initialized successfully.
> [  997.564580] [drm] ib test on ring 0 succeeded in 0 usecs
> [  997.564614] [drm] ib test on ring 3 succeeded in 0 usecs
> [  997.723870] [drm] ib test on ring 5 succeeded
> [  997.724326] [drm] Radeon Display Connectors
> [  997.724332] [drm] Connector 0:
> [  997.724335] [drm]   VGA-1
> [  997.724338] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
> 0x7e4c 0x7e4c
> [  997.724342] [drm]   Encoders:
> [  997.724345] [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [  997.724348] [drm] Connector 1:
> [  997.724350] [drm]   HDMI-A-1
> [  997.724353] [drm]   HPD1
> [  997.724355] [drm]

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

[Anthony PERARD]

On Tue, Dec 08, 2015 at 10:23:49AM +, Ian Campbell wrote:
> On Fri, 2015-11-20 at 14:55 +, Anthony PERARD wrote:
> 
> I think this will also add a devstack job to most other flights? That's a
> good thing, I think.

That was not my intention. It's true that the more test, the better, but on
the other hands it takes about 1h to deploy+test openstack, after
installing the host.

> I wonder if the flight ought to be called openstack-nova, to leave open the
> possibility of other openstack-$foo flights in the future?

Yeah, that probably good to do.

> > Signed-off-by: Anthony PERARD 
> > 
> > ---
> > Change in V4:
> > - also skip build-*-oldkern in make flight
> 
> Those should already be caught by cr-daily-branch
> setting REVISION_LINUX_OLD=disable for all but the xen-unstable flight
> (arguably that default ought to be inverted, such that make-flight by
> default doesn't make such flights unless asked to, but that's not your Yakk
> I think)
> 
> > - fix select_xenbranch
> > - set revision_*=$REVISION_OPENSTACK_* in make-flight
> >   (was revision_*=master before)
> >   only REVISION_OPENSTACK_NOVA is set, the others are unset.
> >   empty revision_* runvar would clone the default branch, which should
> >   be master for every openstack repos
> 
> The sort of info in this last bullet would be useful in the commit message,
> I think.

Yes, I should add that to the commit, to at least let know the intention of
the author.

> > diff --git a/make-flight b/make-flight
> > index 8523995..5a4fc0c 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -54,6 +54,12 @@ job_create_build_filter_callback () {
> >  *) return 1 ;;
> >    esac
> >  ;;
> > +openstack)
> > +  case "$job" in
> > +*-xsm) return 1;;
> 
> I wonder, would a test-$xenarch$kern-$dom0arch-devstack-xsm be a useful
> think to have though?

Probably, that would test xsm with a different scenario.

> > +*-oldkern) return 1;;
> 
> See above.

Ok, I guest I can remove this.

> > diff --git a/mfi-common b/mfi-common
> > index 5fbe195..f11302b 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -59,6 +59,7 @@ xenbranch_xsm_variants () {
> >  xen-4.3-testing) echo "false";;
> >  xen-4.4-testing) echo "false";;
> >  xen-4.5-testing) echo "false";;
> > +openstack)   echo "false";;
> >  *) echo "false true";
> >  esac
> >  }
> > @@ -102,6 +103,7 @@ create_build_jobs () {
> >    rumpuserxen) continue;;
> >    seabios) continue;;
> >    ovmf) continue;;
> > +  openstack) continue;;
> >    esac
> >    case "$xenbranch" in
> >    xen-3.*-testing) continue;;
> > @@ -127,6 +129,9 @@ create_build_jobs () {
> >    "
> >    ;;
> >  esac
> > +if [ "$arch" = i386 ] && [ "$branch" = openstack ]; then
> > +  continue
> 
> This accepts ARM, but I think you filter the test cases for that? The
> filtering of build vs. test jobs in make-flight/mfi-common is a bit of a
> mess, recently e21625f79d33 "make-flight: move in-lined branch vs arch
> filtering into callbacks" make it a bit less bad, which might be useful to
> you here?

Yes, ARM should be filter elsewere. I'll give a look at this commit.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] Success with pv guest and ATI Radeon HD4550

[Geoffrey McRae]

On 09/12/15 01:51, Andrew Cooper wrote:

On 08/12/15 14:37, Geoffrey McRae wrote:

Hi All,

This is just a heads up on the steps involved in getting a HD4550
working with the ATI driver as a pv guest on a Dom0 with no IOMMU
support. The main issue with making this work was providing a way for
the guest to read the vga bios.

[2.127078] [drm] Initialized drm 1.1.0 20060810
[2.140666] snd_hda_intel :00:00.1: Xen PCI mapped GSI19 to IRQ51
[2.140950] snd_hda_intel :00:00.1: Handle VGA-switcheroo audio
client
[2.143196] [drm] radeon kernel modesetting enabled.
[2.143856] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
[2.144583] [drm] initializing kernel modesetting (RV710
0x1002:0x9540 0x1043:0x0298).
[2.144608] [drm] register mmio base: 0xFBDF
[2.144612] [drm] register mmio size: 65536
[2.144693] radeon :00:00.0: Invalid ROM contents
[2.144703] radeon :00:00.0: Invalid ROM contents
[2.144707] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[2.144712] radeon :00:00.0: Fatal error during GPU init
[2.144717] [drm] radeon: finishing device.
[2.144720] [TTM] Memory type 2 has not been initialized

To resolve this I dumped the BIOS on dom0 to a file and copied it into
the guest, then patched radeon_bios.c to provide a means to load it
from userspace with the following result.


[  997.220370] [drm] radeon kernel modesetting enabled.
[  997.220743] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 53
for gsi 18
[  997.220753] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
[  997.221304] [drm] initializing kernel modesetting (RV710
0x1002:0x9540 0x1043:0x0298).
[  997.221329] [drm] register mmio base: 0xFBDF
[  997.221333] [drm] register mmio size: 65536
[  997.222605] radeon :00:00.0: firmware: direct-loading firmware
radeon.bios
[  997.222652] ATOM BIOS: 9540.11.17.0.18.AS02
[  997.222691] radeon :00:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[  997.222702] radeon :00:00.0: GTT: 1024M 0x2000 -
0x5FFF
[  997.222708] Failed to add WC MTRR for
[d000-dfff]; performance may suffer.
[  997.222713] [drm] Detected VRAM RAM=512M, BAR=256M
[  997.222717] [drm] RAM width 64bits DDR
[  997.222815] [TTM] Zone  kernel: Available graphics memory: 509996 kiB
[  997.222821] [TTM] Initializing pool allocator
[  997.222829] [TTM] Initializing DMA pool allocator
[  997.222862] [drm] radeon: 512M of VRAM memory ready
[  997.222866] [drm] radeon: 1024M of GTT memory ready.
[  997.222884] [drm] Loading RV710 Microcode
[  997.231622] radeon :00:00.0: firmware: direct-loading firmware
radeon/RV710_pfp.bin
[  997.249253] radeon :00:00.0: firmware: direct-loading firmware
radeon/RV710_me.bin
[  997.272966] radeon :00:00.0: firmware: direct-loading firmware
radeon/R700_rlc.bin
[  997.290901] radeon :00:00.0: firmware: direct-loading firmware
radeon/RV710_smc.bin
[  997.290915] [drm] Internal thermal controller without fan control
[  997.291866] [drm] radeon: dpm initialized
[  997.306236] radeon :00:00.0: firmware: direct-loading firmware
radeon/RV710_uvd.bin
[  997.306409] [drm] GART: num cpu pages 262144, num gpu pages 262144
[  997.320178] [drm] PCIE GART of 1024M enabled (table at
0x0025D000).
[  997.320240] radeon :00:00.0: WB enabled
[  997.320246] radeon :00:00.0: fence driver on ring 0 use gpu
addr 0x2c00 and cpu addr 0x88003c79cc00
[  997.320253] radeon :00:00.0: fence driver on ring 3 use gpu
addr 0x2c0c and cpu addr 0x88003c79cc0c
[  997.323053] radeon :00:00.0: fence driver on ring 5 use gpu
addr 0x0005c598 and cpu addr 0xc931c598
[  997.323060] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[  997.323063] [drm] Driver supports precise vblank timestamp query.
[  997.323067] radeon :00:00.0: radeon: MSI limited to 32-bit
[  997.323285] radeon :00:00.0: radeon: using MSI.
[  997.323322] [drm] radeon: irq initialized.
[  997.369642] [drm] ring test on 0 succeeded in 1 usecs
[  997.369651] [drm] ring test on 3 succeeded in 2 usecs
[  997.564145] [drm] ring test on 5 succeeded in 1 usecs
[  997.564153] [drm] UVD initialized successfully.
[  997.564580] [drm] ib test on ring 0 succeeded in 0 usecs
[  997.564614] [drm] ib test on ring 3 succeeded in 0 usecs
[  997.723870] [drm] ib test on ring 5 succeeded
[  997.724326] [drm] Radeon Display Connectors
[  997.724332] [drm] Connector 0:
[  997.724335] [drm]   VGA-1
[  997.724338] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
0x7e4c 0x7e4c
[  997.724342] [drm]   Encoders:
[  997.724345] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[  997.724348] [drm] Connector 1:
[  997.724350] [drm]   HDMI-A-1
[  997.724353] [drm]   HPD1
[  997.724355] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58
0x7e5c 0x7e5c
[  997.724359] [drm]   Encoders:
[  997.724362] [drm] DFP1: INTERNAL_UNIPHY
[  997.

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

[Ian Campbell]

On Tue, 2015-12-08 at 14:54 +, Anthony PERARD wrote:
> On Tue, Dec 08, 2015 at 10:23:49AM +, Ian Campbell wrote:
> > On Fri, 2015-11-20 at 14:55 +, Anthony PERARD wrote:
> > 
> > I think this will also add a devstack job to most other flights? That's
> > a
> > good thing, I think.
> 
> That was not my intention. It's true that the more test, the better, but on
> the other hands it takes about 1h to deploy+test openstack, after
> installing the host.

1h isn't outsides the realms of reasonableness, but I'll let Ian comment on
available colo test bandwidth.

> diff --git a/make-flight b/make-flight
> > > index 8523995..5a4fc0c 100755
> > > --- a/make-flight
> > > +++ b/make-flight
> > > @@ -54,6 +54,12 @@ job_create_build_filter_callback () {
> > >  *)   return 1 ;;
> > >    esac
> > >  ;;
> > > +openstack)
> > > +  case "$job" in
> > > +*-xsm) return 1;;
> > 
> > I wonder, would a test-$xenarch$kern-$dom0arch-devstack-xsm be a useful
> > think to have though?
> 
> Probably, that would test xsm with a different scenario.

Indeed.

In fact I wonder if we should have a general policy of defaulting to
testing with XSM turned on. After all I would expect that to find strictly
more bugs than running without.

[...]
> Yes, ARM should be filter elsewere. I'll give a look at this commit.

For both this and the question of whether the devstack is being added to
the other flights or not I would recommend running
"standalone-generate-dump-flight-runvars > before" and "s-g-d-f-r > after"
with and without your change and examining the diff.

I usually run it with eatmydata for minimum runtimes, although that has a
small chance in theory of corrupting standalone.db.

Ian.

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

Re: [Xen-devel] xenstore domain

[Andrew Cooper]

On 08/12/15 14:44, Juergen Gross wrote:
> I'm just playing a little bit with xenstore in an own domain.
>
> I've come across some questions I'd like to have some answers to before
> presenting official patches to make this an easy configurable option:
>
> a) As this would need a boot time configuration item I'd like to add
>e.g. /etc/xen/server.conf where such global configuration options
>could be set via directives. Is this generally okay? If yes, which
>format? Easiest way would be entries like
>VAR=value
>which can be either sourced in from shell scripts or can easily be
>parsed in all programming languages. What are the preferences here?

Any configuration like this going to be toolstack-specific.  I would
recommend against using a name as generic as that.

/etc/xl.conf already exists, which IMO would be the natural place for
this to live, but it isn't parseable by shell, because of vif notation.

One option might be to alter xl.conf to be compatible with shell
parsing.  It wouldn't be complicated (even in upgrade situations), and
would offer rather more flexibility.

>
> b) Today init-xenstore-domain will require flask to be enabled. An
>alternative would be to add a new domain creation flag to allow the
>domains with that flag set calling xc_domain_getinfo(). Thoughts?

Which flag?

>
> c) In order to be as flexible as possible I think the xenstore domain
>should be allowed to auto-balloon according to it's needs. Is anyone
>already working on ballooning support for mini-os?

This is the C xenstore?  Have you investigated whether Mirage-based
stubdomains can balloon?

~Andrew

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

Re: [Xen-devel] Success with pv guest and ATI Radeon HD4550

[Andrew Cooper]

On 08/12/15 14:55, Geoffrey McRae wrote:
>
> On 09/12/15 01:51, Andrew Cooper wrote:
>> On 08/12/15 14:37, Geoffrey McRae wrote:
>>> Hi All,
>>>
>>> This is just a heads up on the steps involved in getting a HD4550
>>> working with the ATI driver as a pv guest on a Dom0 with no IOMMU
>>> support. The main issue with making this work was providing a way for
>>> the guest to read the vga bios.
>>>
>>> [2.127078] [drm] Initialized drm 1.1.0 20060810
>>> [2.140666] snd_hda_intel :00:00.1: Xen PCI mapped GSI19 to
>>> IRQ51
>>> [2.140950] snd_hda_intel :00:00.1: Handle VGA-switcheroo audio
>>> client
>>> [2.143196] [drm] radeon kernel modesetting enabled.
>>> [2.143856] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
>>> [2.144583] [drm] initializing kernel modesetting (RV710
>>> 0x1002:0x9540 0x1043:0x0298).
>>> [2.144608] [drm] register mmio base: 0xFBDF
>>> [2.144612] [drm] register mmio size: 65536
>>> [2.144693] radeon :00:00.0: Invalid ROM contents
>>> [2.144703] radeon :00:00.0: Invalid ROM contents
>>> [2.144707] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS
>>> ROM
>>> [2.144712] radeon :00:00.0: Fatal error during GPU init
>>> [2.144717] [drm] radeon: finishing device.
>>> [2.144720] [TTM] Memory type 2 has not been initialized
>>>
>>> To resolve this I dumped the BIOS on dom0 to a file and copied it into
>>> the guest, then patched radeon_bios.c to provide a means to load it
>>> from userspace with the following result.
>>>
>>>
>>> [  997.220370] [drm] radeon kernel modesetting enabled.
>>> [  997.220743] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 53
>>> for gsi 18
>>> [  997.220753] radeon :00:00.0: Xen PCI mapped GSI18 to IRQ53
>>> [  997.221304] [drm] initializing kernel modesetting (RV710
>>> 0x1002:0x9540 0x1043:0x0298).
>>> [  997.221329] [drm] register mmio base: 0xFBDF
>>> [  997.221333] [drm] register mmio size: 65536
>>> [  997.222605] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon.bios
>>> [  997.222652] ATOM BIOS: 9540.11.17.0.18.AS02
>>> [  997.222691] radeon :00:00.0: VRAM: 512M 0x -
>>> 0x1FFF (512M used)
>>> [  997.222702] radeon :00:00.0: GTT: 1024M 0x2000 -
>>> 0x5FFF
>>> [  997.222708] Failed to add WC MTRR for
>>> [d000-dfff]; performance may suffer.
>>> [  997.222713] [drm] Detected VRAM RAM=512M, BAR=256M
>>> [  997.222717] [drm] RAM width 64bits DDR
>>> [  997.222815] [TTM] Zone  kernel: Available graphics memory: 509996
>>> kiB
>>> [  997.222821] [TTM] Initializing pool allocator
>>> [  997.222829] [TTM] Initializing DMA pool allocator
>>> [  997.222862] [drm] radeon: 512M of VRAM memory ready
>>> [  997.222866] [drm] radeon: 1024M of GTT memory ready.
>>> [  997.222884] [drm] Loading RV710 Microcode
>>> [  997.231622] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon/RV710_pfp.bin
>>> [  997.249253] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon/RV710_me.bin
>>> [  997.272966] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon/R700_rlc.bin
>>> [  997.290901] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon/RV710_smc.bin
>>> [  997.290915] [drm] Internal thermal controller without fan control
>>> [  997.291866] [drm] radeon: dpm initialized
>>> [  997.306236] radeon :00:00.0: firmware: direct-loading firmware
>>> radeon/RV710_uvd.bin
>>> [  997.306409] [drm] GART: num cpu pages 262144, num gpu pages 262144
>>> [  997.320178] [drm] PCIE GART of 1024M enabled (table at
>>> 0x0025D000).
>>> [  997.320240] radeon :00:00.0: WB enabled
>>> [  997.320246] radeon :00:00.0: fence driver on ring 0 use gpu
>>> addr 0x2c00 and cpu addr 0x88003c79cc00
>>> [  997.320253] radeon :00:00.0: fence driver on ring 3 use gpu
>>> addr 0x2c0c and cpu addr 0x88003c79cc0c
>>> [  997.323053] radeon :00:00.0: fence driver on ring 5 use gpu
>>> addr 0x0005c598 and cpu addr 0xc931c598
>>> [  997.323060] [drm] Supports vblank timestamp caching Rev 2
>>> (21.10.2013).
>>> [  997.323063] [drm] Driver supports precise vblank timestamp query.
>>> [  997.323067] radeon :00:00.0: radeon: MSI limited to 32-bit
>>> [  997.323285] radeon :00:00.0: radeon: using MSI.
>>> [  997.323322] [drm] radeon: irq initialized.
>>> [  997.369642] [drm] ring test on 0 succeeded in 1 usecs
>>> [  997.369651] [drm] ring test on 3 succeeded in 2 usecs
>>> [  997.564145] [drm] ring test on 5 succeeded in 1 usecs
>>> [  997.564153] [drm] UVD initialized successfully.
>>> [  997.564580] [drm] ib test on ring 0 succeeded in 0 usecs
>>> [  997.564614] [drm] ib test on ring 3 succeeded in 0 usecs
>>> [  997.723870] [drm] ib test on ring 5 succeeded
>>> [  997.724326] [drm] Radeon Display Connectors
>>> [  997.724332] [drm] Connector 0:
>>> [  997.724335] [drm]   VGA-1
>>> [  997.7243

Re: [Xen-devel] [PATCH] Fix regression in xendomains initscript: test for privcmd char device

[Ian Jackson]

Sander Eikelenboom writes ("[PATCH] Fix regression in xendomains initscript: 
test for privcmd char device"):
> Since commit:
> "xendomains initscript: test for privcmd char device"
> (1367e9e5ba4d1612e303123ec0bbf961100fcfa1)
> due to incorrect negation the xendomains initscript bails out
> early when both: "/dev/xen/privcmd" and "/proc/xen/privcmd"
> are present in dom0.

Acked-by: Ian Jackson 

Sorry for not spotting this bug when reading the patch before it was
committed !

Ian.

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

[Xen-devel] [distros-debian-snapshot test] 38464: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38405
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38405
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38405
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail REGR. 
vs. 38405

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

baseline version:
 flight   38405

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

[Xen-devel] [PATCH] Fix regression in xendomains initscript: test for privcmd char device

[Sander Eikelenboom]

Since commit:
"xendomains initscript: test for privcmd char device"
(1367e9e5ba4d1612e303123ec0bbf961100fcfa1)
due to incorrect negation the xendomains initscript bails out
early when both: "/dev/xen/privcmd" and "/proc/xen/privcmd"
are present in dom0.

Signed-off-by: Sander Eikelenboom 
---
 tools/hotplug/Linux/xendomains.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index 686f061..dfe0b33 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -45,7 +45,7 @@ fi
 
 # Correct exit code would probably be 5, but it's enough
 # if xend complains if we're not running as privileged domain
-if ! [ -e /dev/xen/privcmd ] || [ -e /proc/xen/privcmd ]; then
+if [ ! -e /dev/xen/privcmd ] && [ ! -e /proc/xen/privcmd ]; then
exit 0
 fi
 
-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  eedecb3cf0b2ce1ffc2eb08f3c73f88d42c382c9
baseline version:
 xen  3c80d6f3c61eb0f8072f70b0a9a8c8c7adf17572

Last test of basis65545  2015-12-08 09:00:48 Z0 days
Testing same since65561  2015-12-08 14:00:48 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] xenstore domain

[Juergen Gross]

On 08/12/15 16:04, Andrew Cooper wrote:
> On 08/12/15 14:44, Juergen Gross wrote:
>> I'm just playing a little bit with xenstore in an own domain.
>>
>> I've come across some questions I'd like to have some answers to before
>> presenting official patches to make this an easy configurable option:
>>
>> a) As this would need a boot time configuration item I'd like to add
>>e.g. /etc/xen/server.conf where such global configuration options
>>could be set via directives. Is this generally okay? If yes, which
>>format? Easiest way would be entries like
>>VAR=value
>>which can be either sourced in from shell scripts or can easily be
>>parsed in all programming languages. What are the preferences here?
> 
> Any configuration like this going to be toolstack-specific.  I would
> recommend against using a name as generic as that.
> 
> /etc/xl.conf already exists, which IMO would be the natural place for
> this to live, but it isn't parseable by shell, because of vif notation.

OTOH that file wouldn't be just for xl. It would be consumed by e.g.
xencommons. Other configuration options I'd plan to add would be
driver domains dedicated to specific interface cards.

> One option might be to alter xl.conf to be compatible with shell
> parsing.  It wouldn't be complicated (even in upgrade situations), and
> would offer rather more flexibility.

Shell parsing could be even handled via a rather simple filter, I guess.

>> b) Today init-xenstore-domain will require flask to be enabled. An
>>alternative would be to add a new domain creation flag to allow the
>>domains with that flag set calling xc_domain_getinfo(). Thoughts?
> 
> Which flag?

A new domcr_flag.

>> c) In order to be as flexible as possible I think the xenstore domain
>>should be allowed to auto-balloon according to it's needs. Is anyone
>>already working on ballooning support for mini-os?
> 
> This is the C xenstore?  Have you investigated whether Mirage-based
> stubdomains can balloon?

Aren't they based on mini-os, too?


Juergen


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

Re: [Xen-devel] [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen

[Jim Fehlig]

Daniel P. Berrange wrote:
> On Mon, Dec 07, 2015 at 10:59:32PM -0700, Jim Fehlig wrote:
>> On 12/07/2015 11:52 AM, Daniel P. Berrange wrote:
>>> On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote:
 In commit d2e5538b1, the libxl driver was changed to copy interface
 names autogenerated by libxl to the corresponding network def in the
 domain's virDomainDef object. The copied name is freed when the domain
 transitions to the shutoff state. But when migrating a domain, the
 autogenerated name is included in the XML sent to the destination host.
 It is possible an interface with the same name already exists on the
 destination host, causing migration to fail. Indeed the Xen project's
 OSSTEST CI already encountered such a failure.

 This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
 the autogenerated names to be excluded when parsing and formatting
 inactive config.

 Signed-off-by: Jim Fehlig 
 ---

 This is an alternative approach to Joao's fix for this regression

 https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html

 I think it is the same approach used by the qemu driver. My only
 reservation is that it expands the potential for clashes with
 user-defined names. I.e. with this change both 'vnet' and 'vif' are
 reserved prefixes.
>>> Hmm, yes, tricky one.
>>>
>>> If we only care about XML parsing, then you could register a post
>>> parse callback instead to do this.
>> AFAIK, XML parsing is all that's in play here.
>>
>>> I'm not clear why we also have it in the virDomainNetDefFormat
>>> method - and we can't solve that with a post-parse callback.
>>>
>>>
>>> The other option would be to make the reserved prefix be a
>>> capability that the parser/formatter could read.
>> This seems like the best option, since a post-parse callback doesn't solve 
>> the
>> problem in virDomainNetDefFormat. It also has the upshot of making the prefix
>> visible and known to users. But I doubt such a change is suitable during 
>> 1.3.0
>> freeze.  With the freeze in mind, seems the best solution to the libxl 
>> migration
>> regression is revert d2e5538b1. It can be added again post-1.3.0 release, 
>> after
>> adding the prefix to capabilities.
>>
>> DV, since you may be making the release soon, feel free to revert d2e5538b1 
>> if
>> you agree.
> 
> Yeah, just go ahead & revert it Jim,  DV isn't doing the releae until
> tomorrow morning

I've pushed the revert.

Joao, sorry for yanking this for 1.3.0. We can get it in 1.3.1, after exposing
the prefix in capabilities.

Regards,
Jim


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

Re: [Xen-devel] xenstore domain

[Andrew Cooper]

On 08/12/15 16:02, Juergen Gross wrote:
> On 08/12/15 16:04, Andrew Cooper wrote:
>> On 08/12/15 14:44, Juergen Gross wrote:
>>> I'm just playing a little bit with xenstore in an own domain.
>>>
>>> I've come across some questions I'd like to have some answers to before
>>> presenting official patches to make this an easy configurable option:
>>>
>>> a) As this would need a boot time configuration item I'd like to add
>>>e.g. /etc/xen/server.conf where such global configuration options
>>>could be set via directives. Is this generally okay? If yes, which
>>>format? Easiest way would be entries like
>>>VAR=value
>>>which can be either sourced in from shell scripts or can easily be
>>>parsed in all programming languages. What are the preferences here?
>> Any configuration like this going to be toolstack-specific.  I would
>> recommend against using a name as generic as that.
>>
>> /etc/xl.conf already exists, which IMO would be the natural place for
>> this to live, but it isn't parseable by shell, because of vif notation.
> OTOH that file wouldn't be just for xl. It would be consumed by e.g.
> xencommons. Other configuration options I'd plan to add would be
> driver domains dedicated to specific interface cards.

It is still logically part of the "xl toolstack infrastructure", but I
accept your point.  The current xl.conf is all about how to create
domains in general, rather than specifically "how I would like my system
configured when starting up".

>
>> One option might be to alter xl.conf to be compatible with shell
>> parsing.  It wouldn't be complicated (even in upgrade situations), and
>> would offer rather more flexibility.
> Shell parsing could be even handled via a rather simple filter, I guess.
>
>>> b) Today init-xenstore-domain will require flask to be enabled. An
>>>alternative would be to add a new domain creation flag to allow the
>>>domains with that flag set calling xc_domain_getinfo(). Thoughts?
>> Which flag?
> A new domcr_flag.

Indicating what, precisely?

>
>>> c) In order to be as flexible as possible I think the xenstore domain
>>>should be allowed to auto-balloon according to it's needs. Is anyone
>>>already working on ballooning support for mini-os?
>> This is the C xenstore?  Have you investigated whether Mirage-based
>> stubdomains can balloon?
> Aren't they based on mini-os, too?

Heavily modified.  For one, they have fixed suspend/resume.  I don't
know whether they have ballooning, and it isn't completely obvious from
their repo.

Dave: any ideas?

~Andrew

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

Re: [Xen-devel] [PATCH v1 2/2] libxl: re-implement libxl__xs_printf()

[Ian Campbell]

On Wed, 2015-12-02 at 15:22 +, Paul Durrant wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: 02 December 2015 15:21
> > To: Paul Durrant; xen-de...@lists.xenproject.org
> > Cc: Ian Jackson; Stefano Stabellini; Wei Liu
> > Subject: Re: [PATCH v1 2/2] libxl: re-implement libxl__xs_printf()
> > 
> > On Tue, 2015-12-01 at 13:55 +, Paul Durrant wrote:
> > > This patch adds a new libxl__xs_vprintf() which actually checks the
> > > success of the underlying call to xs_write() (logging if it fails)
> > > and
> > > then re-implements libxl__xs_printf() using this (and replacing the
> > > call to vasprintf() with a call to libxl__vsprintf()).
> > 
> > Is the addition of libxl__xs_vprintf() an end in itself (i.e. do you
> > have
> > an upcoming use for it) or just an artefact of how you decided to fix
> > libxl__xs_printf()?
> > 
> 
> It's an artefact but seemed sufficiently useful to expose.

Thanks:
Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

[Ian Campbell]

On Mon, 2015-12-07 at 17:48 +0100, Roger Pau Monne wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
> guests.
> 
> This patch introduces a new structure (vcpu_hvm_context) that should be
> used
> in conjuction with the VCPUOP_initialise hypercall in order to initialize

"conjunction"

> vCPUs for HVM guests.
> 
> Signed-off-by: Roger Pau Monné 
> Signed-off-by: Andrew Cooper 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 

For the (trivial) ARM bit:

> Acked-by: Ian Campbell 
[...]
>  xen/arch/arm/domain.c |   5 +


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

Re: [Xen-devel] [PATCH v3 1/6] xl: Return proper error codes for block-attach and block-detach

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
> 
> Also while we're at it, normalize init and dispose of
> libxl_device_disk structures.  This means calling init and dispose in
> the actual functions where they are declared.
> 
> This in turn means changing parse_disk_config_multistring() to not
> call libxl_device_disk_init.  And that in turn means changes to
> callers of parse_disk_config().
> 
> It also means removing libxl_device_disk_init() from
> libxl.c:libxl_vdev_to_device_disk().  This is only called from
> xl_cmdimpl.c.

... and the ocaml bindings.

I can't remember what we decided regarding libxl "getter" functions and
initialisation of the data type (i.e. whose responsibility it is), but it
seems that changing a given calls semantics is rather dangerous API-wise.

Wei, ISTR you stumbling over this once and the formulation of A Plan(tm),
but I can't remember what it was, can you?

> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Wilk 
> 
> v3:
>  - Rebased to tip
> 
> v2:
>  - Restructure functions to make sure init and dispose are properly
>  called.
> ---
>  tools/libxl/libxl.c  |  2 --
>  tools/libxl/xl_cmdimpl.c | 29 -
>  2 files changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index bd3aac8..814d056 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2738,8 +2738,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx,
> uint32_t domid,
>  if (devid < 0)
>  return ERROR_INVAL;
>  
> -libxl_device_disk_init(disk);
> -
>  dompath = libxl__xs_get_dompath(gc, domid);
>  if (!dompath) {
>  goto out;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2b6371d..2ba2393 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -570,8 +570,6 @@ static void parse_disk_config_multistring(XLU_Config
> **config,
>  {
>  int e;
>  
> -libxl_device_disk_init(disk);
> -
>  if (!*config) {
>  *config = xlu_cfg_init(stderr, "command line");
>  if (!*config) { perror("xlu_cfg_init"); exit(-1); }
> @@ -3340,6 +3338,8 @@ static int cd_insert(uint32_t domid, const char
> *virtdev, char *phys)
>  xasprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
>    virtdev, phys ? phys : "");
>  
> +libxl_device_disk_init(&disk);
> +
>  parse_disk_config(&config, buf, &disk);
>  
>  /* ATM the existence of the backing file is not checked for qdisk
> @@ -6649,6 +6649,7 @@ int main_blockattach(int argc, char **argv)
>  uint32_t fe_domid;
>  libxl_device_disk disk;
>  XLU_Config *config = 0;
> +int rc = 0;
>  
>  SWITCH_FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
>  /* No options */
> @@ -6660,6 +6661,8 @@ int main_blockattach(int argc, char **argv)
>  }
>  optind++;
>  
> +libxl_device_disk_init(&disk);
> +
>  parse_disk_config_multistring
>  (&config, argc-optind, (const char* const*)argv + optind,
> &disk);
>  
> @@ -6668,14 +6671,17 @@ int main_blockattach(int argc, char **argv)
>  printf("disk: %s\n", json);
>  free(json);
>  if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-
> 1); }
> -return 0;
> +goto out;
>  }
>  
>  if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
>  fprintf(stderr, "libxl_device_disk_add failed.\n");
> -return 1;
> +rc = 1;
>  }
> -return 0;
> +out:
> +libxl_device_disk_dispose(&disk);
> +
> +return rc;
>  }
>  
>  int main_blocklist(int argc, char **argv)
> @@ -6726,18 +6732,23 @@ int main_blockdetach(int argc, char **argv)
>  /* No options */
>  }
>  
> +libxl_device_disk_init(&disk);
> +
>  domid = find_domain(argv[optind]);
>  
>  if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
>  fprintf(stderr, "Error: Device %s not connected.\n",
> argv[optind+1]);
> -return 1;
> +rc = 1;
> +goto out;
>  }
> -rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
> -if (rc) {
> +if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
>  fprintf(stderr, "libxl_device_disk_remove failed.\n");
> -return 1;
> +rc = 1;
>  }
> +
> +out:
>  libxl_device_disk_dispose(&disk);
> +
>  return rc;
>  }
>  

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

Re: [Xen-devel] [PATCH v3 2/6] libxl: Fix libxl_set_memory_target return value

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> libxl_set_memory_target seems to have the following return values:
> 
> * 1 on failure, if the failure happens because of a xenstore error *or*
> invalid target
> 
> * -1 if the setmaxmem hypercall
> 
> * -errno if the set_pod_target hypercall target fails
> 
> * 1 on success (!)
> 
> Make it consistenstly return ERROR_FAIL, unless the parameters were

"consistently"

> invalid.
> 
> To make this more robust, use 'lrc' for return values to functions

tools/libxl/CODING_STYLE recommends "r" for such variables (return values
of syscalls or libxc calls).

> whose return values are a different error space (like
> xc_domain_setmaxmem and xc_domain_set_pod_target), or where a failure
> means retry, rather than fail the whole function
> (libxl__fill_dom0_memory_info), to reduce the risk that future code
> shuffles will accidentally clobber the return value again.
> 
> Also remove the final call to xc_domain_getinfolist. There's no
> obvious reason for this call -- all it seems to be doing is checking
> to see if the domain exists; but if it doesn't exist, it will have
> already failed by this point.

If we aren't sure what it is for then I'd rather remove it in an
independent change, just in case.

> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/libxl/libxl.c | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 814d056..f8a0642 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4722,7 +4722,7 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> uint32_t domid,
>  int32_t target_memkb, int relative, int enforce)
>  {
>  GC_INIT(ctx);
> -int rc = 1, abort_transaction = 0;
> +int rc = ERROR_FAIL, abort_transaction = 0, lrc;

CODING_STYLE asks that rc not be initialised on declaration but set on the
failure paths (it allows a single line if () { rc = ; goto ... } to
mitigate the verbosity of this somewhat).

Ian.

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

Re: [Xen-devel] [PATCH v2] libxl: Introduce a template for devices with a controller

[Ian Campbell]

On Tue, 2015-12-08 at 12:26 +, George Dunlap wrote:
> On Tue, Dec 1, 2015 at 12:09 PM, George Dunlap
>  wrote:
> > We have several outstanding patch series which add devices that have
> > two levels: a controller and individual devices attached to that
> > controller.
> > 
> > In the interest of consistency, this patch introduces a section that
> > sketches out a template for interfaces for such devices.
> > 
> > Signed-off-by: George Dunlap 
> > Acked-by: Juergen Gross 
> 
> Committers,
> 
> Is there anything else that needs to be done for this to be checked in?

Just to prod a committer, sorry for the delay.

Now acked on the basis of Jurgen, Chun Yan and Olaf's Acks and pushed.

Chun Yan, I turned your informal Ack into 
Acked-by: Chun Yan Liu 
I hope that's ok. In future it would be appreciated if you would spell it
out in full to avoid any possible ambiguity or misunderstanding.

Thanks,
Ian.



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

Re: [Xen-devel] [PATCH] Fix regression in xendomains initscript: test for privcmd char device

[Ian Campbell]

On Tue, 2015-12-08 at 15:14 +, Ian Jackson wrote:
> Sander Eikelenboom writes ("[PATCH] Fix regression in xendomains
> initscript: test for privcmd char device"):
> > Since commit:
> > "xendomains initscript: test for privcmd char device"
> > (1367e9e5ba4d1612e303123ec0bbf961100fcfa1)
> > due to incorrect negation the xendomains initscript bails out
> > early when both: "/dev/xen/privcmd" and "/proc/xen/privcmd"
> > are present in dom0.
> 
> Acked-by: Ian Jackson 

Applied, thanks.


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

Re: [Xen-devel] [PATCH] tools/libxc: Identify problematic file in error messages

[Ian Campbell]

On Mon, 2015-12-07 at 13:09 +, Andrew Cooper wrote:
> Error messages along the lines of:
> 
>    xc: error: panic: xc_dom_core.c:207: failed to open file: No such file
> or
>    directory: Internal error
> 
> are of very little use.
> 
> Include the filename in the error messages, so the user does not have to
> resort to debug level logging to identify the problem.
> 
> Signed-off-by: Andrew Cooper 

Acked + applied.


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

Re: [Xen-devel] [PATCH v2] libxc: try to find last used pfn when migrating

[Ian Campbell]

On Wed, 2015-12-02 at 16:30 +0100, Juergen Gross wrote:
> On 02/12/15 16:28, Ian Campbell wrote:
> > On Wed, 2015-12-02 at 12:36 +, Andrew Cooper wrote:
> > > On 02/12/15 07:42, Juergen Gross wrote:
> > > > diff --git a/tools/libxc/xc_sr_save_x86_hvm.c
> > > > b/tools/libxc/xc_sr_save_x86_hvm.c
> > > > index cdee774..3c879ed 100644
> > > > --- a/tools/libxc/xc_sr_save_x86_hvm.c
> > > > +++ b/tools/libxc/xc_sr_save_x86_hvm.c
> > > > @@ -135,6 +135,20 @@ static int x86_hvm_normalise_page(struct
> > > > xc_sr_context *ctx,
> > > >  static int x86_hvm_setup(struct xc_sr_context *ctx)
> > > >  {
> > > >  xc_interface *xch = ctx->xch;
> > > > +xen_pfn_t nr_pfns;
> > > > +
> > > > +if ( xc_domain_nr_gpfns(xch, ctx->domid, &nr_pfns) < 0 )
> > > > +{
> > > > +PERROR("Unable to obtain the guest p2m size");
> > > > +return -1;
> > > > +}
> > > > +if ( nr_pfns > ~XEN_DOMCTL_PFINFO_LTAB_MASK )
> > > > +{
> > > > +PERROR("Cannot save this big a guest");
> > > 
> > > Strictly speaking to match the moved code, this should set errno =
> > > E2BIG.
> > > 
> > > However, the error handling in libxc is in a dire state, and the
> > > error
> > > message is retained, which is the important point.
> > > 
> > > Entire patch Reviewed-by: Andrew Cooper 
> > > with
> > > or without the errno tweaks.
> > 
> > I could make the errno tweak on commit, if there is agreement.
> 
> Sure, go ahead.

Now done, sorry for the delay... distractions...

Ian.


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

Re: [Xen-devel] [PATCH v3 2/6] libxl: Fix libxl_set_memory_target return value

[George Dunlap]

On 08/12/15 17:19, Ian Campbell wrote:
> On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
>> libxl_set_memory_target seems to have the following return values:
>>
>> * 1 on failure, if the failure happens because of a xenstore error *or*
>> invalid target
>>
>> * -1 if the setmaxmem hypercall
>>
>> * -errno if the set_pod_target hypercall target fails
>>
>> * 1 on success (!)
>>
>> Make it consistenstly return ERROR_FAIL, unless the parameters were
> 
> "consistently"
> 
>> invalid.
>>
>> To make this more robust, use 'lrc' for return values to functions
> 
> tools/libxl/CODING_STYLE recommends "r" for such variables (return values
> of syscalls or libxc calls).
> 
>> whose return values are a different error space (like
>> xc_domain_setmaxmem and xc_domain_set_pod_target), or where a failure
>> means retry, rather than fail the whole function
>> (libxl__fill_dom0_memory_info), to reduce the risk that future code
>> shuffles will accidentally clobber the return value again.
>>
>> Also remove the final call to xc_domain_getinfolist. There's no
>> obvious reason for this call -- all it seems to be doing is checking
>> to see if the domain exists; but if it doesn't exist, it will have
>> already failed by this point.
> 
> If we aren't sure what it is for then I'd rather remove it in an
> independent change, just in case.
> 
>> Signed-off-by: George Dunlap 
>> ---
>> CC: Ian Campbell 
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> ---
>>  tools/libxl/libxl.c | 27 +--
>>  1 file changed, 13 insertions(+), 14 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 814d056..f8a0642 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -4722,7 +4722,7 @@ int libxl_set_memory_target(libxl_ctx *ctx,
>> uint32_t domid,
>>  int32_t target_memkb, int relative, int enforce)
>>  {
>>  GC_INIT(ctx);
>> -int rc = 1, abort_transaction = 0;
>> +int rc = ERROR_FAIL, abort_transaction = 0, lrc;
> 
> CODING_STYLE asks that rc not be initialised on declaration but set on the
> failure paths (it allows a single line if () { rc = ; goto ... } to
> mitigate the verbosity of this somewhat).

Ack to all of the above.

 -George


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

Re: [Xen-devel] [PATCH v3 3/6] xl: Make set_memory_target return an error code on failure

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> Bring set_memory_target into line with set_memory_max (which does
> return an error code.
> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Wilk 
> ---
>  tools/libxl/xl_cmdimpl.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2ba2393..4455d73 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3297,9 +3297,10 @@ int main_memmax(int argc, char **argv)
>  return 0;
>  }
>  
> -static void set_memory_target(uint32_t domid, const char *mem)
> +static int set_memory_target(uint32_t domid, const char *mem)
>  {
> -long long int memorykb;
> +int64_t memorykb;

The switch from long long to int64_t here is just incidental, right?

It did cause me to notice that both libxl_set_memory_target
and libxl_domain_setmaxmem take a 32bit (inconsistently signed vs unsigned)
argument for the memkb, so apart from the loss of range vs
parse_mem_size_kb you also can't set the target as high as you can set the
maximum. Nice.

Ian.

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

Re: [Xen-devel] [PATCH v3 4/6] xl: Return an error on failed cd-insert

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> This makes xl more useful in scripts.
> 
> The strange thing about this is that the internal cd_insert function
> *already* returned something appropriate, and cd-eject was using it,
> but cd-insert wasnt.

Missing an apostrophe in wasnt.

> Signed-off-by: George Dunlap 

Acked-by: Ian Campbell 

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/libxl/xl_cmdimpl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 4455d73..72ece2e 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3405,8 +3405,7 @@ int main_cd_insert(int argc, char **argv)
>  virtdev = argv[optind + 1];
>  file = argv[optind + 2];
>  
> -cd_insert(domid, virtdev, file);
> -return 0;
> +return cd_insert(domid, virtdev, file);
>  }
>  
>  int main_console(int argc, char **argv)

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

Re: [Xen-devel] [PATCH v3 5/6] xl: Return error codes for pci* commands

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> Add return codes for pci-detach, pci-attach, pci-asssignable-add, and
> pci-assignable-remove.
> 
> Returning error codes makes it easier for shell scripts to tell if a
> command has failed or succeeded.
> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/libxl/xl_cmdimpl.c | 56 
> 
>  1 file changed, 37 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 72ece2e..5f21c37 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3495,10 +3495,11 @@ int main_pcilist(int argc, char **argv)
>  return 0;
>  }
>  
> -static void pcidetach(uint32_t domid, const char *bdf, int force)
> +static int pcidetach(uint32_t domid, const char *bdf, int force)
>  {
>  libxl_device_pci pcidev;
>  XLU_Config *config;
> +int rc = 0;

I think we should probably avoid "rc" for non-libxl error codes even in xl.

Also, I'd forgotten that since 00e110e44a0eb we are trying to have xl
main_* functions return either EXIT_SUCCESS or EXIT_FAILURE rather than 0,
1, -foo etc. That probably applies to many of the  earlier patches which
I've already commented on. I shan't go back and correct myself.

Ian.



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

Re: [Xen-devel] [PATCH v3 6/6] xl: Return error code on save

[Ian Campbell]

On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote:
> save_domain was already constructing an error code; it just wasn't
> being used.
> 
> Signed-off-by: George Dunlap 

Acked-by: Ian Campbell 


> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/libxl/xl_cmdimpl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 5f21c37..52aedcf 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -4712,8 +4712,7 @@ int main_save(int argc, char **argv)
>  if ( argc - optind >= 3 )
>  config_filename = argv[optind + 2];
>  
> -save_domain(domid, filename, checkpoint, leavepaused,
> config_filename);
> -return 0;
> +return save_domain(domid, filename, checkpoint, leavepaused,
> config_filename);
>  }
>  
>  int main_migrate(int argc, char **argv)

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

[Xen-devel] [xen-unstable-smoke test] 65569: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 65561

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

version targeted for testing:
 xen  40412e3c9979f1ec93cd95fc8486d778f5df
baseline version:
 xen  eedecb3cf0b2ce1ffc2eb08f3c73f88d42c382c9

Last test of basis65561  2015-12-08 14:00:48 Z0 days
Testing same since65569  2015-12-08 16:02:11 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Campbell 
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 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


Not pushing.


commit 40412e3c9979f1ec93cd95fc8486d778f5df
Author: Ian Jackson 
Date:   Wed Nov 18 15:34:54 2015 +

libxl: Fix bootloader-related virtual memory leak on pv build failure

The bootloader may call libxl__file_reference_map(), which mmap's the
pv_kernel and pv_ramdisk into process memory.  This was only unmapped,
however, on the success path of libxl__build_pv().  If there were a
failure anywhere between libxl_bootloader.c:parse_bootloader_result()
and the end of libxl__build_pv(), the calls to
libxl__file_reference_unmap() would be skipped, leaking the mapped
virtual memory.

Ideally this would be fixed by adding the unmap calls to the
destruction path for libxl__domain_build_state.  Unfortunately the
lifetime of the libxl__domain_build_state is opaque, and it doesn't
have a proper destruction path.  But, the only thing in it that isn't
from the gc are these bootloader references, and they are only ever
set for one libxl__domain_build_state, the one which is
libxl__domain_create_state.build_state.

So we can clean up in the exit path from libxl__domain_create_*, which
always comes through domcreate_complete.

Remove the now-redundant unmaps in libxl__build_pv's success path.

This is XSA-160.

Signed-off-by: George Dunlap 
Signed-off-by: Ian Jackson 
Tested-by: George Dunlap 
Acked-by: Ian Campbell 
(qemu changes not included)

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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/8/15 8:25 AM, Jan Beulich wrote:
 On 08.12.15 at 15:16,  wrote:
>> On 12/8/15 1:32 AM, Jan Beulich wrote:
>> On 07.12.15 at 22:27,  wrote:
 On 12/3/15 2:57 AM, Jan Beulich wrote:
 On 03.12.15 at 01:34,  wrote:
>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>> On 30.11.15 at 18:53,  wrote:
 On 11/30/15 8:36 AM, Jan Beulich wrote:
 On 24.11.15 at 18:51,  wrote:
>> +config ARCH_DEFCONFIG
>> +string
>> +default "arch/x86/configs/x86_64_defconfig"
>
> x86_defconfig perhaps?

 No. I was told to drop support for x86 entirely in an earlier review.
 Its not possible to configure for 32-bit x86 in v6.
>>>
>>> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
>>> Here I consider x86 as to basic architecture without any
>>> particular bit width in mind.
>>
>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
>> the original is correct. There is no defconfig for the ambiguous x86
>> family. You're either building for x86_64 or x86_32 (which I referred to
>> as x86 in my original response).
>>
>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
>> for its named correctly.
>
> But there is no x86_32 architecture form the hypervisor build's
> point of view, and hence x86 isn't ambiguous. In fact the mid-term
> plan is to remove leftovers of references to x86_64 (like the
> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
> possible. The only place they need to be kept are in the public
> interface.

 That's fine but you don't build things for "x86". You build them for
 "x86_64". XEN_TARGET_ARCH takes in "x86_64".
>>>
>>> The XEN_TARGET_ARCH value is of no interest here. The only fact
>>> that I care about is that there's only one x86 configuration, and
>>> hence I can't see why it shouldn't be named x86_defconfig.
>>
>> This is just how the upstream stuff works. Are we forking upstream's
>> kconfig just so we can call it "x86" instead of "x86_64"?
> 
> I don't think using
> 
> config ARCH_DEFCONFIG
>   string
>   default "arch/x86/configs/x86_defconfig"
> 
> instead of
> 
> config ARCH_DEFCONFIG
>   string
>   default "arch/x86/configs/x86_64_defconfig"
> 
> in a Kconfig file of ours is a fork. Or am I overlooking some other
> aspect?
> 
> Jan
> 

Its not that simple. When you run "make defconfig" it will default to
using "arch/$(SRCARCH)/configs/$(ARCH)_defconfig". Where SRCARCH =
TARGET_ARCH and ARCH = TARGET_SUBARCH = XEN_TARGET_ARCH. So to use real
values from the documentation how to build Xen:

- XEN_TARGET_ARCH=x86_64 make defconfig
- XEN_TARGET_ARCH=arm32 make defconfig
- XEN_TARGET_ARCH=arm64 make defconfig

The result is things build correctly. To make the variable build ups
change for x86 vs arm would require us to fork
xen/tools/kconfig/Makefile line 101 (potentially others).

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf bisection] complete build-i386-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  48aed71c6572db9204bfa8af090039d5f24f5bea
  Bug not present: 4aa9826def3bf9d817e7d245d46886a31de92c15
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65567/


  commit 48aed71c6572db9204bfa8af090039d5f24f5bea
  Author: Yonghong Zhu 
  Date:   Mon Dec 7 09:09:31 2015 +
  
  BaseTools: process the files by the priority in BUILDRULEORDER
  
  By the BUILDRULEORDER feature to process files listed in INF [Sources]
  sections in priority order, if a filename is listed with multiple
  extensions, the tools will use only the file that matches the first
  extension in the space separated list.
  
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Yonghong Zhu 
  Reviewed-by: Liming Gao 
  
  git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19143 
6f19259b-4bc3-4df7-8a09-765794883524


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/build-i386-xsm.xen-build 
--summary-out=tmp/65567.bisection-summary --basis-template=65468 
--blessings=real,real-bisect ovmf build-i386-xsm xen-build
Searching for failure / basis pass:
 65536 fail [host=baroque1] / 65468 [host=italia1] 65386 [host=italia0] 65359 
[host=italia0] 65336 [host=pinot0] 65319 [host=chardonnay0] 65293 
[host=huxelrebe1] 65278 [host=pinot1] 65258 [host=italia0] 65244 
[host=huxelrebe1] 65181 [host=pinot0] 65160 [host=nocera1] 65139 [host=nocera1] 
65119 [host=huxelrebe1] 65098 ok.
Failure / basis pass flights: 65536 / 65098
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Basis pass 9f419739d1ae849e0c4d75a131502f9367ca4a7d 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
Generating revisions with ./adhoc-revtuple-generator  
https://github.com/tianocore/edk2.git#9f419739d1ae849e0c4d75a131502f9367ca4a7d-fb48e7780e1e0e0a7702ed8772e68150a9f8d10e
 
git://xenbits.xen.org/qemu-xen.git#3fb401edbd8e9741c611bfddf6a2032ca91f55ed-f6787aedc9043bffc5ee5b64c6d46b8fc7298a96
 
git://xenbits.xen.org/xen.git#22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c-713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Loaded 9098 nodes in revision graph
Searching for test results:
 65098 pass 9f419739d1ae849e0c4d75a131502f9367ca4a7d 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
 65119 [host=huxelrebe1]
 65139 [host=nocera1]
 65160 [host=nocera1]
 65181 [host=pinot0]
 65258 [host=italia0]
 65244 [host=huxelrebe1]
 65278 [host=pinot1]
 65293 [host=huxelrebe1]
 65319 [host=chardonnay0]
 65336 [host=pinot0]
 65359 [host=italia0]
 65485 fail 76a5e6c269a2ce559c8b2d93d77c6672591327a5 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65386 [host=italia0]
 65468 [host=italia1]
 65489 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65509 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65525 pass 9f419739d1ae849e0c4d75a131502f9367ca4a7d 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
 65526 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65552 fail 48aed71c6572db9204bfa8af090039d5f24f5bea 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65493 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65528 pass 9f419739d1ae849e0c4d75a131502f9367ca4a7d 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
c87303c04738b0e837da6e891eb561de0bf1b64e
 65529 pass d9b51b21e7ec6c75ba66a6f7b641f79a09c0bdae 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65541 pass 2ff9e575746a2664580df87e4e61d1183a67dcec 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65506 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Andrew Cooper]

On 08/12/15 17:59, Doug Goldstein wrote:
> On 12/8/15 8:25 AM, Jan Beulich wrote:
> On 08.12.15 at 15:16,  wrote:
>>> On 12/8/15 1:32 AM, Jan Beulich wrote:
>>> On 07.12.15 at 22:27,  wrote:
> On 12/3/15 2:57 AM, Jan Beulich wrote:
> On 03.12.15 at 01:34,  wrote:
>>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>>> On 30.11.15 at 18:53,  wrote:
> On 11/30/15 8:36 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51,  wrote:
>>> +config ARCH_DEFCONFIG
>>> +   string
>>> +   default "arch/x86/configs/x86_64_defconfig"
>> x86_defconfig perhaps?
> No. I was told to drop support for x86 entirely in an earlier review.
> Its not possible to configure for 32-bit x86 in v6.
 x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
 Here I consider x86 as to basic architecture without any
 particular bit width in mind.
>>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
>>> the original is correct. There is no defconfig for the ambiguous x86
>>> family. You're either building for x86_64 or x86_32 (which I referred to
>>> as x86 in my original response).
>>>
>>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
>>> for its named correctly.
>> But there is no x86_32 architecture form the hypervisor build's
>> point of view, and hence x86 isn't ambiguous. In fact the mid-term
>> plan is to remove leftovers of references to x86_64 (like the
>> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
>> possible. The only place they need to be kept are in the public
>> interface.
> That's fine but you don't build things for "x86". You build them for
> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
 The XEN_TARGET_ARCH value is of no interest here. The only fact
 that I care about is that there's only one x86 configuration, and
 hence I can't see why it shouldn't be named x86_defconfig.
>>> This is just how the upstream stuff works. Are we forking upstream's
>>> kconfig just so we can call it "x86" instead of "x86_64"?
>> I don't think using
>>
>> config ARCH_DEFCONFIG
>>  string
>>  default "arch/x86/configs/x86_defconfig"
>>
>> instead of
>>
>> config ARCH_DEFCONFIG
>>  string
>>  default "arch/x86/configs/x86_64_defconfig"
>>
>> in a Kconfig file of ours is a fork. Or am I overlooking some other
>> aspect?
>>
>> Jan
>>
> Its not that simple. When you run "make defconfig" it will default to
> using "arch/$(SRCARCH)/configs/$(ARCH)_defconfig". Where SRCARCH =
> TARGET_ARCH and ARCH = TARGET_SUBARCH = XEN_TARGET_ARCH. So to use real
> values from the documentation how to build Xen:
>
> - XEN_TARGET_ARCH=x86_64 make defconfig
> - XEN_TARGET_ARCH=arm32 make defconfig
> - XEN_TARGET_ARCH=arm64 make defconfig
>
> The result is things build correctly. To make the variable build ups
> change for x86 vs arm would require us to fork
> xen/tools/kconfig/Makefile line 101 (potentially others).

Frankly, I don't think it is worth worrying that x86_64 could be
shortened.  It is more important to reduce divergence from upstream Kconfig.

After all, x86_128 is likely to come along sometime.

~Andrew

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

Re: [Xen-devel] Success with pv guest and ATI Radeon HD4550

[Konrad Rzeszutek Wilk]

> > Correct, it was just providing the rom to the driver. Is there already
> > a way to allow pci-front to pass this, or does it require a patch? I
> > do not know the code base very well, nor do I have much experience
> > with how PCI operates, I was pretty excited to get this far :)
> 
> I am not very familiar with pci-{front,back}, although lack of Option
> ROM mapping seems like the obvious explanation.
> 
> Konrad - any ideas?

Oh, yes. The code there has an nice TODO :-). And it would be all
in the drivers/xen/xen-pciback codebase.


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

Re: [Xen-devel] [PATCH v2 04/14] x86/time.c: Use correct guest TSC frequency in tsc_get_info()

[Boris Ostrovsky]

On 12/07/2015 08:08 PM, Haozhong Zhang wrote:

On 12/07/15 12:53, Boris Ostrovsky wrote:

On 12/06/2015 03:58 PM, Haozhong Zhang wrote:

When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
TSC_MODE_PVRDTSCP and no TSC emulation is used, the existing
tsc_get_info() uses the host TSC frequency (cpu_khz) as the guest TSC
frequency. However, tsc_set_info() may set the guest TSC frequency to a
value different than the host. In order to keep consistent to
tsc_set_info(), this patch makes tsc_get_info() use the value set by
tsc_set_info() as the guest TSC frequency.

Signed-off-by: Haozhong Zhang 
---
  xen/arch/x86/time.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 1091e69..95df4f1 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1749,6 +1749,9 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
uint64_t *elapsed_nsec, uint32_t *gtsc_khz,
uint32_t *incarnation)
  {
+bool_t enable_tsc_scaling = has_hvm_container_domain(d) &&
+cpu_has_tsc_ratio;

&& !d->arch.vtsc ?

(assuming my comment to the previous patch is correct).


enable_tsc_scaling in tsc_get_info() is always used in the condition
!d->arch.vtsc, so it's not necessary to include it again in
enable_tsc_scaling.


+
  *incarnation = d->arch.incarnation;
  *tsc_mode = d->arch.tsc_mode;
@@ -1769,7 +1772,7 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
  }
  tsc = rdtsc();
  *elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns);
-*gtsc_khz = cpu_khz;
+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : cpu_khz;
  break;
  case TSC_MODE_PVRDTSCP:
  if ( d->arch.vtsc )
@@ -1779,10 +1782,13 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
  }
  else
  {
+struct time_scale *scale = enable_tsc_scaling ?
+   &this_cpu(cpu_time).tsc_scale :
+   &d->arch.vtsc_to_ns;

IIUIC tsc_scale is host property and so why would it be used if TSC scaling
is available to guests?


scale is used below to convert a host TSC to nanosec. When TSC scaling is used,
d->arch.vtsc_to_ns may not base on the host TSC frequency, so I turn to the host
tsc_scale instead.


OK. Can we then use tsc_scale for both with and without TSC scaling? (on 
the set side too).


(And as a side note, I think that the comment in 
include/asm-x86/domain.h describing vtsc_to_ns as being used for 
emulated cases is rather misleading. We use it for both emulated and native)


-boris




Haozhong


-boris



  tsc = rdtsc();
-*elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns) -
+*elapsed_nsec = scale_delta(tsc, scale) -
  d->arch.vtsc_offset;
-*gtsc_khz = 0; /* ignored by tsc_set_info */
+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : 0;
  }
  break;
  }



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-prev   3 host-install(3) broken REGR. vs. 65114
 build-i386-xsm3 host-install(3) broken REGR. vs. 65114
 build-amd64   5 xen-build fail REGR. vs. 65114
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail in 65488 
REGR. vs. 65114

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken in 65488 pass in 
65463
 test-amd64-amd64-libvirt-pair 3 host-install/src_host(3) broken in 65488 pass 
in 65463
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 65488 
pass in 65463
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
65488
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 65463 pass in 65488
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 65463 pass in 
65540
 test-armhf-armhf-libvirt-xsm 11 guest-startfail in 65463 pass in 65540
 test-armhf-armhf-xl-rtds 11 guest-startfail in 65488 pass in 65540

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) broken in 65488 
blocked in 65114
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail blocked in 65114
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65488 blocked in 65114
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail in 65488 like 65114
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65488 like 65114
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail in 65488 like 65114
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 65488 like 65114
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail in 65488 like 65114
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 65114

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 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-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) bl

Re: [Xen-devel] [PATCH v2 06/14] x86/time.c: Scale host TSC in pvclock properly

[Boris Ostrovsky]

On 12/07/2015 08:52 PM, Haozhong Zhang wrote:

On 12/07/15 13:14, Boris Ostrovsky wrote:

On 12/06/2015 03:58 PM, Haozhong Zhang wrote:

This patch makes the pvclock return the scaled host TSC and
corresponding scaling parameters to HVM domains if guest TSC is not
emulated and TSC scaling is enabled.

Signed-off-by: Haozhong Zhang 

+Joao who has been staring at this code.

Joao, can you run this series through your test with non-native frequency?
(http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg00683.html
provides an interface to set it in config file).



---
  xen/arch/x86/time.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 95df4f1..732d1e9 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu *v, int 
force)
  }
  else
  {
-tsc_stamp = t->local_tsc_stamp;
-
-_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
-_u.tsc_shift = (s8)t->tsc_scale.shift;
+if ( is_hvm_domain(d) && cpu_has_tsc_ratio )
+{
+tsc_stamp= hvm_funcs.scale_tsc(v, t->local_tsc_stamp);
+_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
+_u.tsc_shift = d->arch.vtsc_to_ns.shift;

I am not sure this is correct (which is why I asked Joao to look at this and
test). The scaler below is calculated as result of TSC calibration across
physical CPUs and what you use above (vtsc_to_ns) is an uncalibrated value.


Because guest TSC is synchronized among all vcpus of a domain, I think
it's safe to use d->arch.vtsc_to_ns here.


This is only guaranteed if we have constant/reliable TSC. So perhaps you 
should set tsc_scaling_supported only when either (or both?) of these 
TSC properties are true. Which is probably the case anyway but may be 
worth explicitly checking in start_svm/vmx? (and use 
tsc_scaling_supported instead of cpu_has_tsc_ratio in the 'if' statement)


And just like I asked in the previous email --- should we then use the 
same scaler (which would be vtsc_to_ns) in both cases? At least for 
guests in HVM containers (it may work for PV guests as well, but it 
would need to be confirmed).


Also, I noticed that this routine uses is_hvm_domain(). I think it 
should be has_hvm_container_domain().


-boris



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

Re: [Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

[Konrad Rzeszutek Wilk]

On Tue, Dec 08, 2015 at 12:51:25PM +, Julien Grall wrote:
> Hi Konrad,
> 
> On 07/12/15 15:01, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 07, 2015 at 02:21:46PM +, Julien Grall wrote:
> >> Thank you, the changes look good to me. What about patch #2?
> > 
> > Oh, I thought you said you would rebase it - so I had been waiting
> > for that.
> > 
> > Should have communicated that much better.
> > 
> > If it wouldn't be too much trouble - could you rebase #2 please?
> 
> I'm also providing a rebase of #1 because your wasn't correct. See
> attachments.
> 
> git://xenbits.xen.org/people/julieng/linux-arm.git
> branch blkfront-64-indirect-v4

OK, I've taken those two and I am testing them now.

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

Re: [Xen-devel] [PATCHv6] 03/28] build: use generated Kconfig options for Xen

[Doug Goldstein]

On 11/30/15 8:45 AM, Jan Beulich wrote:
 On 24.11.15 at 18:51,  wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -26,6 +26,9 @@ default: build
>>  .PHONY: dist
>>  dist: install
>>  
>> +.PHONY: build
>> +build:: $(BASEDIR)/include/config/auto.conf
>> +
>>  .PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags
> 
> I do not see why you need to add build to PHONY's dependencies
> another time.
> 
>> @@ -227,9 +230,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
>> defconfig \
>>  $(kconfig):
>>  $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
>> $@
>>  
>> -$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
>> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd 
>> $(BASEDIR)/.config
>>  $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>>  
>>  # Allow people to just run `make` as before and not force them to configure
>> -$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
>> +$(BASEDIR)/.config:
>>  $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) defconfig
> 
> This should be one of the oldconfig targets now, shouldn't it?

oldconfig uses .config. This is the case when the user has checked out
the tree fresh. Its there to not change the workflow of "git clone ...
&& cd xen/xen && make"

> 
>> +# Break the dependency chain for the first run
>> +$(BASEDIR)/include/config/auto.conf.cmd: ;
>> +
>> +-include $(BASEDIR)/include/config/auto.conf.cmd
> 
> The comment is quite a bit different in Linux, and seems to make more
> sense. Also note how Linux has an empty rule for $(KCONFIG_CONFIG),
> a variable which iirc you defined in an earlier patch and hence perhaps
> you should be using here.

I don't see where that's defined.

> 
>> --- a/xen/include/xen/config.h
>> +++ b/xen/include/xen/config.h
>> @@ -12,6 +12,8 @@
>>  #endif
>>  #include 
>>  
>> +#include 
> 
> First thing perhaps?
> 
> Jan
> 

Done.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  91e204d37f44913913776d0a89279721694f8b32
baseline version:
 xen  eedecb3cf0b2ce1ffc2eb08f3c73f88d42c382c9

Last test of basis65561  2015-12-08 14:00:48 Z0 days
Failing since 65569  2015-12-08 16:02:11 Z0 days2 attempts
Testing same since65572  2015-12-08 18:00:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chun Yan Liu 
  George Dunlap 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Juergen Gross 
  Olaf Hering 
  Sander Eikelenboom 

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

[Xen-devel] [PATCH] libxl: update check-xl-disk-parse

[Wei Liu]

The block-attach command now returns 1 when fails. Update first test
case to expect return value 1 instead of 255.

The parser now doesn't generate output for default values. Remove them
from expected output.

The "discard=" variant is never not supported, so delete two test cases
with that variant.

Reported-by: Jim Fehlig 
Signed-off-by: Wei Liu 
---
Cc: Jim Fehlig 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
 tools/libxl/check-xl-disk-parse | 100 
 1 file changed, 8 insertions(+), 92 deletions(-)

diff --git a/tools/libxl/check-xl-disk-parse b/tools/libxl/check-xl-disk-parse
index 1bec4ca..03572e4 100755
--- a/tools/libxl/check-xl-disk-parse
+++ b/tools/libxl/check-xl-disk-parse
@@ -40,7 +40,7 @@ complete () {
 fi
 }
 
-e=255
+e=1
 
 
 #-- test data --
@@ -52,18 +52,10 @@ one $e foo
 
 expected 

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Thomas Gleixner]

On Fri, 4 Dec 2015, David Vrabel wrote:
> On 04/12/15 14:06, David Vrabel wrote:
> > On 03/12/15 10:43, David Vrabel wrote:
> >> Adding the rtc platform device when there are no legacy irqs (no
> >> legacy PIC) causes a conflict with other devices that end up using the
> >> same irq number.
> > 
> > An alternative is to remove the rtc_cmos platform device in Xen PV
> > guests.
> > 
> > Any preference on how this regression should be fixed?
> > 
> > David
> > 
> > 8<--
> > x86: Xen PV guests don't have the rtc_cmos platform device
> > 
> [...]
> > --- a/arch/x86/kernel/rtc.c
> > +++ b/arch/x86/kernel/rtc.c
> > @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
> > }
> >  #endif
> >  
> > +   if (xen_pv_domain())
> > +   return -ENODEV;
> > +
> 
> Note there's a missing include that breaks !XEN builds.

What's the state of this?

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

[Xen-devel] [qemu-mainline test] 65542: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 65498 pass in 65542
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 65498 
pass in 65542
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 65498
 test-amd64-amd64-xl-qcow2 3 host-install(3)   broken pass in 65498
 test-amd64-amd64-xl-multivcpu 22 leak-check/check  fail in 65498 pass in 65542

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair  4 host-install/dst_host(4) broken like 65474
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 65474
 test-armhf-armhf-libvirt  6 xen-bootfail in 65498 blocked in 65474
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 65474

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 65498 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-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-amd64-libvirt-xsm 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-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-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 qemuuc3626ca7df027dabf0568284360a23faf18f0884
baseline version:
 qemuua5582eac15171ffea99f9962dd9a4bf3c1dd2f1c

Last test of basis65474  2015-12-07 11:13:35 Z1 days
Testing same since65498  2015-12-08 00:43:22 Z0 days2 attempts


People who touched revisions under test:
  Andrew Baumann 
  Denis V. Lunev 
  Fam Zheng 
  Jason Wang 
  Markus Armbruster 
  Michael S. Tsirkin 
  Peter Maydell 
  Prasad J Pandit 

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

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Boris Ostrovsky]

On 12/08/2015 04:02 PM, Thomas Gleixner wrote:

On Fri, 4 Dec 2015, David Vrabel wrote:

On 04/12/15 14:06, David Vrabel wrote:

On 03/12/15 10:43, David Vrabel wrote:

Adding the rtc platform device when there are no legacy irqs (no
legacy PIC) causes a conflict with other devices that end up using the
same irq number.

An alternative is to remove the rtc_cmos platform device in Xen PV
guests.

Any preference on how this regression should be fixed?

David

8<--
x86: Xen PV guests don't have the rtc_cmos platform device


[...]

--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
  #endif
  
+	if (xen_pv_domain())

+   return -ENODEV;
+

Note there's a missing include that breaks !XEN builds.

What's the state of this?


I think we are waiting for x86 maintainers to express their preference. 
There were 3 proposals to add in add_rtc_cmos()


1. if (!nr_legacy_irqs())
return -ENODEV;

2. #ifdef XEN
if (xen_pv_domain())
return -ENODEV;
#endif

3. if (paravirt_enabled())
return -ENODEV;


-boris

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

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Thomas Gleixner]

On Tue, 8 Dec 2015, Boris Ostrovsky wrote:
> On 12/08/2015 04:02 PM, Thomas Gleixner wrote:
> > > > --- a/arch/x86/kernel/rtc.c
> > > > +++ b/arch/x86/kernel/rtc.c
> > > > @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
> > > > }
> > > >   #endif
> > > >   + if (xen_pv_domain())
> > > > +   return -ENODEV;
> > > > +
> > > Note there's a missing include that breaks !XEN builds.
> > What's the state of this?
> 
> I think we are waiting for x86 maintainers to express their preference. There
> were 3 proposals to add in add_rtc_cmos()
> 
> 1. if (!nr_legacy_irqs())
> return -ENODEV;
> 
> 2. #ifdef XEN
> if (xen_pv_domain())
> return -ENODEV;
> #endif
> 
> 3. if (paravirt_enabled())
> return -ENODEV;

Either #2 (but with the #ifdefs removed, include the proper header
instead) or #3.

Thanks,

tglx

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