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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  8b7a356409023f60f80e9f4b00bba16ad56cd77b
baseline version:
 xen  f354fb4670132c9811b433ba34fb8edd46f7

Last test of basis95235  2016-06-03 10:55:03 Z6 days
Failing since 95328  2016-06-06 13:42:21 Z3 days4 attempts
Testing same since95447  2016-06-08 17:16:14 Z1 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Vitaly Kuznetsov 
  Wei Liu 

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 

[Xen-devel] [xen-4.7-testing baseline test] 95446: tolerable FAIL

[osstest service owner]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen6 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c2a17869d5dcd845d646bf4db122cad73596a2be
baseline version:
 xen  c2a17869d5dcd845d646bf4db122cad73596a2be

Last test of basis95446  2016-06-08 16:21:53 Z1 days
Testing same since0  1970-01-01 00:00:00 Z 16962 days0 attempts

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 

[Xen-devel] [xen-4.4-testing test] 95439: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  3 host-install(3) broken in 95373 REGR. vs. 95234
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95234
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. 
vs. 95234
 test-amd64-i386-qemuu-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
95234
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1  fail REGR. vs. 95234
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
95234
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95234
 test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. 
vs. 95234
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95234
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 95234
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95234
 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95234
 test-amd64-amd64-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95234
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95234
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 95234
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95234
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 95234
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 95234
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 95234
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 95234
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 95234
 test-armhf-armhf-xl-multivcpu 16 guest-start.2   fail in 95373 REGR. vs. 95234

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2  4 host-ping-check-nativefail pass in 95373
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat  fail pass in 95373

Tests which did not succeed, but are not blocking:
 build-amd64-rumpuserxen   1 build-check(1)blocked in 95373 n/a
 build-amd64-libvirt   1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1) blocked in 95373 n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)  blocked in 95373 n/a
 test-amd64-amd64-xl   1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked in 95373 n/a
 test-amd64-i386-xl1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)  blocked in 95373 n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked in 95373 n/a
 test-amd64-amd64-libvirt  1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 95373 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 95373 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1) blocked in 95373 n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked in 95373 n/a
 test-amd64-amd64-pair 1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)  blocked in 95373 n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked in 95373 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1) blocked in 95373 n/a
 test-amd64-i386-xl-raw1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-pair  1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-pygrub   1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)blocked in 95373 n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 95373 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 95373 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 95373 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 95373 n/a
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. 
vs. 95290
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
95290
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. 
vs. 95290
 test-amd64-i386-qemuu-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
95290
 test-amd64-amd64-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95290
 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95290
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95290
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95290
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1  fail REGR. vs. 95290
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 95290
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95290
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 95290
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 95290
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95290
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 95290
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install  fail REGR. vs. 95290
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 95290
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 95290
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95290
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 95290
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 95290
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 95290
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 95290

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-amd 14 capture-logs/l1(14) fail blocked in 95290
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 95290
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 95290

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-intel 14 capture-logs/l1(14) fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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

version targeted for testing:
 xen  6338746f1b3db99016ca2c5fa030ceccd938745e
baseline version:
 xen  8c4b40337b66679bbb776b157c747a946ed06de5

Last test of basis95290  2016-06-05 09:32:15 Z4 days
Failing since 95333  2016-06-06 15:12:07 Z3 days3 attempts
Testing same since95434  2016-06-08 11:18:23 Z1 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Vitaly Kuznetsov 
  Wei Liu 

jobs:
 build-amd64  

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |   17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index c81b2ea..bf02a1b 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -1384,6 +1384,7 @@ document, but are included for prospective operating 
> system and boot
>  loader writers.
>  
>  @menu
> +* C structure alignment and padding consideration::
>  * Notes on PC:: 
>  * BIOS device mapping techniques::  
>  * Example OS code:: 
> @@ -1391,6 +1392,22 @@ loader writers.
>  @end menu
>  
>  
> +@node C structure alignment and padding consideration
> +@section C structure alignment and padding consideration
> +
> +Many C compilers try to optimize memory accesses aligning structure

"by aligning"

> +members properly. Usually they reach the goal by adding some padding.

What does "properly" mean here?  The default padding will be specified
by the default ABI the compiler conforms to.

> +This is very useful thing in general. However, if you try to mix assembler
> +with C or use C to implement structure low level access this behavior
> +may lead, at least, to quite surprising results. Hence, compiler should
> +be instructed to not optimize such accesses. Usually it is done by special
> +attribute added to structure definition, e.g. GCC compatible sources use
> +@samp{__attribute__ ((__packed__))} for this purpose. However, this is not
> +required if it is known that its members are properly aligned and compiler
> +does not do any optimization. Very good example of this is shown below in
> +@file{multiboot2.h} file.

I am not sure what you are trying to say.

~Andrew

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

[Xen-devel] [qemu-upstream-4.3-testing test] 95450: trouble: blocked/broken

[osstest service owner]

flight 95450 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95450/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuu0aabf85123a437e60e6cfb15f13bc559b75a21d5
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  124 days
Failing since 93977  2016-05-10 11:09:16 Z   30 days  119 attempts
Testing same since95450  2016-06-08 18:27:39 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 

Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data

[Doug Goldstein]

On 6/9/16 11:53 AM, Daniel De Graaf wrote:
> On 06/09/2016 12:15 PM, Jan Beulich wrote:
> On 09.06.16 at 16:47,  wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -132,6 +132,23 @@ config FLASK
>>>
>>>If unsure, say Y.
>>>
>>> +config XSM_POLICY
>>> +bool "Compile Xen with a built-in security policy"
>>> +default y
>>> +depends on XSM
>>> +---help---
>>> +  This includes a default XSM policy in the hypervisor so that the
>>> +  bootloader does not need to load a policy to get sane behavior
>>> from an
>>> +  XSM-enabled hypervisor.  If this is disabled, a policy must be
>>> +  provided by the bootloader or by Domain 0.  Even if this is
>>> enabled, a
>>> +  policy provided by the bootloader will override it.
>>> +
>>> +  This requires that the SELinux policy compiler (checkpolicy) be
>>> +  available when compiling the hypervisor; if this tool is not
>>> found, no
>>> +  policy will be added.
>>> +
>>> +  If unsure, say Y.
>>> +
>>>  config FLASK_AVC_STATS
>>>  def_bool y
>>>  depends on FLASK
>>
>> Placing this between FLASK and FLASK_AVC_STATS will break proper
>> menuconfig representation of the latter afaict.
>>
>> Jan
> 
> This option isn't visible in menuconfig.  Should I make it visible?
> 

I believe I actually had that as an outstanding question to you on the
series that introduced that flag.

-- 
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] [qemu-upstream-4.6-testing test] 95441: tolerable FAIL - PUSHED

[osstest service owner]

flight 95441 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95441/

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuuaa38966b6fb6008c290f1c6af97af24906ee5159
baseline version:
 qemuu14a60f98e0cd16e2636afb136129ed7f11cbfce0

Last test of basis93974  2016-05-10 10:29:46 Z   30 days
Testing same since95389  2016-06-07 17:14:21 Z2 days2 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Wei Liu 

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

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 07/10] multiboot2: Say that memory maps may not be available on EFI platforms

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |   11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index f1e0e09..c81b2ea 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -927,6 +927,10 @@ possible value for lower memory is 640 kilobytes. The 
> value returned for
>  upper memory is maximally the address of the first upper memory hole
>  minus 1 megabyte. It is not guaranteed to be this value.
>  
> +This tag may not be provided by some boot loaders on EFI platforms if EFI
> +boot services are enabled and available for loaded image (EFI boot services

"for the loaded".  And below.

~Andrew

> +not terminated tag exists in Multiboot information structure).
> +
>  @subsection BIOS Boot device
>  @example
>  @group
> @@ -1078,6 +1082,10 @@ indicated a reserved area.
>  The map provided is guaranteed to list all standard @sc{ram} that should
>  be available for normal use. This type however includes the regions occupied 
> by kernel, mbi, segments and modules. Kernel must take care not to overwrite 
> these regions.
>  
> +This tag may not be provided by some boot loaders on EFI platforms if EFI
> +boot services are enabled and available for loaded image (EFI boot services
> +not terminated tag exists in Multiboot information structure).
> +
>  @subsection Boot loader name
>  @example
>  @group
> @@ -1310,6 +1318,9 @@ u32 | descriptor version|
>  
>  This tag contains EFI memory map as per EFI specification.
>  
> +This tag may not be provided by some boot loaders on EFI platforms if EFI
> +boot services are enabled and available for loaded image (EFI boot services
> +not terminated tag exists in Multiboot information structure).
>  
>  @subsection EFI boot services not terminated
>  @example


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

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |   56 
> 
>  doc/multiboot2.h   |   24 ++
>  2 files changed, 80 insertions(+)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index 130176a..f1e0e09 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -359,6 +359,7 @@ executable header.
>  * Console header tags::
>  * Module alignment tag::
>  * EFI boot services tag::
> +* Relocatable header tag::
>  
>  @end menu
>  
> @@ -681,6 +682,47 @@ u32 | size = 8  |
>  This tag indicates that payload supports starting without
>  terminating boot services.
>  
> +@node Relocatable header tag
> +@subsection Relocatable header tag
> +
> +@example
> +@group
> ++---+
> +u16 | type = 10 |
> +u16 | flags |
> +u32 | size = 24 |
> +u32 | min_addr  |
> +u32 | max_addr  |
> +u32 | align |
> +u32 | preference|
> ++---+
> +@end group
> +@end example
> +
> +This tag indicates that image is relocatable.
> +
> +The meaning of each field is as follows:
> +
> +@table @code
> +@item min_addr
> +Lowest possible physical address at which image should be loaded.
> +Boot loader cannot load any part of image below this address.

"The bootloader".

> +
> +@item max_addr
> +Highest possible physical address at which loaded image should end.
> +Boot loader cannot load any part of image above this address.

"The bootloader".

> +
> +@item align
> +Image alignment in memory, e.g. 4096 (know on many machines as page).

I would drop the qualification in brackets.  It isn't helpful to the
intended audience.

> +
> +@item preference
> +It contains load address placement suggestion for boot loader.
> +Boot loader should follow it. @samp{0} means none, @samp{1} means
> +load image at lowest possible address but not lower than min_addr
> +and @samp{2} means load image at highest possible address but not
> +higher than max_addr.
> +@end table
> +
>  @node Machine state
>  @section MIPS machine state
>  
> @@ -1309,6 +1351,20 @@ u64 | pointer   |
>  This tag contains pointer to EFI amd64 image handle.
>  Usually it is boot loader image handle.
>  
> +@subsection Image load base physical address
> +@example
> +@group
> ++---+
> +u32 | type = 21 |
> +u32 | size = 12 |
> +u32 | load_base_addr|
> ++---+
> +@end group
> +@end example
> +
> +This tag contains image load base physical address. It is
> +provided only if image has relocatable header tag.
> +
>  @node Examples
>  @chapter Examples
>  
> diff --git a/doc/multiboot2.h b/doc/multiboot2.h
> index b85cb13..b181607 100644
> --- a/doc/multiboot2.h
> +++ b/doc/multiboot2.h
> @@ -62,6 +62,7 @@
>  #define MULTIBOOT_TAG_TYPE_EFI_BS18
>  #define MULTIBOOT_TAG_TYPE_EFI32_IH  19
>  #define MULTIBOOT_TAG_TYPE_EFI64_IH  20
> +#define MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR21
>  
>  #define MULTIBOOT_HEADER_TAG_END  0
>  #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
> @@ -73,11 +74,16 @@
>  #define MULTIBOOT_HEADER_TAG_EFI_BS7
>  #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
>  #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
> +#define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
>  
>  #define MULTIBOOT_ARCHITECTURE_I386  0
>  #define MULTIBOOT_ARCHITECTURE_MIPS32  4
>  #define MULTIBOOT_HEADER_TAG_OPTIONAL 1
>  
> +#define MULTIBOOT_LOAD_PREFERENCE_NONE 0
> +#define MULTIBOOT_LOAD_PREFERENCE_LOW 1
> +#define MULTIBOOT_LOAD_PREFERENCE_HIGH 2
> +
>  #define MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
>  #define MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
>  
> @@ -162,6 +168,17 @@ struct multiboot_header_tag_module_align
>multiboot_uint32_t size;
>  };
>  
> +struct multiboot_header_tag_relocatable
> +{
> +  multiboot_uint16_t type;
> +  multiboot_uint16_t flags;
> +  multiboot_uint32_t size;
> +  multiboot_uint32_t min_addr;
> +  multiboot_uint32_t max_addr;

64bit multiboot2 payloads could reasonably expect to be able to have
themselves relocated about the 4G boundary.

~Andrew

> +  multiboot_uint32_t align;
> +  multiboot_uint32_t preference;
> +};
> +
>  struct multiboot_color
>  {
>multiboot_uint8_t red;
> @@ -388,6 +405,13 @@ struct multiboot_tag_efi64_ih
>multiboot_uint64_t pointer;
>  };
>  
> +struct multiboot_tag_load_base_addr
> +{
> +  multiboot_uint32_t type;
> +  multiboot_uint32_t size;
> +  multiboot_uint32_t load_base_addr;
> +};
> +
>  #endif /* ! ASM_FILE */
>  
>  #endif /* ! MULTIBOOT_HEADER */


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

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |  108 
> +++-
>  doc/multiboot2.h   |2 +
>  2 files changed, 108 insertions(+), 2 deletions(-)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index e43df93..1583b76 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -534,6 +534,62 @@ The physical address to which the boot loader should 
> jump in order to
>  start running the operating system.
>  @end table
>  
> +@subsection EFI i386 entry address tag of Multiboot header
> +
> +@example
> +@group
> ++---+
> +u16 | type = 8  |
> +u16 | flags |
> +u32 | size  |
> +u_virt  | entry_addr|
> ++---+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses.
> +The meaning of each is as follows:
> +
> +@table @code
> +
> +@item entry_addr
> +The physical address to which the boot loader should jump in order to
> +start running EFI i386 compatible operating system code.
> +@end table
> +
> +This tag is taken into account only on EFI i386 platforms
> +when Multiboot image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot header are ignored.
> +
> +@subsection EFI amd64 entry address tag of Multiboot header
> +
> +@example
> +@group
> ++---+
> +u16 | type = 9  |
> +u16 | flags |
> +u32 | size  |
> +u_virt  | entry_addr|
> ++---+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses.
> +The meaning of each is as follows:

A 64bit entry cannot possibly be a physical, as paging is mandatory.

This is clearly supposed to be the entry virtual address, but it should
not be conflated with the position of the image in RAM.  The chances of
the two being the same is very small.

> +
> +@table @code
> +
> +@item entry_addr
> +The physical address to which the boot loader should jump in order to
> +start running EFI amd64 compatible operating system code.
> +@end table
> +
> +This tag is taken into account only on EFI amd64 platforms
> +when Multiboot image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot header are ignored.
> +
>  @node Console header tags
>  @subsection Flags tag
>  
> @@ -714,12 +770,60 @@ The OS image must leave interrupts disabled until it 
> sets up its own
>  
>  On EFI system boot services must be terminated.
>  
> +@section EFI i386 machine state with boot services enabled
> +
> +When the boot loader invokes the 32-bit operating system on EFI i386
> +platform and EFI boot services tag together with EFI i386 entry address
> +tag are present in the image Multiboot header, the machine must have the
> +following state:
> +
> +@table @samp
> +@item EAX
> +Must contain the magic value @samp{0x36d76289}; the presence of this
> +value indicates to the operating system that it was loaded by a
> +Multiboot-compliant boot loader (e.g. as opposed to another type of

Multiboot 2, not multiboot.

> +boot loader that the operating system can also be loaded from).
> +
> +@item EBX
> +Must contain the 32-bit physical address of the Multiboot
> +information structure provided by the boot loader (@pxref{Boot
> +information format}).
> +@end table
> +
> +All other processor registers, flag bits and state are set accordingly
> +to Unified Extensible Firmware Interface Specification, Version 2.6,
> +section 2.3.2, IA-32 Platforms, boot services.
> +
> +@section EFI amd64 machine state with boot services enabled
> +
> +When the boot loader invokes the 64-bit operating system on EFI amd64
> +platform and EFI boot services tag together with EFI amd64 entry address
> +tag are present in the image Multiboot header, the machine must have the
> +following state:
> +
> +@table @samp
> +@item RAX
> +Must contain the magic value @samp{0x36d76289}; the presence of this
> +value indicates to the operating system that it was loaded by a
> +Multiboot-compliant boot loader (e.g. as opposed to another type of

Again, Multiboot 2.

> +boot loader that the operating system can also be loaded from).
> +
> +@item RBX
> +Must contain the 64-bit physical address of the Multiboot

This is surely a virtual address, unless you expect a multiboot payload
to edit its own pagetables before it can read the info structure.

> +information structure provided by the boot loader (@pxref{Boot
> +information format}).
> +@end table
> +
> +All other processor registers, flag bits and state are set accordingly
> +to Unified Extensible Firmware Interface Specification, Version 2.6,
> +section 2.3.4, x64 Platforms, boot services.
> +
>  @node Boot information format
>  @section Boot 

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 02/10] multiboot2: Clarify meaning of information request header tag

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |   20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index 27e5a2f..a7e3584 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -443,15 +443,19 @@ u32[n]  | mbi_tag_types |
>  @end group
>  @end example
>  
> -@samp{mbi_tag_types} is an array of u32 each one representing an information
> -request
> -If this tag is present and @samp{optional} is set to @samp{0} information
> -conveyed by requested tag types must be present. If bootloader is unable
> -to supply this information it must fail with an error
> +@samp{mbi_tag_types} is an array of u32 each one representing an information 
> request.

"u32's, each"

>  
> -Note: it doesn't garantee that any tags of type @samp{mbi_tag_types} will
> -actually be present. E.g. on a videoless system even if you requested tag
> -@samp{8} no tags of type @samp{8} will be present in mbi.
> +If this tag is present and @samp{optional} is set to @samp{0} bootloader must

", the bootloader"

> +support (understand meaning of) requested tag(s) and be able to provide 
> relevant

"the requested".  I don't think you need to explain what supported
means, so I would just drop the brackets entirely.

> +information to image if it is available. If bootloader do not understand 
> meaning

"the image".  "the bootloader does not". "the meaning".

> +of requested tag(s) it must fail with an error. However, if it support a 
> given

"the requested".  "supports".

> +tag(s) but information conveyed by it/them is not available bootloader can 
> do not

"a given tag(s)" is an odd way of phrasing this.  I would recommend just
"supports a given tag, but the information requested by it is".

"available, the bootloader can't provide the requested".

> +provide requested tag(s) in Multiboot information structure and proceed 
> further.

"in the Multiboot".  What do you mean by "and proceed further" in this
case?  It also doesn't parse.  I presume you mean that it is legal for
the bootloader to not provide the requested information, but may
continue booting.

> +
> +Note: Above means that there is not guarantee that any tags of type 
> @samp{mbi_tag_types}

"The above", "there is no guarentee"

> +will actually be present. E.g. on a videoless system even if you requested 
> tag @samp{8}
> +and bootloader support it no tags of type @samp{8} will be present in 
> Multiboot

"the bootloader supports it, no".  "The Multiboot".

~Andrew

> +information structure.
>  
>  
>  @node Address header tag


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

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 01/10] multiboot2: Remove redundant if

[Andrew Cooper]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index 4b92918..27e5a2f 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -425,7 +425,7 @@ u32 | size  |
>  
>  @samp{type} is divided into 2 parts. Lower contains an identifier of 
> contents of the rest of the tag.
>  @samp{size} contains the size of tag including header fields.
> -If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set if 
> bootloader may ignore this tag if it 
> +If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set 
> bootloader may ignore this tag if it 

As a native English speaker, I think you want to s/if/, the/ in this
case.  Neither option currently parses.

~Andrew

>  lacks relevant support.
>  Tags are terminated by a tag of type @samp{0} and size @samp{8}.
>  


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

Re: [Xen-devel] [PATCH 11/11] oxenstored: honour XEN_{LOG, RUN}_DIR in oxenstored.conf

[David Scott]

> On 9 Jun 2016, at 16:51, Ian Jackson  wrote:
> 
> Wei Liu writes ("[PATCH 11/11] oxenstored: honour XEN_{LOG,RUN}_DIR in 
> oxenstored.conf"):
>> Generate oxenstored.conf with configure. This involves modifying
>> tools/configure.ac and rerun autogen.sh.
>> 
>> Signed-off-by: Wei Liu 
>> ---
>> Cc: Ian Jackson 
>> Cc: David Scott 
> 
> You should mention that autogen.sh should be rerun.
> 
> Acked-by: Ian Jackson 
> 
>> There are two hard-coded paths in logging.ml, but I'm not sure if
>> generate an ocaml _Path module is the right thing to do.
> 
> I would be interested to hear Dave's opinion.

For reference the paths are:

  let xenstored_log_destination = ref (File "/var/log/xenstored.log")
  let access_log_destination = ref (File "/var/log/xenstored-access.log”)

These correspond to the command line arguments:

  ("access-log-file", Config.String Logging.set_access_log_destination);
  ("xenstored-log-file", Config.String Logging.set_xenstored_log_destination);

I think if you want to remove these paths completely from the binary then 
generating a simple module would be fine. I guess other options would be

- make the paths into optional values, default to None, and interpret None as 
“don’t bother logging”. Might not be a good idea to encourage people to turn 
off logging though.
- make it mandatory to set the paths via the config file?

I don’t have a strong opinion though :-)

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

[Xen-devel] [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |   17 +
 1 file changed, 17 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index c81b2ea..bf02a1b 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1384,6 +1384,7 @@ document, but are included for prospective operating 
system and boot
 loader writers.
 
 @menu
+* C structure alignment and padding consideration::
 * Notes on PC:: 
 * BIOS device mapping techniques::  
 * Example OS code:: 
@@ -1391,6 +1392,22 @@ loader writers.
 @end menu
 
 
+@node C structure alignment and padding consideration
+@section C structure alignment and padding consideration
+
+Many C compilers try to optimize memory accesses aligning structure
+members properly. Usually they reach the goal by adding some padding.
+This is very useful thing in general. However, if you try to mix assembler
+with C or use C to implement structure low level access this behavior
+may lead, at least, to quite surprising results. Hence, compiler should
+be instructed to not optimize such accesses. Usually it is done by special
+attribute added to structure definition, e.g. GCC compatible sources use
+@samp{__attribute__ ((__packed__))} for this purpose. However, this is not
+required if it is known that its members are properly aligned and compiler
+does not do any optimization. Very good example of this is shown below in
+@file{multiboot2.h} file.
+
+
 @node Notes on PC
 @section Notes on PC
 
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 09/10] multiboot2: Add me to authors

[Daniel Kiper]

.. and properly format author list.

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index bf02a1b..a25c223 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -53,7 +53,9 @@ versions.
 @titlepage
 @sp 10
 @title The Multiboot Specification version @value{VERSION}
-@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro 
Ishiguro, Vladimir 'phcoder' Serbinenko
+@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn,
+@author Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko,
+@author Daniel Kiper
 @page
 @vskip 0pt plus 1filll
 @insertcopying
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 10/10] multiboot2: Bump version to 2.0

[Daniel Kiper]

.. and add 2016 to copyright.

Signed-off-by: Daniel Kiper 
---
 configure.ac   |2 +-
 doc/multiboot.texi |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index b11961d..585b37a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@ dnl LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER 
RESULTING FROM THE
 dnl USE OF THIS SOFTWARE.
 
 AC_PREREQ(2.59)
-AC_INIT([Multiboot], [1.6], [bug-g...@gnu.org])
+AC_INIT([Multiboot], [2.0], [bug-g...@gnu.org])
 AC_CONFIG_SRCDIR([doc/multiboot.texi])
 AC_CONFIG_HEADER([config.h])
 AM_INIT_AUTOMAKE
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index a25c223..350937f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -20,7 +20,7 @@ Copyright @copyright{} 1995,96 Bryan Ford 

 
 Copyright @copyright{} 1995,96 Erich Stefan Boleyn 
 
-Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010 Free Software 
Foundation, Inc.
+Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010,2016 Free 
Software Foundation, Inc.
 
 @quotation
 Permission is granted to make and distribute verbatim copies of
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |   56 
 doc/multiboot2.h   |   24 ++
 2 files changed, 80 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 130176a..f1e0e09 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -359,6 +359,7 @@ executable header.
 * Console header tags::
 * Module alignment tag::
 * EFI boot services tag::
+* Relocatable header tag::
 
 @end menu
 
@@ -681,6 +682,47 @@ u32 | size = 8  |
 This tag indicates that payload supports starting without
 terminating boot services.
 
+@node Relocatable header tag
+@subsection Relocatable header tag
+
+@example
+@group
++---+
+u16 | type = 10 |
+u16 | flags |
+u32 | size = 24 |
+u32 | min_addr  |
+u32 | max_addr  |
+u32 | align |
+u32 | preference|
++---+
+@end group
+@end example
+
+This tag indicates that image is relocatable.
+
+The meaning of each field is as follows:
+
+@table @code
+@item min_addr
+Lowest possible physical address at which image should be loaded.
+Boot loader cannot load any part of image below this address.
+
+@item max_addr
+Highest possible physical address at which loaded image should end.
+Boot loader cannot load any part of image above this address.
+
+@item align
+Image alignment in memory, e.g. 4096 (know on many machines as page).
+
+@item preference
+It contains load address placement suggestion for boot loader.
+Boot loader should follow it. @samp{0} means none, @samp{1} means
+load image at lowest possible address but not lower than min_addr
+and @samp{2} means load image at highest possible address but not
+higher than max_addr.
+@end table
+
 @node Machine state
 @section MIPS machine state
 
@@ -1309,6 +1351,20 @@ u64 | pointer   |
 This tag contains pointer to EFI amd64 image handle.
 Usually it is boot loader image handle.
 
+@subsection Image load base physical address
+@example
+@group
++---+
+u32 | type = 21 |
+u32 | size = 12 |
+u32 | load_base_addr|
++---+
+@end group
+@end example
+
+This tag contains image load base physical address. It is
+provided only if image has relocatable header tag.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b85cb13..b181607 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -62,6 +62,7 @@
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
 #define MULTIBOOT_TAG_TYPE_EFI32_IH  19
 #define MULTIBOOT_TAG_TYPE_EFI64_IH  20
+#define MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR21
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -73,11 +74,16 @@
 #define MULTIBOOT_HEADER_TAG_EFI_BS7
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
+#define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
 #define MULTIBOOT_HEADER_TAG_OPTIONAL 1
 
+#define MULTIBOOT_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT_LOAD_PREFERENCE_HIGH 2
+
 #define MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
 #define MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
 
@@ -162,6 +168,17 @@ struct multiboot_header_tag_module_align
   multiboot_uint32_t size;
 };
 
+struct multiboot_header_tag_relocatable
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+  multiboot_uint32_t min_addr;
+  multiboot_uint32_t max_addr;
+  multiboot_uint32_t align;
+  multiboot_uint32_t preference;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
@@ -388,6 +405,13 @@ struct multiboot_tag_efi64_ih
   multiboot_uint64_t pointer;
 };
 
+struct multiboot_tag_load_base_addr
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t load_base_addr;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 05/10] multiboot2: Add description of EFI image handle tags

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |   28 
 doc/multiboot2.h   |   16 
 2 files changed, 44 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 1583b76..130176a 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1281,6 +1281,34 @@ u32 | size = 8  |
 
 This tag indicates ExitBootServices wasn't called
 
+@subsection EFI 32-bit image handle pointer
+@example
+@group
++---+
+u32 | type = 19 |
+u32 | size = 12 |
+u32 | pointer   |
++---+
+@end group
+@end example
+
+This tag contains pointer to EFI i386 image handle.
+Usually it is boot loader image handle.
+
+@subsection EFI 64-bit image handle pointer
+@example
+@group
++---+
+u32 | type = 20 |
+u32 | size = 16 |
+u64 | pointer   |
++---+
+@end group
+@end example
+
+This tag contains pointer to EFI amd64 image handle.
+Usually it is boot loader image handle.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index 240400d..b85cb13 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK   16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -372,6 +374,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 00/10] multiboot2: Update documentation

[Daniel Kiper]

Hi,

This patch series adds descriptions of multiboot2 protocol new
features and fixes some issues found here and there.

It applies to multiboot2 branch in GRUB2 git tree.

Daniel

PS Please apply my GRUB2 patches which add above mentioned
   features. They were posted at the of March.

 configure.ac   |2 +-
 doc/multiboot.texi |  255 
++---
 doc/multiboot2.h   |   42 
 3 files changed, 282 insertions(+), 17 deletions(-)

Daniel Kiper (10):
  multiboot2: Remove redundant if
  multiboot2: Clarify meaning of information request header tag
  multiboot2: Fix description of EFI boot services tag
  multiboot2: Add description of support for EFI boot services
  multiboot2: Add description of EFI image handle tags
  multiboot2: Add description of support for relocatable images
  multiboot2: Say that memory maps may not be available on EFI platforms
  multiboot2: Add C structure alignment and padding consideration section
  multiboot2: Add me to authors
  multiboot2: Bump version to 2.0


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 02/10] multiboot2: Clarify meaning of information request header tag

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |   20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 27e5a2f..a7e3584 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -443,15 +443,19 @@ u32[n]  | mbi_tag_types |
 @end group
 @end example
 
-@samp{mbi_tag_types} is an array of u32 each one representing an information
-request
-If this tag is present and @samp{optional} is set to @samp{0} information
-conveyed by requested tag types must be present. If bootloader is unable
-to supply this information it must fail with an error
+@samp{mbi_tag_types} is an array of u32 each one representing an information 
request.
 
-Note: it doesn't garantee that any tags of type @samp{mbi_tag_types} will
-actually be present. E.g. on a videoless system even if you requested tag
-@samp{8} no tags of type @samp{8} will be present in mbi.
+If this tag is present and @samp{optional} is set to @samp{0} bootloader must
+support (understand meaning of) requested tag(s) and be able to provide 
relevant
+information to image if it is available. If bootloader do not understand 
meaning
+of requested tag(s) it must fail with an error. However, if it support a given
+tag(s) but information conveyed by it/them is not available bootloader can do 
not
+provide requested tag(s) in Multiboot information structure and proceed 
further.
+
+Note: Above means that there is not guarantee that any tags of type 
@samp{mbi_tag_types}
+will actually be present. E.g. on a videoless system even if you requested tag 
@samp{8}
+and bootloader support it no tags of type @samp{8} will be present in Multiboot
+information structure.
 
 
 @node Address header tag
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 07/10] multiboot2: Say that memory maps may not be available on EFI platforms

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index f1e0e09..c81b2ea 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -927,6 +927,10 @@ possible value for lower memory is 640 kilobytes. The 
value returned for
 upper memory is maximally the address of the first upper memory hole
 minus 1 megabyte. It is not guaranteed to be this value.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI
+boot services are enabled and available for loaded image (EFI boot services
+not terminated tag exists in Multiboot information structure).
+
 @subsection BIOS Boot device
 @example
 @group
@@ -1078,6 +1082,10 @@ indicated a reserved area.
 The map provided is guaranteed to list all standard @sc{ram} that should
 be available for normal use. This type however includes the regions occupied 
by kernel, mbi, segments and modules. Kernel must take care not to overwrite 
these regions.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI
+boot services are enabled and available for loaded image (EFI boot services
+not terminated tag exists in Multiboot information structure).
+
 @subsection Boot loader name
 @example
 @group
@@ -1310,6 +1318,9 @@ u32 | descriptor version|
 
 This tag contains EFI memory map as per EFI specification.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI
+boot services are enabled and available for loaded image (EFI boot services
+not terminated tag exists in Multiboot information structure).
 
 @subsection EFI boot services not terminated
 @example
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 03/10] multiboot2: Fix description of EFI boot services tag

[Daniel Kiper]

Without this fix multiboot2 doc build fails. Additionally,
add missing full stop at the end of sentence.

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index a7e3584..e43df93 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -358,6 +358,7 @@ executable header.
 * Address header tag::   
 * Console header tags::
 * Module alignment tag::
+* EFI boot services tag::
 
 @end menu
 
@@ -608,8 +609,8 @@ u32 | size = 8  |
 
 If this tag is present modules must be page aligned.
 
-@node EFI boot services
-@subsection EFI boot services
+@node EFI boot services tag
+@subsection EFI boot services tag
 
 @example
 @group
@@ -622,7 +623,7 @@ u32 | size = 8  |
 @end example
 
 This tag indicates that payload supports starting without
-terminating boot services
+terminating boot services.
 
 @node Machine state
 @section MIPS machine state
-- 
1.7.10.4


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

[Xen-devel] [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |  108 +++-
 doc/multiboot2.h   |2 +
 2 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index e43df93..1583b76 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -534,6 +534,62 @@ The physical address to which the boot loader should jump 
in order to
 start running the operating system.
 @end table
 
+@subsection EFI i386 entry address tag of Multiboot header
+
+@example
+@group
++---+
+u16 | type = 8  |
+u16 | flags |
+u32 | size  |
+u_virt  | entry_addr|
++---+
+@end group
+@end example
+
+All of the address fields in this tag are physical addresses.
+The meaning of each is as follows:
+
+@table @code
+
+@item entry_addr
+The physical address to which the boot loader should jump in order to
+start running EFI i386 compatible operating system code.
+@end table
+
+This tag is taken into account only on EFI i386 platforms
+when Multiboot image header contains EFI boot services tag.
+Then entry point specified in ELF header and the entry address
+tag of Multiboot header are ignored.
+
+@subsection EFI amd64 entry address tag of Multiboot header
+
+@example
+@group
++---+
+u16 | type = 9  |
+u16 | flags |
+u32 | size  |
+u_virt  | entry_addr|
++---+
+@end group
+@end example
+
+All of the address fields in this tag are physical addresses.
+The meaning of each is as follows:
+
+@table @code
+
+@item entry_addr
+The physical address to which the boot loader should jump in order to
+start running EFI amd64 compatible operating system code.
+@end table
+
+This tag is taken into account only on EFI amd64 platforms
+when Multiboot image header contains EFI boot services tag.
+Then entry point specified in ELF header and the entry address
+tag of Multiboot header are ignored.
+
 @node Console header tags
 @subsection Flags tag
 
@@ -714,12 +770,60 @@ The OS image must leave interrupts disabled until it sets 
up its own
 
 On EFI system boot services must be terminated.
 
+@section EFI i386 machine state with boot services enabled
+
+When the boot loader invokes the 32-bit operating system on EFI i386
+platform and EFI boot services tag together with EFI i386 entry address
+tag are present in the image Multiboot header, the machine must have the
+following state:
+
+@table @samp
+@item EAX
+Must contain the magic value @samp{0x36d76289}; the presence of this
+value indicates to the operating system that it was loaded by a
+Multiboot-compliant boot loader (e.g. as opposed to another type of
+boot loader that the operating system can also be loaded from).
+
+@item EBX
+Must contain the 32-bit physical address of the Multiboot
+information structure provided by the boot loader (@pxref{Boot
+information format}).
+@end table
+
+All other processor registers, flag bits and state are set accordingly
+to Unified Extensible Firmware Interface Specification, Version 2.6,
+section 2.3.2, IA-32 Platforms, boot services.
+
+@section EFI amd64 machine state with boot services enabled
+
+When the boot loader invokes the 64-bit operating system on EFI amd64
+platform and EFI boot services tag together with EFI amd64 entry address
+tag are present in the image Multiboot header, the machine must have the
+following state:
+
+@table @samp
+@item RAX
+Must contain the magic value @samp{0x36d76289}; the presence of this
+value indicates to the operating system that it was loaded by a
+Multiboot-compliant boot loader (e.g. as opposed to another type of
+boot loader that the operating system can also be loaded from).
+
+@item RBX
+Must contain the 64-bit physical address of the Multiboot
+information structure provided by the boot loader (@pxref{Boot
+information format}).
+@end table
+
+All other processor registers, flag bits and state are set accordingly
+to Unified Extensible Firmware Interface Specification, Version 2.6,
+section 2.3.4, x64 Platforms, boot services.
+
 @node Boot information format
 @section Boot information
 @subsection Boot information format
 
-Upon entry to the operating system, the @code{EBX} register contains the
-physical address of a @dfn{Multiboot information} data structure,
+Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
+the physical address of a @dfn{Multiboot information} data structure,
 through which the boot loader communicates vital information to the
 operating system. The operating system can use or ignore any parts of
 the structure as it chooses; all information passed by the boot loader
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index 78337f5..240400d 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -69,6 +69,8 @@
 #define MULTIBOOT_HEADER_TAG_FRAMEBUFFER  5
 

[Xen-devel] [MULTIBOOT2 DOC PATCH 01/10] multiboot2: Remove redundant if

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 doc/multiboot.texi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 4b92918..27e5a2f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -425,7 +425,7 @@ u32 | size  |
 
 @samp{type} is divided into 2 parts. Lower contains an identifier of contents 
of the rest of the tag.
 @samp{size} contains the size of tag including header fields.
-If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set if 
bootloader may ignore this tag if it 
+If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set 
bootloader may ignore this tag if it 
 lacks relevant support.
 Tags are terminated by a tag of type @samp{0} and size @samp{8}.
 
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v7 03/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping (top level ones)

[Suravee Suthikulanit]

On 6/8/2016 9:54 AM, Jan Beulich wrote:

On 08.06.16 at 10:58,  wrote:

> From: Quan Xu 
>
> Signed-off-by: Quan Xu 
> Acked-by: Kevin Tian 
>
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Kevin Tian 
> CC: Feng Wu 
> CC: Jan Beulich 
> CC: Andrew Cooper 

CC: Suravee Suthikulpanit 



Acked-by: Suravee Suthikulpanit 

Thanks,
Suravee

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

Re: [Xen-devel] [PATCH v7 07/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending (top level ones)

[Suravee Suthikulanit]

On 6/8/2016 3:59 AM, Xu, Quan wrote:

From: Quan Xu 

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Liu Jinsong 
CC: Keir Fraser 
CC: Andrew Cooper 
CC: Suravee Suthikulpanit 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Kevin Tian 
CC: Feng Wu 

v7:
  1. return SAVED_ALL at the bottom of device_power_down(), instead
 of SAVED_NONE.
  2. drop the 'if ( error > 0 )', calling device_power_up(error)
 without any if().
  3. for vtd_suspend():
   - drop pointless initializer.
   - return 0 at the bottom to make obvious that no error path
 comes there.


Shouldn't the changes log for v7 probably go ...

---

... HERE instead so that we don't get this in the commit log.


For AMD part,
Acked-by: Suravee Suthikulpanit 

Thanks,
Suravee

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e2532e9207583a784132f69b974f4cdb5d3e56c6
baseline version:
 xen  372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5

Last test of basis95478  2016-06-09 15:03:17 Z0 days
Testing same since95480  2016-06-09 17:09:44 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Paulina Szubarczyk 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=e2532e9207583a784132f69b974f4cdb5d3e56c6
+ . ./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 
e2532e9207583a784132f69b974f4cdb5d3e56c6
+ branch=xen-unstable-smoke
+ revision=e2532e9207583a784132f69b974f4cdb5d3e56c6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xe2532e9207583a784132f69b974f4cdb5d3e56c6 = 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;

Re: [Xen-devel] [PATCH v7 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)

[Suravee Suthikulanit]

On 6/8/2016 9:43 AM, Jan Beulich wrote:

On 08.06.16 at 10:58,  wrote:

> From: Quan Xu 
>
> Signed-off-by: Quan Xu 
> Acked-by: Kevin Tian 

Reviewed-by: Jan Beulich 


Acked-by: Suravee Suthikulpanit 

Thanks,
Suravee


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

Re: [Xen-devel] [PATCH] x86/time: use correct (local) time stamp in constant-TSC calibration fast path

[Joao Martins]

[changing Dario address to citrix.com as it was bouncing for me ]

On 06/09/2016 04:52 PM, Jan Beulich wrote:
 On 09.06.16 at 17:00,  wrote:
>> On 06/09/2016 01:57 PM, Jan Beulich wrote:
>> On 09.06.16 at 14:11,  wrote:
>>> So in effect for the fast path the patch
>>> changes the situation from c->stime_local_stamp being effectively
>>> unused to c->stime_master_stamp being so. In the former case, if
>>> that really hadn't been a typo, deleting the write of that field from
>>> time_calibration_std_rendezvous() would have made sense, as
>>> get_s_time() certainly is more overhead than the simply memory
>>> read and write needed for keeping c->stime_master_stamp up to
>>> date (despite not being used).
>> I agree, but what I meant previously was more of a concern meaning: CPU 0 is 
>> doing an
>> expensive read_platform_time (e.g. HPET supposedly microseconds order, plus 
>> a
>> non-contented lock) to set stime_master_stamp that doesn't get used at all -
>> effectively not using the clocksource set initially at boot.
> 
> Yeah, there's likely some cleanup potential here, but of course we
> need to be pretty careful about not doing something that may be
> needed by some code paths but not others. But if you think you
> can help the situation without harming maintainability, feel free to
> go ahead.
> 
OK, Makes sense. I'll likely do already so of it on my related series.

>> What if verify_tsc_reliability clears out X86_FEATURE_TSC_RELIABLE when 
>> failing
>> the warp test? The calibration function is set early on right after 
>> interrupts are
>> enabled and the time warp check later on when all CPUs are up. So on 
>> problematic
>> platforms it's possible that std_rendezvous is used with a constant TSC but 
>> still
>> deemed unreliable. We still keep incrementing deltas at roughly about the 
>> same time,
>> but in effect with this change the stime_local_stamp would be TSC-only based 
>> thus
>> leading to warps with an unreliable TSC? And there's also the CPU 
>> hotplug/onlining
>> case that we once discussed.
> 
> I agree that we're likely in trouble in such a case. But for the
> moment I'd be glad if we could get the "normal" case work right.
> 
OK. Apologies for the noise, I was just pointing out things that I tried and 
some
also discussed here in the PVCLOCK_TSC_STABLE_BIT series, although didn't cross 
me
that Xen own idea of time could be a little broken. IMO adding another 
clocksource
for TSC would be more correct if we are only using TSC (and having its 
associated
limitations made aware/explicit to the user) rather then being on the back of 
another
clocksource in use. But it wouldn't cover the normal case :( unless set manually

NB: Guests on the other hand aren't affected since they take care of keeping the
latest stamp when different vCPUS slightly diverge.

Joao

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

[Xen-devel] [PATCH V9 3/3] arm/acpi: Add Server Base System Architecture UART support

[Shanker Donthineni]

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers, modem
control, DMA and hardware flow control features. So, extend the
driver probe() to handle SBSA interface and skip the accessing
PL011 registers that are not described in SBSA document
(ARM-DEN-0029 Version 3.0, 6 APPENDIX B: GENERIC UART).

Signed-off-by: Shanker Donthineni 
Reviewed-by: Julien Grall 
---
Changes sicne v8:
   Simplified condition 'if (spcr->interface_type == ACPI_DBG2_SBSA) || '.

Changes sicne v7:
   Moved comment 'To compatible with SBSA v2.x document, all accesses should be 
32-bit' from #2.

Changes since v3:
  Moved non-SBSA related changes to patches 1/3 and 2/3.

changes since v2:
  Edited commit text to include SBSA document version.
  Remove setting baudrate code completely as per Julien's suggestion.
  Support both the SBSA interface types ACPI_DBG2_SBSA & ACPI_DBG2_SBSA_32.
  Replace MIS references with combination of RIS & IMSC.

Changes since v1:
  Don't access UART registers that are not part of SBSA document.
  Move setting baudrate function to a separate function.

 xen/drivers/char/pl011.c | 54 ++--
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 7e19c4a..ab22f7f 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -41,6 +41,7 @@ static struct pl011 {
 /* struct timer timer; */
 /* unsigned int timeout_ms; */
 /* bool_t probing, intr_works; */
+bool sbsa;  /* ARM SBSA generic interface */
 } pl011_com = {0};
 
 /* These parity settings can be ORed directly into the LCR. */
@@ -50,6 +51,7 @@ static struct pl011 {
 #define PARITY_MARK  (PEN|SPS)
 #define PARITY_SPACE (PEN|EPS|SPS)
 
+/* SBSA v2.x document requires, all reads/writes must be 32-bit accesses */
 #define pl011_read(uart, off)   readl((uart)->regs + (off))
 #define pl011_write(uart, off,val)  writel((val), (uart)->regs + (off))
 
@@ -95,14 +97,17 @@ static void __init pl011_init_preirq(struct serial_port 
*port)
 /* No interrupts, please. */
 pl011_write(uart, IMSC, 0);
 
-/* Definitely no DMA */
-pl011_write(uart, DMACR, 0x0);
-
-/* This write must follow FBRD and IBRD writes. */
-pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
-| FEN
-| ((uart->stop_bits - 1) << 3)
-| uart->parity);
+if ( !uart->sbsa )
+{
+/* Definitely no DMA */
+pl011_write(uart, DMACR, 0x0);
+
+/* This write must follow FBRD and IBRD writes. */
+pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
+| FEN
+| ((uart->stop_bits - 1) << 3)
+| uart->parity);
+}
 /* Clear errors */
 pl011_write(uart, RSR, 0);
 
@@ -110,10 +115,13 @@ static void __init pl011_init_preirq(struct serial_port 
*port)
 pl011_write(uart, IMSC, 0);
 pl011_write(uart, ICR, ALLI);
 
-/* Enable the UART for RX and TX; keep RTS and DTR */
-cr = pl011_read(uart, CR);
-cr &= RTS | DTR;
-pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+if ( !uart->sbsa )
+{
+/* Enable the UART for RX and TX; keep RTS and DTR */
+cr = pl011_read(uart, CR);
+cr &= RTS | DTR;
+pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+}
 }
 
 static void __init pl011_init_postirq(struct serial_port *port)
@@ -215,7 +223,7 @@ static struct uart_driver __read_mostly pl011_driver = {
 .vuart_info   = pl011_vuart,
 };
 
-static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+static int __init pl011_uart_init(int irq, u64 addr, u64 size, bool sbsa)
 {
 struct pl011 *uart;
 
@@ -224,6 +232,7 @@ static int __init pl011_uart_init(int irq, u64 addr, u64 
size)
 uart->data_bits = 8;
 uart->parity= PARITY_NONE;
 uart->stop_bits = 1;
+uart->sbsa  = sbsa;
 
 uart->regs = ioremap_nocache(addr, size);
 if ( !uart->regs )
@@ -272,7 +281,7 @@ static int __init pl011_dt_uart_init(struct dt_device_node 
*dev,
 return -EINVAL;
 }
 
-res = pl011_uart_init(res, addr, size);
+res = pl011_uart_init(res, addr, size, false);
 if ( res < 0 )
 {
 printk("pl011: Unable to initialize\n");
@@ -303,6 +312,7 @@ static int __init pl011_acpi_uart_init(const void *data)
 acpi_status status;
 struct acpi_table_spcr *spcr = NULL;
 int res;
+bool sbsa;
 
 status = acpi_get_table(ACPI_SIG_SPCR, 0,
 (struct acpi_table_header **));
@@ -313,11 +323,14 @@ static int __init pl011_acpi_uart_init(const void *data)
 return -EINVAL;
 }
 
+sbsa = (spcr->interface_type == ACPI_DBG2_SBSA ||
+spcr->interface_type == ACPI_DBG2_SBSA_32);
+
 /* 

[Xen-devel] [PATCH V9 1/3] drivers/pl011: Don't configure baudrate

[Shanker Donthineni]

The default baud and clock_hz configuration parameters are hardcoded
(commit 60ff980995008caf) for Versatile Express. Other platforms,
these default values may not be valid and might cause problems by
programming registers IBRD and FBRD incorrectly.

So, removing driver logic that sets the baudrate to fix the problem.
The behavior is unchanged because the driver was already relying on
the boot firmware for setting the correct baudrate.

Signed-off-by: Shanker Donthineni 
Reviewed-by: Julien Grall 
---
Changes since v1:
  Edited commit text.

 xen/drivers/char/pl011.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 1212d5c..6a3c21b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -31,7 +31,7 @@
 #include 
 
 static struct pl011 {
-unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int data_bits, parity, stop_bits;
 unsigned int irq;
 void __iomem *regs;
 /* UART with IRQ line: interrupt-driven I/O. */
@@ -84,7 +84,6 @@ static void pl011_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
 static void __init pl011_init_preirq(struct serial_port *port)
 {
 struct pl011 *uart = port->uart;
-unsigned int divisor;
 unsigned int cr;
 
 /* No interrupts, please. */
@@ -93,22 +92,6 @@ static void __init pl011_init_preirq(struct serial_port 
*port)
 /* Definitely no DMA */
 pl011_write(uart, DMACR, 0x0);
 
-/* Line control and baud-rate generator. */
-if ( uart->baud != BAUD_AUTO )
-{
-/* Baud rate specified: program it into the divisor latch. */
-divisor = (uart->clock_hz << 2) / uart->baud; /* clk << 6 / bd << 4 */
-pl011_write(uart, FBRD, divisor & 0x3f);
-pl011_write(uart, IBRD, divisor >> 6);
-}
-else
-{
-/* Baud rate already set: read it out from the divisor latch. */
-divisor = (pl011_read(uart, IBRD) << 6) | (pl011_read(uart, FBRD));
-if (!divisor)
-panic("pl011: No Baud rate configured\n");
-uart->baud = (uart->clock_hz << 2) / divisor;
-}
 /* This write must follow FBRD and IBRD writes. */
 pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
 | FEN
@@ -232,8 +215,6 @@ static int __init pl011_uart_init(int irq, u64 addr, u64 
size)
 
 uart = _com;
 uart->irq   = irq;
-uart->clock_hz  = 0x16e3600;
-uart->baud  = BAUD_AUTO;
 uart->data_bits = 8;
 uart->parity= PARITY_NONE;
 uart->stop_bits = 1;
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

[Xen-devel] [PATCH V9 2/3] drivers/pl011: Use combination of UARTRIS and UARTMSC instead of UARTMIS

[Shanker Donthineni]

The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.

UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
 - 3.3.10 Interrupt mask set/clear register, UARTIMSC
 - 3.3.11 Raw interrupt status register, UARTRIS
 - 3.3.12 Masked interrupt status register, UARTMIS

This change is necessary for driver to be SBSA compliant v2.x without
affecting the current driver functionality.

Signed-off-by: Shanker Donthineni 
Reviewed-by: Julien Grall 
---
Changes since v8:
 Fixed white spaces.

Changes since v7:
 Moved comment 'To compatible with SBSA v2.x document, all accesses should be 
32-bit' to #3

Changes since v1:
 Added a new function to return an interrupt status.

 xen/drivers/char/pl011.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6a3c21b..7e19c4a 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -53,11 +53,17 @@ static struct pl011 {
 #define pl011_read(uart, off)   readl((uart)->regs + (off))
 #define pl011_write(uart, off,val)  writel((val), (uart)->regs + (off))
 
+static unsigned int pl011_intr_status(struct pl011 *uart)
+{
+/* UARTMIS is not documented in SBSA v2.x, so use UARTRIS/UARTIMSC. */
+return (pl011_read(uart, RIS) & pl011_read(uart, IMSC));
+}
+
 static void pl011_interrupt(int irq, void *data, struct cpu_user_regs *regs)
 {
 struct serial_port *port = data;
 struct pl011 *uart = port->uart;
-unsigned int status = pl011_read(uart, MIS);
+unsigned int status = pl011_intr_status(uart);
 
 if ( status )
 {
@@ -76,7 +82,7 @@ static void pl011_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
 if ( status & (TXI) )
 serial_tx_interrupt(port, regs);
 
-status = pl011_read(uart, MIS);
+status = pl011_intr_status(uart);
 } while (status != 0);
 }
 }
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Olaf Hering]

On Thu, Jun 09, Wei Liu wrote:

> On Thu, Jun 09, 2016 at 06:45:10PM +0200, Olaf Hering wrote:
> > On Thu, Jun 09, Konrad Rzeszutek Wilk wrote:
> > 
> > > Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> > > says otherwise is confusing to say at least.
> > 
> > > Cc: Olaf Hering 
> > 
> > Signed-off-by: Olaf Hering 
> > 
> 
> Hmm... I think you fat-fingered your tag.

Time to call it a day:

Acked-by: Olaf Hering 


Olaf

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

Re: [Xen-devel] [PATCH] xen-blkfront: export backend vdev name via sysfs

[Olaf Hering]

On Thu, Jun 09, David Vrabel wrote:

> Why don't you get the udev rule to read the xenstore key directly instead?

Good point. Something like this does indeed work:

c170:~ # cd -P /sys/block/xvda/device ; d=${PWD##*/} ; xenstore-read 
`xenstore-read device/${d/-/\/}/backend`/dev
hda
c170:/sys/devices/vbd-768 # 

Olaf

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

Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

On 06/09/2016 11:30 AM, Andrew Cooper wrote:

On 09/06/16 15:47, Daniel De Graaf wrote:

diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 4a264c2..6ffccb2 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
 return 0;
 }

+extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
+
+static void __init xsm_policy_init(void)
+{
+if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
+{
+policy_buffer = __xsm_init_policy_start;


I think this might cause a problem for ARM.

xsm_dt_init(void) does

ret = xsm_core_init();
xfree(policy_buffer);

which might now try freeing a piece of initdata.  Even going back to c/s
a8f2fb51c19 which introduced this code, I can't spot its justification.


The buffer is allocated and populated in xsm_dt_policy_init.


It also looks like the entire policy buffer can be const, at which point
it can be linked slightly higher in .init.data with the other
logically-const data.


Sure, although this will require quite a bit of const propagation down into
the FLASK security server (or casting it away).

--
Daniel De Graaf
National Security Agency

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5
baseline version:
 xen  e9151dbe35611778d70a1ad2698af60141ea0418

Last test of basis95475  2016-06-09 12:14:17 Z0 days
Testing same since95478  2016-06-09 15:03:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Len Brown 
  Tim Deegan 

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=372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5
+ . ./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 
372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5
+ branch=xen-unstable-smoke
+ revision=372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x372ad59dd0e7a3df0bd46ec3c8b934d739eb07b5 = 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();
  

Re: [Xen-devel] [PATCH 00/11] Honour XEN_{LOG, RUN}_DIR in various places

[Wei Liu]

On Thu, Jun 09, 2016 at 05:53:09PM +0100, Anthony PERARD wrote:
> There is also some /var/run hardcoded in here:
> tools/hotplug/Linux/systemd/xenstored.socket.in
> tools/hotplug/Linux/systemd/xenstored_ro.socket.in

Thanks. I will send out follow-up patches for that.

Wei.

> 
> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Wei Liu]

On Thu, Jun 09, 2016 at 06:45:10PM +0200, Olaf Hering wrote:
> On Thu, Jun 09, Konrad Rzeszutek Wilk wrote:
> 
> > Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> > says otherwise is confusing to say at least.
> 
> > Cc: Olaf Hering 
> 
> Signed-off-by: Olaf Hering 
> 

Hmm... I think you fat-fingered your tag.

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

Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

On 06/09/2016 12:15 PM, Jan Beulich wrote:

On 09.06.16 at 16:47,  wrote:

--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -132,6 +132,23 @@ config FLASK

  If unsure, say Y.

+config XSM_POLICY
+   bool "Compile Xen with a built-in security policy"
+   default y
+   depends on XSM
+   ---help---
+ This includes a default XSM policy in the hypervisor so that the
+ bootloader does not need to load a policy to get sane behavior from an
+ XSM-enabled hypervisor.  If this is disabled, a policy must be
+ provided by the bootloader or by Domain 0.  Even if this is enabled, a
+ policy provided by the bootloader will override it.
+
+ This requires that the SELinux policy compiler (checkpolicy) be
+ available when compiling the hypervisor; if this tool is not found, no
+ policy will be added.
+
+ If unsure, say Y.
+
 config FLASK_AVC_STATS
def_bool y
depends on FLASK


Placing this between FLASK and FLASK_AVC_STATS will break proper
menuconfig representation of the latter afaict.

Jan


This option isn't visible in menuconfig.  Should I make it visible?

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH 00/11] Honour XEN_{LOG, RUN}_DIR in various places

[Anthony PERARD]

There is also some /var/run hardcoded in here:
tools/hotplug/Linux/systemd/xenstored.socket.in
tools/hotplug/Linux/systemd/xenstored_ro.socket.in


-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] xen-blkfront: export backend vdev name via sysfs

[David Vrabel]

On 09/06/16 17:43, Olaf Hering wrote:
> From: Jeff Mahoney 
> 
> This patch creates a sysfs group to export blkfront attribute via sysfs.
> For now, we just export the backend device name.
> 
> This helps with migrating existing domU installation from a xenlinux
> based kernel to a pvops based kernel. The old blkfront driver did
> respect the vdev=hd|sd|xvd setting in domU.cfg, while the pvops blkfront
> driver enforce xvd as kernel device name.
> 
> If for some reason the domU uses kernel devices names in configuration
> files like fstab, menu.lst, grub.cfg etc. the system may not startup
> properly after upgrading from a dist version with xenlinux based kernel
> to a newer one with pvops based kernel. With the new sysfs attribute
> /sys/block/*/blkfront/backend_dev udev can create a symlink /dev/hda to
> /dev/xvda using rules as shown below.
> 
> The value of "vdev" is cached to avoid the load caused by constant
> rereading from the sysfs file.
> 
> This might be added to systemd/rules/60-persistent-storage.rules:
> KERNEL=="xvd*[!0-9]", ATTRS{blkfront/backend_dev}=="hd[a-d]", 
> SYMLINK+="$attr{blkfront/backend_dev}"
> KERNEL=="xvd*[0-9]",  ATTRS{blkfront/backend_dev}=="hd[a-d]", 
> SYMLINK+="$attr{blkfront/backend_dev}%n"

Why don't you get the udev rule to read the xenstore key directly instead?

David

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

Re: [Xen-devel] [PATCH] xen-blkfront: export backend vdev name via sysfs

[Olaf Hering]

On Thu, Jun 09, Olaf Hering wrote:

> The value of "vdev" is cached to avoid the load caused by constant
> rereading from the sysfs file.

For some reason I sent an earlier variant of the patch without caching.
If the approach is acceptable I will resend.

Olaf

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Olaf Hering]

On Thu, Jun 09, Konrad Rzeszutek Wilk wrote:

> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> says otherwise is confusing to say at least.

> Cc: Olaf Hering 

Signed-off-by: Olaf Hering 


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

[Xen-devel] [PATCH] xen-blkfront: export backend vdev name via sysfs

[Olaf Hering]

From: Jeff Mahoney 

This patch creates a sysfs group to export blkfront attribute via sysfs.
For now, we just export the backend device name.

This helps with migrating existing domU installation from a xenlinux
based kernel to a pvops based kernel. The old blkfront driver did
respect the vdev=hd|sd|xvd setting in domU.cfg, while the pvops blkfront
driver enforce xvd as kernel device name.

If for some reason the domU uses kernel devices names in configuration
files like fstab, menu.lst, grub.cfg etc. the system may not startup
properly after upgrading from a dist version with xenlinux based kernel
to a newer one with pvops based kernel. With the new sysfs attribute
/sys/block/*/blkfront/backend_dev udev can create a symlink /dev/hda to
/dev/xvda using rules as shown below.

The value of "vdev" is cached to avoid the load caused by constant
rereading from the sysfs file.

This might be added to systemd/rules/60-persistent-storage.rules:
KERNEL=="xvd*[!0-9]", ATTRS{blkfront/backend_dev}=="hd[a-d]", 
SYMLINK+="$attr{blkfront/backend_dev}"
KERNEL=="xvd*[0-9]",  ATTRS{blkfront/backend_dev}=="hd[a-d]", 
SYMLINK+="$attr{blkfront/backend_dev}%n"

Signed-off-by: Jeff Mahoney 
Signed-off-by: Olaf Hering 
---
 drivers/block/xen-blkfront.c | 61 
 1 file changed, 61 insertions(+)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 6405b65..3c12644 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1066,6 +1066,66 @@ static int xen_translate_vdev(int vdevice, int *minor, 
unsigned int *offset)
return 0;
 }
 
+/* xlvbd sysfs attributes */
+static ssize_t xlvbd_attr_show(struct device *dev, char *page,
+   ssize_t (*callback)(struct blkfront_info *, char *))
+{
+   struct gendisk *disk = dev_to_disk(dev);
+   struct blkfront_info *lo = disk->private_data;
+
+   return callback(lo, page);
+}
+
+#define XLVBD_ATTR_RO(_name)   \
+static ssize_t xlvbd_attr_##_name##_show(struct blkfront_info *, char *);\
+static ssize_t xlvbd_attr_do_show_##_name(struct device *d,\
+   struct device_attribute *attr, char *b) \
+{  \
+   return xlvbd_attr_show(d, b, xlvbd_attr_##_name##_show);\
+}  \
+static struct device_attribute xlvbd_attr_##_name =\
+   __ATTR(_name, S_IRUGO, xlvbd_attr_do_show_##_name, NULL);
+
+
+static ssize_t xlvbd_attr_backend_dev_show(struct blkfront_info *info,
+  char *buf)
+{
+   const char *nodename = info->xbdev->nodename;
+   const char *backend;
+   const char *dev;
+
+   backend = xenbus_read(XBT_NIL, nodename, "backend", NULL);
+   if (IS_ERR(backend))
+   return PTR_ERR(backend);
+
+   dev = xenbus_read(XBT_NIL, backend, "dev", NULL);
+   kfree(backend);
+   if (IS_ERR(dev))
+   return PTR_ERR(dev);
+
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", dev);
+
+   kfree(dev);
+   return ret;
+}
+
+XLVBD_ATTR_RO(backend_dev);
+
+static struct attribute *xlvbd_attrs[] = {
+   _attr_backend_dev.attr,
+   NULL,
+};
+
+static const struct attribute_group xlvbd_attribute_group = {
+   .name = "blkfront",
+   .attrs = xlvbd_attrs,
+};
+
+static const struct attribute_group *xlvbd_attribute_groups[] = {
+   _attribute_group,
+   NULL,
+};
+
 static char *encode_disk_name(char *ptr, unsigned int n)
 {
if (n >= 26)
@@ -1143,6 +1203,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
gd->private_data = info;
gd->driverfs_dev = &(info->xbdev->dev);
set_capacity(gd, capacity);
+   disk_to_dev(gd)->groups = xlvbd_attribute_groups;
 
if (xlvbd_init_blk_queue(gd, sector_size, physical_sector_size,
 info->max_indirect_segments ? :

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

Re: [Xen-devel] [PATCH 10/15] flask: remove xen_flask_userlist operation

[Daniel De Graaf]

On 06/09/2016 12:07 PM, Jan Beulich wrote:

On 09.06.16 at 16:47,  wrote:

--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -70,20 +70,6 @@ struct xen_flask_transition {
 uint32_t newsid;
 };

-struct xen_flask_userlist {
-/* IN: starting SID for list */
-uint32_t start_sid;
-/* IN: size of user string and output buffer
- * OUT: number of SIDs returned */
-uint32_t size;
-union {
-/* IN: user to enumerate SIDs */
-XEN_GUEST_HANDLE(char) user;
-/* OUT: SID list */
-XEN_GUEST_HANDLE(uint32) sids;
-} u;
-};


No known users or not, we don't normally allow breaking code that
may be consuming any of our public headers. I.e. conventionally,
for interfaces not restricted to the tool stack we keep everything,
but guard it with a __XEN_INTERFACE_VERSION__ conditional.

Whether making an exception here is okay I'm not certain; in any
event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.

Jan


OK, then I'll drop this patch.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

On 06/09/2016 12:11 PM, Jan Beulich wrote:

On 09.06.16 at 16:47,  wrote:

Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex.  Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and that can be placed in xsm_core.c.

Signed-off-by: Daniel De Graaf 


While I agree with the Kconfig change, it not being mentioned at
all in the description is confusing. Does it need to be part of this
patch? Or can it rather be a separate one with a proper description?

Jan


It does not need to be part of this patch; it just ended up here because
the other Kconfig changes that I made were not useful and got dropped.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH 08/15] flask: remove unused secondary context in ocontext

[Daniel De Graaf]

On 06/09/2016 12:01 PM, Jan Beulich wrote:

On 09.06.16 at 16:47,  wrote:

--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -158,8 +158,8 @@ struct ocontext {
 u64 high_iomem;
 } iomem;
 } u;
-struct context context[2];/* security context(s) */
-u32 sid[2];/* SID(s) */
+struct context context[1];/* security context(s) */
+u32 sid[1];/* SID(s) */


Is keeping them be arrays useful for anything?

Jan



No, it was just more code churn to convert them to fields.

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Wei Liu]

On Thu, Jun 09, 2016 at 05:27:30PM +0200, Olaf Hering wrote:
> On Thu, Jun 09, Konrad Rzeszutek Wilk wrote:
> 
> > Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> > says otherwise is confusing to say at least.
> 
> I'm fine with that. My changes to libvchan were just build fixes,
> nothing substantial.
> 

Can you give a formal ack so that it can be put into the commit log?
Thanks!

Wei.

> Olaf

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Anil Madhavapeddy]

> On 9 Jun 2016, at 17:34, Jason P Andryuk  wrote:
> 
> On Thu, Jun 09, 2016 at 11:16:10AM -0400, Daniel De Graaf wrote:
>> On 06/09/2016 10:21 AM, Konrad Rzeszutek Wilk wrote:
>>> As the xen/COPYING file says:
>>> "A few files are licensed under both GPL and a weaker BSD-style 
>>> license. This includes all files within the subdirectory 
>>> include/public, as described in include/public/COPYING. All such 
>>> files include the non-GPL license text as a source-code comment. 
>>> Although the license text refers generically to "the software", the 
>>> non-GPL license applies *only* to those source files that explicitly 
>>> include the non-GPL license text."
>>> 
>>> The libxenvchan.h is under xen/include/public/io directory and the 
>>> xen/include/public/COPYING says:
>>> 
>>> "XEN NOTICE
>>> ==
>>> 
>>> This copyright applies to all files within this subdirectory and its
>>> subdirectories:
>>>  include/public/*.h
>>>  include/public/hvm/*.h
>>>  include/public/io/*.h
>>> 
>>> The intention is that these files can be freely copied into the 
>>> source tree of an operating system when porting that OS to run on 
>>> Xen. Doing so does *not* cause the OS to become subject to the terms of the 
>>> GPL.
>>> 
>>> All other files in the Xen source distribution are covered by 
>>> version
>>> 2 of the GNU General Public License except where explicitly stated 
>>> otherwise within individual source files.
>>> "
>>> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file 
>>> says otherwise is confusing to say at least.
>>> 
>>> Upon consulting with the authors of libxenvchan they said:
>>> "FWIW Neither I, nor ITL staff (as author of original libvchan 
>>> library) have anything against converting it to the BSD-style licence."
>>> (Marek Marczykowski-Górecki,
>>> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
>>> so as such lets change it.
>>> 
>>> Signed-off-by: Konrad Rzeszutek Wilk 
>> 
>> Acked-by: Daniel De Graaf 
> 
> Acked-by: Jason Andryuk 

Acked-by: Anil Madhavapeddy >

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Jason P Andryuk]

On Thu, Jun 09, 2016 at 11:16:10AM -0400, Daniel De Graaf wrote:
> On 06/09/2016 10:21 AM, Konrad Rzeszutek Wilk wrote:
> > As the xen/COPYING file says:
> > "A few files are licensed under both GPL and a weaker BSD-style 
> > license. This includes all files within the subdirectory 
> > include/public, as described in include/public/COPYING. All such 
> > files include the non-GPL license text as a source-code comment. 
> > Although the license text refers generically to "the software", the 
> > non-GPL license applies *only* to those source files that explicitly 
> > include the non-GPL license text."
> > 
> > The libxenvchan.h is under xen/include/public/io directory and the 
> > xen/include/public/COPYING says:
> > 
> > "XEN NOTICE
> > ==
> > 
> > This copyright applies to all files within this subdirectory and its
> > subdirectories:
> >   include/public/*.h
> >   include/public/hvm/*.h
> >   include/public/io/*.h
> > 
> > The intention is that these files can be freely copied into the 
> > source tree of an operating system when porting that OS to run on 
> > Xen. Doing so does *not* cause the OS to become subject to the terms of the 
> > GPL.
> > 
> > All other files in the Xen source distribution are covered by 
> > version
> > 2 of the GNU General Public License except where explicitly stated 
> > otherwise within individual source files.
> > "
> > Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file 
> > says otherwise is confusing to say at least.
> > 
> > Upon consulting with the authors of libxenvchan they said:
> > "FWIW Neither I, nor ITL staff (as author of original libvchan 
> > library) have anything against converting it to the BSD-style licence."
> > (Marek Marczykowski-Górecki,
> > http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
> > so as such lets change it.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Acked-by: Daniel De Graaf 

Acked-by: Jason Andryuk 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC for-4.8 v2 4/7] xen/device-tree: Make dt_match_node match props

[Edgar E. Iglesias]

On Thu, Jun 09, 2016 at 05:23:33PM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> On 09/06/16 17:04, Edgar E. Iglesias wrote:
> >On Wed, Jun 08, 2016 at 09:44:51AM +0100, Julien Grall wrote:
> >>
> >>On 07/06/2016 21:43, Edgar E. Iglesias wrote:
> >>>On Mon, Jun 06, 2016 at 06:39:39PM +0100, Julien Grall wrote:
> On 03/06/16 14:29, Edgar E. Iglesias wrote:
> >>
> >>[...]
> >>
> >>>AFAIK, it's needed to instantiate the dynamically sized array of pointers.
> >>>Another option is to make __DT_MATCH_PROPS take the char ** pointer.
> >>>The descriptor declaration would instead of looking like this:
> >>>{
> >>>__DT_MATCH_COMPATIBLE("mmio-sram"),
> >>>__DT_MATCH_PROPS("no-memory-wc"),
> >>>.data = _device_rw,
> >>>},
> >>>
> >>>Look something like this:
> >>>
> >>>const char *props_no_mem_wc[] = { "no-memory-wc", NULL };
> >>>
> >>>
> >>>
> >>>{
> >>>__DT_MATCH_COMPATIBLE("mmio-sram"),
> >>>__DT_MATCH_PROPS(props_no_mem_wc),
> >>>.data = _device_rw,
> >>>},
> >>>
> >>>
> >>>Or do you have better suggestions?
> >>
> >>How about defining props with the type "const char *props[]"?
> >>
> >
> >That doesn't work for arrays of match descriptors (i.e you can't have arrays 
> >of variable sized objects)...
> 
> H... I would rather try to avoid the cast, but the other solution you
> suggested does not look appealing (i.e declare separately the properties).
> 
> However do you have a use case where checking multiple properties would be
> useful? If not, I would just handle one property for now.

No I don't. We can do one property for now. I'll change that for v3.

Thanks,
Edgar

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

Re: [Xen-devel] [PATCH 1/1] tools/livepatch: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Wei Liu]

On Fri, Jun 10, 2016 at 12:02:52AM +0800, Dongli Zhang wrote:
> Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> is true. Thus, it is not necessary to update "j" when "i ==
> ARRAY_SIZE(main_options)" is false.
> 
> Signed-off-by: Dongli Zhang 
> Reviewed-by: Konrad Rzeszutek Wilk 

Thanks, I've queued this up in my next batch.

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

Re: [Xen-devel] [RFC for-4.8 v2 4/7] xen/device-tree: Make dt_match_node match props

[Julien Grall]

Hi Edgar,

On 09/06/16 17:04, Edgar E. Iglesias wrote:

On Wed, Jun 08, 2016 at 09:44:51AM +0100, Julien Grall wrote:


On 07/06/2016 21:43, Edgar E. Iglesias wrote:

On Mon, Jun 06, 2016 at 06:39:39PM +0100, Julien Grall wrote:

On 03/06/16 14:29, Edgar E. Iglesias wrote:


[...]


AFAIK, it's needed to instantiate the dynamically sized array of pointers.
Another option is to make __DT_MATCH_PROPS take the char ** pointer.
The descriptor declaration would instead of looking like this:
{
__DT_MATCH_COMPATIBLE("mmio-sram"),
__DT_MATCH_PROPS("no-memory-wc"),
.data = _device_rw,
},

Look something like this:

const char *props_no_mem_wc[] = { "no-memory-wc", NULL };



{
__DT_MATCH_COMPATIBLE("mmio-sram"),
__DT_MATCH_PROPS(props_no_mem_wc),
.data = _device_rw,
},


Or do you have better suggestions?


How about defining props with the type "const char *props[]"?



That doesn't work for arrays of match descriptors (i.e you can't have arrays of 
variable sized objects)...


H... I would rather try to avoid the cast, but the other solution 
you suggested does not look appealing (i.e declare separately the 
properties).


However do you have a use case where checking multiple properties would 
be useful? If not, I would just handle one property for now.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("[PATCH for 4.7] libxenvchan: Change license of 
header from Lesser GPL v2.1 to BSD"):
> As the xen/COPYING file says:
> "A few files are licensed under both GPL and a weaker BSD-style
> license. This includes all files within the subdirectory
> include/public, as described in include/public/COPYING. All such files
> include the non-GPL license text as a source-code comment. Although
> the license text refers generically to "the software", the non-GPL
> license applies *only* to those source files that explicitly include
> the non-GPL license text."

I have spoken to my line manager.  I can confirm that Citrix is happy
with this proposed change.  So:

Acked-by: Ian Jackson 

This view from Citrix covers all contributions made to these files in
the course of Citrix's employees' employment, which I think is:

> Cc: Andrew Cooper 
> cc: George Dunlap 
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Roger Pau Monne 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 

Ian.

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

Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data

[Jan Beulich]

>>> On 09.06.16 at 16:47,  wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -132,6 +132,23 @@ config FLASK
>  
> If unsure, say Y.
>  
> +config XSM_POLICY
> + bool "Compile Xen with a built-in security policy"
> + default y
> + depends on XSM
> + ---help---
> +   This includes a default XSM policy in the hypervisor so that the
> +   bootloader does not need to load a policy to get sane behavior from an
> +   XSM-enabled hypervisor.  If this is disabled, a policy must be
> +   provided by the bootloader or by Domain 0.  Even if this is enabled, a
> +   policy provided by the bootloader will override it.
> +
> +   This requires that the SELinux policy compiler (checkpolicy) be
> +   available when compiling the hypervisor; if this tool is not found, no
> +   policy will be added.
> +
> +   If unsure, say Y.
> +
>  config FLASK_AVC_STATS
>   def_bool y
>   depends on FLASK

Placing this between FLASK and FLASK_AVC_STATS will break proper
menuconfig representation of the latter afaict.

Jan


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

Re: [Xen-devel] [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Jan Beulich]

>>> On 09.06.16 at 16:47,  wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.
> 
> Signed-off-by: Daniel De Graaf 

While I agree with the Kconfig change, it not being mentioned at
all in the description is confusing. Does it need to be part of this
patch? Or can it rather be a separate one with a proper description?

Jan


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

Re: [Xen-devel] [PATCH 10/15] flask: remove xen_flask_userlist operation

[Jan Beulich]

>>> On 09.06.16 at 16:47,  wrote:
> --- a/xen/include/public/xsm/flask_op.h
> +++ b/xen/include/public/xsm/flask_op.h
> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>  uint32_t newsid;
>  };
>  
> -struct xen_flask_userlist {
> -/* IN: starting SID for list */
> -uint32_t start_sid;
> -/* IN: size of user string and output buffer
> - * OUT: number of SIDs returned */
> -uint32_t size;
> -union {
> -/* IN: user to enumerate SIDs */
> -XEN_GUEST_HANDLE(char) user;
> -/* OUT: SID list */
> -XEN_GUEST_HANDLE(uint32) sids;
> -} u;
> -};

No known users or not, we don't normally allow breaking code that
may be consuming any of our public headers. I.e. conventionally,
for interfaces not restricted to the tool stack we keep everything,
but guard it with a __XEN_INTERFACE_VERSION__ conditional.

Whether making an exception here is okay I'm not certain; in any
event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.

Jan


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

Re: [Xen-devel] [RFC for-4.8 v2 4/7] xen/device-tree: Make dt_match_node match props

[Edgar E. Iglesias]

On Wed, Jun 08, 2016 at 09:44:51AM +0100, Julien Grall wrote:
> Hi Edgar,

Hi Julien,


> 
> On 07/06/2016 21:43, Edgar E. Iglesias wrote:
> >On Mon, Jun 06, 2016 at 06:39:39PM +0100, Julien Grall wrote:
> >>On 03/06/16 14:29, Edgar E. Iglesias wrote:
> 
> [...]
> 
> >AFAIK, it's needed to instantiate the dynamically sized array of pointers.
> >Another option is to make __DT_MATCH_PROPS take the char ** pointer.
> >The descriptor declaration would instead of looking like this:
> >{
> >__DT_MATCH_COMPATIBLE("mmio-sram"),
> >__DT_MATCH_PROPS("no-memory-wc"),
> >.data = _device_rw,
> >},
> >
> >Look something like this:
> >
> >const char *props_no_mem_wc[] = { "no-memory-wc", NULL };
> >
> >
> >
> >{
> >__DT_MATCH_COMPATIBLE("mmio-sram"),
> >__DT_MATCH_PROPS(props_no_mem_wc),
> >.data = _device_rw,
> >},
> >
> >
> >Or do you have better suggestions?
> 
> How about defining props with the type "const char *props[]"?
> 

That doesn't work for arrays of match descriptors (i.e you can't have arrays of 
variable sized objects)...

Cheers,
Edgar

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

[Xen-devel] [PATCH 1/1] tools/livepatch: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Dongli Zhang]

Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
is true. Thus, it is not necessary to update "j" when "i ==
ARRAY_SIZE(main_options)" is false.

Signed-off-by: Dongli Zhang 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 tools/misc/xen-livepatch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 28f339a..3162489 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -435,8 +435,7 @@ int main(int argc, char *argv[])
"'xen-livepatch help'\n", argv[1]);
 return 1;
 }
-} else
-j = ARRAY_SIZE(action_options);
+}
 
 xch = xc_interface_open(0,0,0);
 if ( !xch )
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 08/15] flask: remove unused secondary context in ocontext

[Jan Beulich]

>>> On 09.06.16 at 16:47,  wrote:
> --- a/xen/xsm/flask/ss/policydb.h
> +++ b/xen/xsm/flask/ss/policydb.h
> @@ -158,8 +158,8 @@ struct ocontext {
>  u64 high_iomem;
>  } iomem;
>  } u;
> -struct context context[2];/* security context(s) */
> -u32 sid[2];/* SID(s) */
> +struct context context[1];/* security context(s) */
> +u32 sid[1];/* SID(s) */

Is keeping them be arrays useful for anything?

Jan


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

Re: [Xen-devel] [GIT PULL] (stable/for-jens-4.7) Xen block fixes for v4.7

[Jens Axboe]

On 06/09/2016 07:34 AM, Konrad Rzeszutek Wilk wrote:

Hey Jens,

Please git pull in your 'for-4.7/drivers' the following
branch (based of your 'for-4.7/drivers):

  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.7

which has two fixes for a guest migrating from host that
has multi-queue to one without it (and vice-versa).


Pulled, thanks Konrad.

--
Jens Axboe


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

[Xen-devel] [PATCH] exec: Fix qemu_ram_block_from_host for Xen

[Anthony PERARD]

Since f615f39 (exec: remove ram_addr argument from
qemu_ram_block_from_host), migration under Xen is likely to fail, with a
SEGV of QEMU. But the commit only reveal a bug with the calculation of
the offset value in qemu_ram_block_from_host().

This patch calculates the offset from the ram_addr as
qemu_ram_addr_from_host() will later calculate the ram_addr from the
offset.

Signed-off-by: Anthony PERARD 
---
 exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/exec.c b/exec.c
index f2c9e37..f13106d 100644
--- a/exec.c
+++ b/exec.c
@@ -1935,7 +1935,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool 
round_offset,
 ram_addr = xen_ram_addr_from_mapcache(ptr);
 block = qemu_get_ram_block(ram_addr);
 if (block) {
-*offset = (host - block->host);
+*offset = ram_addr - block->offset;
 }
 rcu_read_unlock();
 return block;
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH for-4.7 1/1] xen/arm: Rename map_regions_rw_cache and use p2m.default_access

[Edgar E. Iglesias]

On Wed, Jun 08, 2016 at 10:36:19AM +0100, Stefano Stabellini wrote:
> On Wed, 8 Jun 2016, Julien Grall wrote:
> > Hi Wei,
> > 
> > On 08/06/2016 09:17, Wei Liu wrote:
> > > On Wed, Jun 08, 2016 at 02:15:27AM +0200, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias" 
> > > > 
> > > > Rename map_regions_rw_cache to map_regions_cache and make it use
> > > > p2m.default_access.
> > > > 
> > > > Suggested-by: Julien Grall 
> > > > Signed-off-by: Edgar E. Iglesias 
> > > 
> > > I don't think this is absolutely necessary for 4.7.
> > > 
> > > On the other hand, it is just straight renaming, which should be quite
> > > safe.
> > 
> > This patch does not only contain a renaming, it also contain a change to fix
> > the default memaccess attribute.
> > 
> > However, I don't see why we should rename the function to map_regions_cache
> > given this will always map the region Read-Write (p2m_mmio_direct prevents 
> > the
> > execution of the memory).
> > 
> > > If I can get an ack or review from maintainers and confirmation that it
> > > doesn't break ARM build within today, we can shovel this in; otherwise
> > > it needs to wait for next version of Xen.
> > 
> > I would wait for a backport here. Stefano, any opinions?
> 
> Indeed, I would also wait for a backport

OK, Sounds good. I'm travelling at the moment so it might take a couple of
weeks for me to get back to this.

Cheers,
Edgar

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

Re: [Xen-devel] [PATCH 11/11] oxenstored: honour XEN_{LOG, RUN}_DIR in oxenstored.conf

[Ian Jackson]

Wei Liu writes ("[PATCH 11/11] oxenstored: honour XEN_{LOG,RUN}_DIR in 
oxenstored.conf"):
> Generate oxenstored.conf with configure. This involves modifying
> tools/configure.ac and rerun autogen.sh.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: David Scott 

You should mention that autogen.sh should be rerun.

Acked-by: Ian Jackson 

> There are two hard-coded paths in logging.ml, but I'm not sure if
> generate an ocaml _Path module is the right thing to do.

I would be interested to hear Dave's opinion.

Ian.

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

Re: [Xen-devel] [PATCH 08/11] hotplug/Linux: honour XEN_LOG_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 08/11] hotplug/Linux: honour XEN_LOG_DIR"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 07/11] hotplug/FreeBSD: honour XEN_{LOG, RUN}_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 07/11] hotplug/FreeBSD: honour XEN_{LOG,RUN}_DIR"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] Run autogen.sh

[Wei Liu]

On Thu, Jun 09, 2016 at 04:45:15PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] Run autogen.sh"):
> > I'm waiting for Ian's reply to that thread. We haven't come to a
> > conclusion whether we should bump the number at the beginning of the
> > release.
> 
> For all the libraries whose version number is currently 4.7 I'm happy
> for them to be bumped now, and I think that woudl be a good idea.
> 

OK. I will prepare a patch for that.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH 04/11] xenconsoled: honour XEN_LOG_DIR and remove hard-coded path

[Ian Jackson]

Wei Liu writes ("[PATCH 04/11] xenconsoled: honour XEN_LOG_DIR and remove 
hard-coded path"):
> Make a _paths.h for xenconsoled as well and use that to generate a
> default path for log file directory.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] x86/time: use correct (local) time stamp in constant-TSC calibration fast path

[Jan Beulich]

>>> On 09.06.16 at 17:00,  wrote:
> On 06/09/2016 01:57 PM, Jan Beulich wrote:
> On 09.06.16 at 14:11,  wrote:
>> So in effect for the fast path the patch
>> changes the situation from c->stime_local_stamp being effectively
>> unused to c->stime_master_stamp being so. In the former case, if
>> that really hadn't been a typo, deleting the write of that field from
>> time_calibration_std_rendezvous() would have made sense, as
>> get_s_time() certainly is more overhead than the simply memory
>> read and write needed for keeping c->stime_master_stamp up to
>> date (despite not being used).
> I agree, but what I meant previously was more of a concern meaning: CPU 0 is 
> doing an
> expensive read_platform_time (e.g. HPET supposedly microseconds order, plus 
> a
> non-contented lock) to set stime_master_stamp that doesn't get used at all -
> effectively not using the clocksource set initially at boot.

Yeah, there's likely some cleanup potential here, but of course we
need to be pretty careful about not doing something that may be
needed by some code paths but not others. But if you think you
can help the situation without harming maintainability, feel free to
go ahead.

> What if verify_tsc_reliability clears out X86_FEATURE_TSC_RELIABLE when 
> failing
> the warp test? The calibration function is set early on right after 
> interrupts are
> enabled and the time warp check later on when all CPUs are up. So on 
> problematic
> platforms it's possible that std_rendezvous is used with a constant TSC but 
> still
> deemed unreliable. We still keep incrementing deltas at roughly about the 
> same time,
> but in effect with this change the stime_local_stamp would be TSC-only based 
> thus
> leading to warps with an unreliable TSC? And there's also the CPU 
> hotplug/onlining
> case that we once discussed.

I agree that we're likely in trouble in such a case. But for the
moment I'd be glad if we could get the "normal" case work right.

Jan


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

Re: [Xen-devel] [PATCH 10/11] libxl: honour XEN_LOG_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 10/11] libxl: honour XEN_LOG_DIR"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] Run autogen.sh

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH] Run autogen.sh"):
> I'm waiting for Ian's reply to that thread. We haven't come to a
> conclusion whether we should bump the number at the beginning of the
> release.

For all the libraries whose version number is currently 4.7 I'm happy
for them to be bumped now, and I think that woudl be a good idea.

Ian.

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

Re: [Xen-devel] [PATCH 02/11] docs: use XEN_LOG_DIR in log file location

[Wei Liu]

On Thu, Jun 09, 2016 at 04:47:17PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 02/11] docs: use XEN_LOG_DIR in log file location"):
> > Signed-off-by: Wei Liu 
> ...
> > diff --git a/docs/misc/hvm-emulated-unplug.markdown 
> > b/docs/misc/hvm-emulated-unplug.markdown
> > index c6d1f9b..89fe14b 100644
> > --- a/docs/misc/hvm-emulated-unplug.markdown
> > +++ b/docs/misc/hvm-emulated-unplug.markdown
> > @@ -45,7 +45,7 @@ drivers):
> >  
> >  Once the drivers have checked the magic number, they can send log
> >  messages to qemu which will be logged to wherever qemu's logs go
> > -(`/var/log/xen/qemu-dm.log` on normal Xen, dom0 syslog on XenServer).
> > +(`$XEN_LOG_DIR/qemu-dm.log` on normal Xen, dom0 syslog on XenServer).
> >  These messages are written to IO port `0x12` a byte at a time, and are
> >  terminated by newlines.  There's a fairly aggressive rate limiter on
> >  these messages, so they shouldn't be used for anything even vaguely
> 
> I'm not a big fan of this kind of abstracted-away documentation.  (I
> think writing this in the markdown does not cause substitution.)  IMO
> it's better to have a concrete path which is right in almost all
> cases, even if it is sometimes wrong.

Correct, it is not substituted.

I will drop this one.

Wei.

> 
> Ian.

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("[PATCH for 4.7] libxenvchan: Change license of 
header from Lesser GPL v2.1 to BSD"):
> As the xen/COPYING file says:
> "A few files are licensed under both GPL and a weaker BSD-style
> license. This includes all files within the subdirectory
> include/public, as described in include/public/COPYING. All such files
> include the non-GPL license text as a source-code comment. Although
> the license text refers generically to "the software", the non-GPL
> license applies *only* to those source files that explicitly include
> the non-GPL license text."

I personally think this patch is a good idea.

I am going to get confirmation from management at Citrix and then
hopefully I will be able to (very soon) give an ack on behalf of all
the Citrix staff.

Ian.

(Changed ijc's email address.)

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

Re: [Xen-devel] [PATCH 09/11] hotplug/NetBSD: honour XEN_{LOG, RUN}_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 09/11] hotplug/NetBSD: honour XEN_{LOG,RUN}_DIR"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v4 1/7] xl_cmdimpl - Add return codes for pci-detach, pci-attach, pci-asssignable-add, and pci-assignable-remove.

[Wei Liu]

On Thu, Jun 09, 2016 at 04:53:29PM +0200, Paulina Szubarczyk wrote:
> On Thu, 2016-06-09 at 15:44 +0100, Wei Liu wrote:
> > Hi Paulina
> > 
> > I was about to push this whole series, but I noticed the subject line
> > of this patch is very long.
> > 
> > May I make a suggestion that we update the title of this patch to
> > 
> >   xl: add return codes for various pci functions
> > 
> > ?
> > 
> > If you agree I will do the modification and push it to staging.
> 
> Hi Wei, 
> 
> yes, I do agree on the suggested title. Thank you.
> 

Thanks for your confirmation. Now your series has been pushed to
staging.

Wei.

> Paulina
> 
> 

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

Re: [Xen-devel] [PATCH 05/11] xenbackendd: honour XEN_{RUN, LOG}_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 05/11] xenbackendd: honour XEN_{RUN,LOG}_DIR"):
> Also added a gitignore entry for xenbackendd binary while I was there.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 02/11] docs: use XEN_LOG_DIR in log file location

[Ian Jackson]

Wei Liu writes ("[PATCH 02/11] docs: use XEN_LOG_DIR in log file location"):
> Signed-off-by: Wei Liu 
...
> diff --git a/docs/misc/hvm-emulated-unplug.markdown 
> b/docs/misc/hvm-emulated-unplug.markdown
> index c6d1f9b..89fe14b 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -45,7 +45,7 @@ drivers):
>  
>  Once the drivers have checked the magic number, they can send log
>  messages to qemu which will be logged to wherever qemu's logs go
> -(`/var/log/xen/qemu-dm.log` on normal Xen, dom0 syslog on XenServer).
> +(`$XEN_LOG_DIR/qemu-dm.log` on normal Xen, dom0 syslog on XenServer).
>  These messages are written to IO port `0x12` a byte at a time, and are
>  terminated by newlines.  There's a fairly aggressive rate limiter on
>  these messages, so they shouldn't be used for anything even vaguely

I'm not a big fan of this kind of abstracted-away documentation.  (I
think writing this in the markdown does not cause substitution.)  IMO
it's better to have a concrete path which is right in almost all
cases, even if it is sometimes wrong.

Ian.

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

Re: [Xen-devel] [PATCH 03/11] tools: install XEN_{LOG,RUN}_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH 03/11] tools: install XEN_{LOG,RUN}_DIR"):
> Signed-off-by: Wei Liu 
> ---

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 01/11] Config.mk: add XEN_LOG_DIR to BUILD_MAKE_VARS

[Ian Jackson]

Wei Liu writes ("[PATCH 01/11] Config.mk: add XEN_LOG_DIR to BUILD_MAKE_VARS"):
> ... so that it can be turned into shell environment and exported to
> header files.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Andrew Cooper]

On 09/06/16 15:21, Konrad Rzeszutek Wilk wrote:
> As the xen/COPYING file says:
> "A few files are licensed under both GPL and a weaker BSD-style
> license. This includes all files within the subdirectory
> include/public, as described in include/public/COPYING. All such files
> include the non-GPL license text as a source-code comment. Although
> the license text refers generically to "the software", the non-GPL
> license applies *only* to those source files that explicitly include
> the non-GPL license text."
>
> The libxenvchan.h is under xen/include/public/io directory
> and the xen/include/public/COPYING says:
>
> "XEN NOTICE
> ==
>
> This copyright applies to all files within this subdirectory and its
> subdirectories:
>   include/public/*.h
>   include/public/hvm/*.h
>   include/public/io/*.h
>
> The intention is that these files can be freely copied into the source
> tree of an operating system when porting that OS to run on Xen. Doing
> so does *not* cause the OS to become subject to the terms of the GPL.
>
> All other files in the Xen source distribution are covered by version
> 2 of the GNU General Public License except where explicitly stated
> otherwise within individual source files.
> "
> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> says otherwise is confusing to say at least.
>
> Upon consulting with the authors of libxenvchan they said:
> "FWIW Neither I, nor ITL staff (as author of original libvchan library)
> have anything against converting it to the BSD-style licence."
> (Marek Marczykowski-Górecki,
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
> so as such lets change it.
>
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Roger Pau Monné]

On Thu, Jun 09, 2016 at 10:21:03AM -0400, Konrad Rzeszutek Wilk wrote:
> As the xen/COPYING file says:
> "A few files are licensed under both GPL and a weaker BSD-style
> license. This includes all files within the subdirectory
> include/public, as described in include/public/COPYING. All such files
> include the non-GPL license text as a source-code comment. Although
> the license text refers generically to "the software", the non-GPL
> license applies *only* to those source files that explicitly include
> the non-GPL license text."
> 
> The libxenvchan.h is under xen/include/public/io directory
> and the xen/include/public/COPYING says:
> 
> "XEN NOTICE
> ==
> 
> This copyright applies to all files within this subdirectory and its
> subdirectories:
>   include/public/*.h
>   include/public/hvm/*.h
>   include/public/io/*.h
> 
> The intention is that these files can be freely copied into the source
> tree of an operating system when porting that OS to run on Xen. Doing
> so does *not* cause the OS to become subject to the terms of the GPL.
> 
> All other files in the Xen source distribution are covered by version
> 2 of the GNU General Public License except where explicitly stated
> otherwise within individual source files.
> "
> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> says otherwise is confusing to say at least.
> 
> Upon consulting with the authors of libxenvchan they said:
> "FWIW Neither I, nor ITL staff (as author of original libvchan library)
> have anything against converting it to the BSD-style licence."
> (Marek Marczykowski-Górecki,
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
> so as such lets change it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked-by: Roger Pau Monne 

Roger.

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[George Dunlap]

On 09/06/16 15:21, Konrad Rzeszutek Wilk wrote:
> As the xen/COPYING file says:
> "A few files are licensed under both GPL and a weaker BSD-style
> license. This includes all files within the subdirectory
> include/public, as described in include/public/COPYING. All such files
> include the non-GPL license text as a source-code comment. Although
> the license text refers generically to "the software", the non-GPL
> license applies *only* to those source files that explicitly include
> the non-GPL license text."
> 
> The libxenvchan.h is under xen/include/public/io directory
> and the xen/include/public/COPYING says:
> 
> "XEN NOTICE
> ==
> 
> This copyright applies to all files within this subdirectory and its
> subdirectories:
>   include/public/*.h
>   include/public/hvm/*.h
>   include/public/io/*.h
> 
> The intention is that these files can be freely copied into the source
> tree of an operating system when porting that OS to run on Xen. Doing
> so does *not* cause the OS to become subject to the terms of the GPL.
> 
> All other files in the Xen source distribution are covered by version
> 2 of the GNU General Public License except where explicitly stated
> otherwise within individual source files.
> "
> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> says otherwise is confusing to say at least.
> 
> Upon consulting with the authors of libxenvchan they said:
> "FWIW Neither I, nor ITL staff (as author of original libvchan library)
> have anything against converting it to the BSD-style licence."
> (Marek Marczykowski-Górecki,
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
> so as such lets change it.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> 
> ---
> Cc: Andrew Cooper 
> Cc: Anil Madhavapeddy 
> Cc: Daniel De Graaf 
> cc: George Dunlap 

To whatever extent it's helpful:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH V8 3/3] arm/acpi: Add Server Base System Architecture UART support

[Julien Grall]

On 09/06/16 16:26, Shanker Donthineni wrote:

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index a2f929b..d70ec99 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -41,6 +41,7 @@ static struct pl011 {
  /* struct timer timer; */
  /* unsigned int timeout_ms; */
  /* bool_t probing, intr_works; */
+bool sbsa;  /* ARM SBSA generic interface */
  } pl011_com = {0};

  /* These parity settings can be ORed directly into the LCR. */
@@ -50,6 +51,7 @@ static struct pl011 {
  #define PARITY_MARK  (PEN|SPS)
  #define PARITY_SPACE (PEN|EPS|SPS)

+/* To compatible with SBSA v2.x document, all accesses should be
32-bit */


The verb is missing. Also please add a full stop at the end of the
comment.


  #define pl011_read(uart, off) readl((uart)->regs + (off))
  #define pl011_write(uart, off,val)  writel((val), (uart)->regs
+ (off))



[...]


Sorry, I didn't understand what is [...]?


It used to show that I dropped some part of your mail in my reply.


@@ -313,11 +323,15 @@ static int __init pl011_acpi_uart_init(const
void *data)
  return -EINVAL;
  }

+if ( (spcr->interface_type == ACPI_DBG2_SBSA) ||
+ (spcr->interface_type == ACPI_DBG2_SBSA_32) )
+sbsa = true;


I thought I already mentioned this on a previous version:

sbsa = (spcr->interface_type == ACPI_DBG2_SBSA || ...);


You want me change to

sbsa = (spcr->interface_type == ACPI_DBG2_SBSA || spcr->interface_type
== ACPI_DBG2_SBSA_32)

right?


Yes please.

--
Julien Grall

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

Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 4a264c2..6ffccb2 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
>  return 0;
>  }
>  
> +extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
> +
> +static void __init xsm_policy_init(void)
> +{
> +if ( policy_size == 0 && __xsm_init_policy_end != 
> __xsm_init_policy_start )
> +{
> +policy_buffer = __xsm_init_policy_start;

I think this might cause a problem for ARM.

xsm_dt_init(void) does

ret = xsm_core_init();
xfree(policy_buffer);

which might now try freeing a piece of initdata.  Even going back to c/s
a8f2fb51c19 which introduced this code, I can't spot its justification.


It also looks like the entire policy buffer can be const, at which point
it can be linked slightly higher in .init.data with the other
logically-const data.

~Andrew

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Olaf Hering]

On Thu, Jun 09, Konrad Rzeszutek Wilk wrote:

> Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> says otherwise is confusing to say at least.

I'm fine with that. My changes to libvchan were just build fixes,
nothing substantial.

Olaf

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

Re: [Xen-devel] [PATCH V8 2/3] drivers/pl011: Use combination of UARTRIS and UARTMSC instead of UARTMIS

[Shanker Donthineni]

On 06/09/2016 05:15 AM, Julien Grall wrote:

Hello Shanker,

On 08/06/16 14:28, Shanker Donthineni wrote:

The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.

UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
  - 3.3.10 Interrupt mask set/clear register, UARTIMSC
  - 3.3.11 Raw interrupt status register, UARTRIS
  - 3.3.12 Masked interrupt status register, UARTMIS

This change is necessary for driver to be SBSA compliant v2.x without
affecting the current driver functionality.

Signed-off-by: Shanker Donthineni 
---
Changes since v7:
  Moved comment 'To compatible with SBSA v2.x document, all accesses 
should be 32-bit' to #3


Changes since v1:
  Added a new function to return an interrupt status.

  xen/drivers/char/pl011.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6a3c21b..a2f929b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -53,11 +53,17 @@ static struct pl011 {
  #define pl011_read(uart, off)   readl((uart)->regs + (off))
  #define pl011_write(uart, off,val)  writel((val), (uart)->regs 
+ (off))


+static unsigned int pl011_intr_status(struct pl011 *uart)
+{
+/* UARTMIS is not documented in SBSA v2.x, so using 
UARTRIS/UARTIMSC */


s/so using/so use/

Also missing full stop at the end of the comment.


I'll fix.

+return ( pl011_read(uart, RIS) & pl011_read(uart, IMSC) );


No space after the first parenthesis and before the last one.


I'll fix.

With these changes:

Reviewed-by: Julien Grall 

Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH V8 3/3] arm/acpi: Add Server Base System Architecture UART support

[Shanker Donthineni]

On 06/09/2016 05:19 AM, Julien Grall wrote:

Hello Shanker,

On 08/06/16 14:28, Shanker Donthineni wrote:

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers, modem
control, DMA and hardware flow control features. So, extend the
driver probe() to handle SBSA interface and skip the accessing
PL011 registers that are not described in SBSA document
(ARM-DEN-0029 Version 3.0, 6 APPENDIX B: GENERIC UART).

Signed-off-by: Shanker Donthineni 
Reviewed-by: Julien Grall 
---
Changes sicne v7:
Moved comment 'To compatible with SBSA v2.x document, all 
accesses should be 32-bit' from #2


Changes since v3:
   Moved non-SBSA related changes to patches 1/3 and 2/3.

changes since v2:
   Edited commit text to include SBSA document version.
   Remove setting baudrate code completely as per Julien's suggestion.
   Support both the SBSA interface types ACPI_DBG2_SBSA & 
ACPI_DBG2_SBSA_32.

   Replace MIS references with combination of RIS & IMSC.

Changes since v1:
   Don't access UART registers that are not part of SBSA document.
   Move setting baudrate function to a separate function.

  xen/drivers/char/pl011.c | 55 
+++-

  1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index a2f929b..d70ec99 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -41,6 +41,7 @@ static struct pl011 {
  /* struct timer timer; */
  /* unsigned int timeout_ms; */
  /* bool_t probing, intr_works; */
+bool sbsa;  /* ARM SBSA generic interface */
  } pl011_com = {0};

  /* These parity settings can be ORed directly into the LCR. */
@@ -50,6 +51,7 @@ static struct pl011 {
  #define PARITY_MARK  (PEN|SPS)
  #define PARITY_SPACE (PEN|EPS|SPS)

+/* To compatible with SBSA v2.x document, all accesses should be 
32-bit */


The verb is missing. Also please add a full stop at the end of the 
comment.



  #define pl011_read(uart, off) readl((uart)->regs + (off))
  #define pl011_write(uart, off,val)  writel((val), (uart)->regs 
+ (off))




[...]


Sorry, I didn't understand what is [...]?
@@ -313,11 +323,15 @@ static int __init pl011_acpi_uart_init(const 
void *data)

  return -EINVAL;
  }

+if ( (spcr->interface_type == ACPI_DBG2_SBSA) ||
+ (spcr->interface_type == ACPI_DBG2_SBSA_32) )
+sbsa = true;


I thought I already mentioned this on a previous version:

sbsa = (spcr->interface_type == ACPI_DBG2_SBSA || ...);


You want me change to

sbsa = (spcr->interface_type == ACPI_DBG2_SBSA || spcr->interface_type 
== ACPI_DBG2_SBSA_32)


right?

Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

[Xen-devel] [xen-4.5-testing bisection] complete test-amd64-i386-qemut-rhel6hvm-intel

[osstest service owner]

branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-amd64-i386-qemut-rhel6hvm-intel
testid guest-start/redhat.repeat

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:  c7e9c4b1231effdc1283d9a4a2645e395adb01d5
  Bug not present: 2388be01dffb8a3aae85ea58052f6020057ae3bc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/95477/


  commit c7e9c4b1231effdc1283d9a4a2645e395adb01d5
  Author: Ian Jackson 
  Date:   Fri Apr 29 16:23:35 2016 +0100
  
  libxl: Do not trust backend for disk eject vdev
  
  For disk eject, use configured vdev from /libxl, not backend.
  
  The backend directory is writeable by driver domains.  This means that
  a malicious driver domain could cause libxl to see a wrong vdev,
  confusing the user or the toolstack.
  
  Use the vdev from the /libxl space, rather than the backend.
  
  For convenience, we read the vdev from the /libxl space into the evg
  during setup and copy it on each event, rather than reading it afresh
  each time (which would in any case involve generating or saving a copy
  of the relevant /libxl path).
  
  This is part of XSA-178.
  
  Signed-off-by: Ian Jackson 
  Reviewed-by: Wei Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-amd64-i386-qemut-rhel6hvm-intel.guest-start--redhat.repeat.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.5-testing/test-amd64-i386-qemut-rhel6hvm-intel.guest-start--redhat.repeat
 --summary-out=tmp/95477.bisection-summary --basis-template=95290 
--blessings=real,real-bisect xen-4.5-testing 
test-amd64-i386-qemut-rhel6hvm-intel guest-start/redhat.repeat
Searching for failure / basis pass:
 95368 fail [host=baroque1] / 95290 [host=huxelrebe1] 95267 [host=elbling0] 
95250 [host=huxelrebe0] 94855 [host=elbling1] 94838 [host=italia1] 94707 
[host=chardonnay0] 94670 [host=chardonnay1] 94570 [host=huxelrebe0] 94543 
[host=italia1] 94518 [host=huxelrebe1] 94499 [host=fiano0] 94488 
[host=baroque0] 94469 [host=italia0] 94448 [host=huxelrebe0] 94384 ok.
Failure / basis pass flights: 95368 / 94384
(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 f06cb456a442c7df95a4ba6e2f3a341cf925d7cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f1cfdc3daeaf47c67f15bfb67d9327e156060f1b 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
d8ac67eff778ae0c6b3286ab46328be5c6c90163
Basis pass 1c767107ef341cdc080d44d3ee1c9ca1b6957ce0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f1cfdc3daeaf47c67f15bfb67d9327e156060f1b 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
1334fa937ad269e9f476fc6a69fd895f5fc99864
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#1c767107ef341cdc080d44d3ee1c9ca1b6957ce0-f06cb456a442c7df95a4ba6e2f3a341cf925d7cf
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#f1cfdc3daeaf47c67f15bfb67d9327e156060f1b-f1cfdc3daeaf47c67f15bfb67d9327e156060f1b
 
git://xenbits.xen.org/qemu-xen.git#63d6eab2fda43e9cfdaa33e9ffde755da8e98e32-63d6eab2fda43e9cfdaa33e9ffde755da8e98e32
 
git://xenbits.xen.org/xen.git#1334fa937ad269e9f476fc6a69fd895f5fc99864-d8ac67eff778ae0c6b3286ab46328be5c6c90163
Loaded 2001 nodes in revision graph
Searching for test results:
 94030 [host=chardonnay0]
 94079 [host=elbling0]
 94135 [host=elbling1]
 94290 [host=fiano1]
 94384 pass 1c767107ef341cdc080d44d3ee1c9ca1b6957ce0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f1cfdc3daeaf47c67f15bfb67d9327e156060f1b 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
1334fa937ad269e9f476fc6a69fd895f5fc99864
 94469 [host=italia0]
 94448 [host=huxelrebe0]
 94488 [host=baroque0]
 94499 [host=fiano0]
 94543 [host=italia1]
 94518 [host=huxelrebe1]
 94570 [host=huxelrebe0]
 94670 [host=chardonnay1]
 94707 [host=chardonnay0]
 94838 [host=italia1]
 94855 [host=elbling1]
 95250 [host=huxelrebe0]
 95267 [host=elbling0]
 95290 [host=huxelrebe1]
 95367 pass 1c767107ef341cdc080d44d3ee1c9ca1b6957ce0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Marek Marczykowski-Górecki]

On Thu, Jun 09, 2016 at 11:16:10AM -0400, Daniel De Graaf wrote:
> On 06/09/2016 10:21 AM, Konrad Rzeszutek Wilk wrote:
> > As the xen/COPYING file says:
> > "A few files are licensed under both GPL and a weaker BSD-style
> > license. This includes all files within the subdirectory
> > include/public, as described in include/public/COPYING. All such files
> > include the non-GPL license text as a source-code comment. Although
> > the license text refers generically to "the software", the non-GPL
> > license applies *only* to those source files that explicitly include
> > the non-GPL license text."
> > 
> > The libxenvchan.h is under xen/include/public/io directory
> > and the xen/include/public/COPYING says:
> > 
> > "XEN NOTICE
> > ==
> > 
> > This copyright applies to all files within this subdirectory and its
> > subdirectories:
> >   include/public/*.h
> >   include/public/hvm/*.h
> >   include/public/io/*.h
> > 
> > The intention is that these files can be freely copied into the source
> > tree of an operating system when porting that OS to run on Xen. Doing
> > so does *not* cause the OS to become subject to the terms of the GPL.
> > 
> > All other files in the Xen source distribution are covered by version
> > 2 of the GNU General Public License except where explicitly stated
> > otherwise within individual source files.
> > "
> > Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
> > says otherwise is confusing to say at least.
> > 
> > Upon consulting with the authors of libxenvchan they said:
> > "FWIW Neither I, nor ITL staff (as author of original libvchan library)
> > have anything against converting it to the BSD-style licence."
> > (Marek Marczykowski-Górecki,
> > http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
> > so as such lets change it.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Acked-by: Daniel De Graaf 

Acked-by: Marek Marczykowski-Górecki 

-- 
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?


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

Re: [Xen-devel] [PATCH 1/1] tools/xsplice: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Wei Liu]

On Mon, May 30, 2016 at 09:46:02AM +0800, Dongli Zhang wrote:
> Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> is true. Thus, it is not necessary to update "j" when "i ==
> ARRAY_SIZE(main_options)" is false.
> 
> Signed-off-by: Dongli Zhang 
> ---
>  tools/misc/xen-xsplice.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> index ddaa079..811dc57 100644
> --- a/tools/misc/xen-xsplice.c
> +++ b/tools/misc/xen-xsplice.c
> @@ -435,8 +435,7 @@ int main(int argc, char *argv[])
> "'xen-xsplice help'\n", argv[1]);
>  return 1;
>  }
> -} else
> -j = ARRAY_SIZE(action_options);
> +}
>  

And of course since xsplice doesn't exist anymore, this patch won't
apply.

Dongli, can you resubmit this patch and update the subject line
accordingly?

You can of course keep Konrad's Review-by tag. I don't expect him to
object.

Wei.

>  xch = xc_interface_open(0,0,0);
>  if ( !xch )
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 09/11] hotplug/NetBSD: honour XEN_{LOG, RUN}_DIR

[Roger Pau Monné]

On Thu, Jun 09, 2016 at 01:57:40PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

Thanks!

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

Re: [Xen-devel] [PATCH 07/11] hotplug/FreeBSD: honour XEN_{LOG, RUN}_DIR

[Roger Pau Monné]

On Thu, Jun 09, 2016 at 01:57:38PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH 08/11] hotplug/Linux: honour XEN_LOG_DIR

[Roger Pau Monné]

On Thu, Jun 09, 2016 at 01:57:39PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 


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

Re: [Xen-devel] [PATCH 14/15] xsm: clean up unregistration

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> The only possible value of original_ops was _xsm_ops, and
> unregister_xsm was never used.
>
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Daniel De Graaf]

On 06/09/2016 10:21 AM, Konrad Rzeszutek Wilk wrote:

As the xen/COPYING file says:
"A few files are licensed under both GPL and a weaker BSD-style
license. This includes all files within the subdirectory
include/public, as described in include/public/COPYING. All such files
include the non-GPL license text as a source-code comment. Although
the license text refers generically to "the software", the non-GPL
license applies *only* to those source files that explicitly include
the non-GPL license text."

The libxenvchan.h is under xen/include/public/io directory
and the xen/include/public/COPYING says:

"XEN NOTICE
==

This copyright applies to all files within this subdirectory and its
subdirectories:
  include/public/*.h
  include/public/hvm/*.h
  include/public/io/*.h

The intention is that these files can be freely copied into the source
tree of an operating system when porting that OS to run on Xen. Doing
so does *not* cause the OS to become subject to the terms of the GPL.

All other files in the Xen source distribution are covered by version
2 of the GNU General Public License except where explicitly stated
otherwise within individual source files.
"
Having the libxenvchan.h as Lesser GPL v2.1 where the COPYING file
says otherwise is confusing to say at least.

Upon consulting with the authors of libxenvchan they said:
"FWIW Neither I, nor ITL staff (as author of original libvchan library)
have anything against converting it to the BSD-style licence."
(Marek Marczykowski-Górecki,
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00995.html)
so as such lets change it.

Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH] APEI: pull a signedness check ahead for Coverity's sake

[Jan Beulich]

>>> On 09.06.16 at 16:24,  wrote:
> On 08/06/16 12:37, Jan Beulich wrote:
>> On 64-bit architectures (which is all we care about right now in ACPI
>> code), the value coming from a __u32 field makes "len" positive anyway,
>> but since from an abstract pov the tool is right, let's just re-order
>> things.
> 
> All the usage of len are unsigned, so why do we want to keep len signed?

Because it serves as the return value of the function, and the
function's return type is signed. Also note how the change makes
the code correct even for 32-bit architectures, even if we don't
care about such in ACPI code right now.

Jan


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

Re: [Xen-devel] [PATCH 13/15] xsm: annotate setup functions with __init

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> These functions were only called from __init functions.
>
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.
>
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Andrew Cooper 

Thanks for fixing the menuconfig bug; I was about to submit a fix
myself.  This is one case where ordering things alphabetically in the
file not the highest priority.

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

Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Ian Jackson]

Wei Liu writes ("Re: [PATCH for 4.7] libxenvchan: Change license of header from 
Lesser GPL v2.1 to BSD"):
> Whose acks are required for this patch?

Everyone CC'd, or (in applicable cases) their employer.

Ian.

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