[Xen-devel] [xen-unstable-smoke test] 138579: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   28 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   27 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 51f7a3e6c5192d3f9a0fa63b0b5617c151180ad7
baseline version:
 ovmf be5903ad1e244cbb0930161fb361ed0b699c4cb8

Last test of basis   138392  2019-06-24 01:39:04 Z3 days
Testing same since   138492  2019-06-25 17:55:27 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Bret Barkelew 
  Fan, ZhijuX 
  Hao A Wu 
  Liming Gao 
  Xiaoyu Lu 
  Zhichao Gao 
  Zhiju.Fan 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   be5903ad1e..51f7a3e6c5  51f7a3e6c5192d3f9a0fa63b0b5617c151180ad7 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH] xen/Kconfig: Fix -Wformat-security when compiling with Clang

[Doug Goldstein]

On Wed, Jun 26, 2019 at 06:36:15PM +0100, Andrew Cooper wrote:
> Clang observes:
> 
> tools/kconfig/conf.c:77:10:
> warning: format string is not a string literal (potentially insecure)
>   [-Wformat-security]
> printf(_("aborted!\n\n"));
>^
> 
> And it is absolutely correct.  gettext() can easily return a string with a %
> in.
> 
> This could be fixed by switching to using printf("%s", _(...)), or by
> switching to puts() (as there is no formatting going on), but the better
> option is follow Linux and remove localisation support.
> 
> Linux changeset: 694c49a7c01cc87194be40cb26404b58b68c291c
> Author: Sam Ravnborg 
> Date:   Tue May 22 20:36:12 2018
> 
> kconfig: drop localization support
> 
> The localization support is broken and appears unused.
> There is no google hits on the update-po-config target.
> And there is no recent (5 years) activity related to the localization.
> 
> So lets just drop this as it is no longer used.
> 
> Suggested-by: Ulf Magnusson 
> Suggested-by: Masahiro Yamada 
> Signed-off-by: Sam Ravnborg 
> Signed-off-by: Masahiro Yamada 
> 
> [Ported to Xen]
> Reported-by: Roger Pau Monné 
> Signed-off-by: Andrew Cooper 

I haven't built this locally but overall I think this is a good backport
to do. In the past there were a lot of concerns about the size of the
Kconfig code base that we were bringing into the tree and some of the
functionality that seemed less than necessary. The approach was taken to
always backport from Linux to ease the maintenance burden for Xen but a
backport like this seems like it achieves both goals.

Acked-by: Doug Goldstein 

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

[Xen-devel] [freebsd-master test] 138540: all pass - PUSHED

[osstest service owner]

flight 138540 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138540/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  14e63f898b16382f4577cfea211a7fb5ad7983e9
baseline version:
 freebsd  fc870a6df90c3876ec348720e21e74beb8b70d92

Last test of basis   138419  2019-06-24 09:19:38 Z2 days
Testing same since   138540  2019-06-26 09:23:06 Z0 days1 attempts


People who touched revisions under test:
  ae 
  araujo 
  asomers 
  avg 
  bcran 
  cy 
  dougm 
  emaste 
  gjb 
  hselasky 
  imp 
  jchandra 
  jhibbits 
  julian 
  kevans 
  luporl 
  markj 
  mav 
  rlibby 
  scottl 
  zec 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  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 :

To xenbits.xen.org:/home/xen/git/freebsd.git
   fc870a6df90..14e63f898b1  14e63f898b16382f4577cfea211a7fb5ad7983e9 -> 
tested/master

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

[Xen-devel] [xen-unstable-smoke test] 138576: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   27 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   26 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-4.11-testing test] 138468: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 138148

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 

[Xen-devel] [xen-unstable-smoke test] 138575: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   26 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   25 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-unstable-smoke test] 138574: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   25 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   24 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-unstable-smoke test] 138570: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   24 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   23 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [linux-4.19 test] 138454: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-credit2 16 guest-start/debian.repeat fail in 138353 pass 
in 138454
 test-arm64-arm64-examine 11 examine-serial/bootloader  fail pass in 138353

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux78778071092e60ab947a0ac99c6bb59aad304526
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  236 days
Failing since129412  2018-11-04 14:10:15 Z  234 days  142 attempts
Testing same since   138353  2019-06-23 03:33:47 Z3 days2 attempts


2175 people touched revisions under test,
not listing them all

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

[Xen-devel] [libvirt test] 138461: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 138327
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 138327
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  fa7d0cc1e74cfc3fa2f268d37e3f8d8ac8728b49
baseline version:
 libvirt  a190f86729d7190b93f9552528cf18ec430e99c4

Last test of basis   138327  2019-06-22 16:57:41 Z4 days
Testing same since   138461  2019-06-25 04:19:44 Z1 days1 attempts


People who touched revisions under test:
  Daniel Henrique Barboza 
  John Ferlan 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   a190f86729..fa7d0cc1e7  fa7d0cc1e74cfc3fa2f268d37e3f8d8ac8728b49 -> 
xen-tested-master

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

[Xen-devel] [xen-unstable-smoke test] 138568: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   23 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   22 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH 17/17] xen/arm64: Zero BSS after the MMU and D-cache is turned on

[Stefano Stabellini]

On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 6/26/19 8:29 PM, Stefano Stabellini wrote:
> > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > At the moment BSS is zeroed before the MMU and D-Cache is turned on.
> > > In other words, the cache will be bypassed when zeroing the BSS section.
> > > 
> > > Per the Image protocol [1], the state of the cache for BSS region is not
> > > known because it is not part of the "loaded kernel image".
> > > 
> > > This means that the cache will need to be invalidated twice for the BSS
> > > region:
> > >  1) Before zeroing to remove any dirty cache line. Otherwise they may
> > >  get evicted while zeroing and therefore overriding the value.
> > >  2) After zeroing to remove any cache line that may have been
> > >  speculated. Otherwise when turning on MMU and D-Cache, the CPU may
> > >  see old values.
> > > 
> > > However, the only reason to have the BSS zeroed early is because the
> > > boot page tables are part of BSS. To avoid the two cache invalidations,
> > > it is possible to move the page tables in the section .data.page_aligned.
> > 
> > I am not following the last part. How is moving the boot page tables to
> > .data.page_aligned solving the problem? Do we need to zero
> > .data.page_aligned early or can we skip it because it is guaranteed to
> > already be zero?
> 
> Global variables are initialized to zero by default regardless the section
> they reside. Usually they are stored in BSS because it saves space in the
> binary.
> 
> With the Image protocol, BSS is not initialized by the bootloader so we have
> to do ourself.
> 
> The section .data.page_aligned is always part of the binary. So the compiler
> will write zero in the binary for any global variables part of that section
> and therefore the corresponding memory will be zeroed when loading the binary.
> 
> If it makes sense, I can try to incorporate that in the commit message.

So basically it is really only BSS the problem. All right, looks good to
me.

Acked-by: Stefano Stabellini 


> > > A new macro DEFINE_BOOT_PAGE_TABLE is introduced to create and mark
> > > page-tables used before BSS is zeroed. This includes all boot_* but also
> > > xen_fixmap as zero_bss() will print a message when earlyprintk is
> > > enabled.
> > 
> > On a similar note, and continuing from what I wrote above, do we need to
> > make sure to zero the xen_fixmap before hooking it up setup_fixmap?
> 
> See above.
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

[Xen-devel] [xen-unstable-smoke bisection] complete build-armhf

[osstest service owner]

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

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:  b41666f2c17f01c437c870389ab713ee62ae3526
  Bug not present: 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138567/


  commit b41666f2c17f01c437c870389ab713ee62ae3526
  Author: Roger Pau Monné 
  Date:   Tue Jun 25 15:39:44 2019 +0200
  
  config: don't hardcode toolchain binaries
  
  Currently the names of the build toolchain binaries are hardcoded in
  StdGNU.mk, and the values from the environment are ignored.
  
  Switch StdGNU.mk to use '?=' instead of '=', so that values from the
  environment are used if present, else default to the values provided
  by the config file.
  
  This change fixes the gitlab CI loop, that was relying on passing
  custom values in the environment variables for the compiler and the
  linker.
  
  Signed-off-by: Roger Pau Monné 
  Acked-by: Andrew Cooper 
  Acked-by: Ian Jackson 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-armhf.xen-build 
--summary-out=tmp/138567.bisection-summary --basis-template=138424 
--blessings=real,real-bisect xen-unstable-smoke build-armhf xen-build
Searching for failure / basis pass:
 138566 fail [host=cubietruck-picasso] / 138424 [host=cubietruck-gleizes] 
138355 [host=cubietruck-metzinger] 138347 ok.
Failure / basis pass flights: 138566 / 138347
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Basis pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11
 
git://xenbits.xen.org/xen.git#11911563610786615c2b3a01cdcaaf09a6f9e38d-1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Loaded 1001 nodes in revision graph
Searching for test results:
 138257 [host=cubietruck-braque]
 138242 [host=cubietruck-gleizes]
 138277 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138295 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138355 [host=cubietruck-metzinger]
 138328 [host=cubietruck-metzinger]
 138317 [host=cubietruck-gleizes]
 138347 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138342 [host=cubietruck-gleizes]
 138424 [host=cubietruck-gleizes]
 138493 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138482 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138489 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138485 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138497 [host=cubietruck-metzinger]
 138501 [host=cubietruck-metzinger]
 138505 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138510 [host=cubietruck-gleizes]
 138517 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138519 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138563 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138547 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138546 [host=cubietruck-gleizes]
 138565 [host=cubietruck-gleizes]
 138549 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138551 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
 138566 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138567 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138550 [host=cubietruck-metzinger]
 138532 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138552 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138534 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138531 [host=cubietruck-metzinger]
 138535 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
 

[Xen-devel] [xen-unstable-smoke test] 138566: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   22 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   21 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH 14/17] xen/arm64: head: Remove ID map as soon as it is not used

[Andrew Cooper]

On 26/06/2019 21:39, Julien Grall wrote:
> On 6/26/19 9:25 PM, Stefano Stabellini wrote:
>> On Mon, 10 Jun 2019, Julien Grall wrote:
>>> The ID map may clash with other parts of the Xen virtual memory layout.
>>> At the moment, Xen is handling the clash by only creating a mapping to
>>> the runtime virtual address before enabling the MMU.
>>>
>>> The rest of the mappings (such as the fixmap) will be mapped after the
>>> MMU is enabled. However, the code doing the mapping is not safe as it
>>> replace mapping without using the Break-Before-Make sequence.
>>>
>>> As the ID map can be anywhere in the memory, it is easier to remove all
>>> the entries added as soon as the ID map is not used rather than adding
>>> the Break-Before-Make sequence everywhere.
>>
>> I think it is a good idea, but I would ask you to mention 1:1 map
>> instead of "ID map" in comments and commit messages because that is the
>> wording we used in all comments so far (see the one in
>> create_page_tables and mm.c). It is easier to grep and refer to if we
>> use the same nomenclature. Note that I don't care about which
>> nomenclature we decide to use, I am only asking for consistency.
>> Otherwise, it would also work if you say it both way at least once:
>>
>>   The ID map (1:1 map) may clash [...]
>
> I would rather drop the wording 1:1 as this is confusing. It is also
> not trivial to find anything on google typing "1:1".

"one-to-one mapping", or "identity map" are both common terminology. 
1:1 is a common representation for the former, whereas ID is not a
abbreviation of "Identity".

If you don't want to use 1:1, then you need to say "The identity map" to
retain clarity.

~Andrew

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

Re: [Xen-devel] [PATCH 14/17] xen/arm64: head: Remove ID map as soon as it is not used

[Julien Grall]

Hi Stefano,

On 6/26/19 9:25 PM, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

The ID map may clash with other parts of the Xen virtual memory layout.
At the moment, Xen is handling the clash by only creating a mapping to
the runtime virtual address before enabling the MMU.

The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, the code doing the mapping is not safe as it
replace mapping without using the Break-Before-Make sequence.

As the ID map can be anywhere in the memory, it is easier to remove all
the entries added as soon as the ID map is not used rather than adding
the Break-Before-Make sequence everywhere.


I think it is a good idea, but I would ask you to mention 1:1 map
instead of "ID map" in comments and commit messages because that is the
wording we used in all comments so far (see the one in
create_page_tables and mm.c). It is easier to grep and refer to if we
use the same nomenclature. Note that I don't care about which
nomenclature we decide to use, I am only asking for consistency.
Otherwise, it would also work if you say it both way at least once:

  The ID map (1:1 map) may clash [...]


I would rather drop the wording 1:1 as this is confusing. It is also not 
trivial to find anything on google typing "1:1".






It is difficult to track where exactly the ID map was created without a
full rework of create_page_tables(). Instead, introduce a new function
remove_id_map() will look where is the top-level entry for the ID map
and remove it.


Do you think it would be worth simplifying this code below by preserving
where/how the ID map was created? We could repurpose x25 for that,
carrying for instance the address of the ID map section slot or a code
number to specify which case we are dealing with. We should be able to
turn remove_id_map into only ~5 lines?


I thought about it but the current implementation of create_map_tables() 
is quite awful to read. So the less I touch this function, the better I 
feel :).


I have some rework for the create_page_tables() which simplify it a lot. 
Yet, I am not entirely sure it is worth to spend time trying to simplify 
remove_id_map. This is unlikely to make the boot significantly faster 
and I don't expect the function to survive more than a release as the ID 
map as to be kept in place (for secondary boot and suspend/resume).


The only reason it is removed now is because it clashes with other 
mapping we may do.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 14/17] xen/arm64: head: Remove ID map as soon as it is not used

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> The ID map may clash with other parts of the Xen virtual memory layout.
> At the moment, Xen is handling the clash by only creating a mapping to
> the runtime virtual address before enabling the MMU.
> 
> The rest of the mappings (such as the fixmap) will be mapped after the
> MMU is enabled. However, the code doing the mapping is not safe as it
> replace mapping without using the Break-Before-Make sequence.
> 
> As the ID map can be anywhere in the memory, it is easier to remove all
> the entries added as soon as the ID map is not used rather than adding
> the Break-Before-Make sequence everywhere.

I think it is a good idea, but I would ask you to mention 1:1 map
instead of "ID map" in comments and commit messages because that is the
wording we used in all comments so far (see the one in
create_page_tables and mm.c). It is easier to grep and refer to if we
use the same nomenclature. Note that I don't care about which
nomenclature we decide to use, I am only asking for consistency.
Otherwise, it would also work if you say it both way at least once:

 The ID map (1:1 map) may clash [...]


> It is difficult to track where exactly the ID map was created without a
> full rework of create_page_tables(). Instead, introduce a new function
> remove_id_map() will look where is the top-level entry for the ID map
> and remove it.

Do you think it would be worth simplifying this code below by preserving
where/how the ID map was created? We could repurpose x25 for that,
carrying for instance the address of the ID map section slot or a code
number to specify which case we are dealing with. We should be able to
turn remove_id_map into only ~5 lines?


> The new function is only called for the boot CPU. Secondary CPUs will
> switch directly to the runtime page-tables so there are no need to
> remove the ID mapping. Note that this still doesn't make the Secondary
> CPUs path safe but it is not making it worst.
> 
> ---
> Note that the comment refers to the patch  "xen/arm: tlbflush: Rework
> TLB helpers" under review (see [1]).
> 
> Furthermore, it is very likely we will need to re-introduce the ID
> map to cater secondary CPUs boot and suspend/resume. For now, the
> attempt is to make boot CPU path fully Arm Arm compliant.
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01134.html
> ---
>  xen/arch/arm/arm64/head.S | 86 
> ++-
>  1 file changed, 71 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 192af3e8a2..96e85f8834 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -300,6 +300,13 @@ real_start_efi:
>  ldr   x0, =primary_switched
>  brx0
>  primary_switched:
> +/*
> + * The ID map may clash with other parts of the Xen virtual memory
> + * layout. As it is not used anymore, remove it completely to
> + * avoid having to worry about replacing existing mapping
> + * afterwards.
> + */
> +blremove_id_map
>  blsetup_fixmap
>  #ifdef CONFIG_EARLY_PRINTK
>  /* Use a virtual address to access the UART. */
> @@ -632,10 +639,68 @@ enable_mmu:
>  ret
>  ENDPROC(enable_mmu)
>  
> +/*
> + * Remove the ID map for the page-tables. It is not easy to keep track
> + * where the ID map was mapped, so we will look for the top-level entry
> + * exclusive to the ID Map and remove it.
> + *
> + * Inputs:
> + *   x19: paddr(start)
> + *
> + * Clobbers x0 - x1
> + */
> +remove_id_map:
> +/*
> + * Find the zeroeth slot used. Remove the entry from zeroeth
> + * table if the slot is not 0. For slot 0, the ID map was either
> + * done in first or second table.
> + */
> +lsr   x1, x19, #ZEROETH_SHIFT   /* x1 := zeroeth slot */
> +cbz   x1, 1f
> +/* It is not in slot 0, remove the entry */
> +ldr   x0, =boot_pgtable /* x0 := root table */
> +str   xzr, [x0, x1, lsl #3]
> +b id_map_removed
> +
> +1:
> +/*
> + * Find the first slot used. Remove the entry for the first
> + * table if the slot is not 0. For slot 0, the ID map was done
> + * in the second table.
> + */
> +lsr   x1, x19, #FIRST_SHIFT
> +and   x1, x1, #LPAE_ENTRY_MASK  /* x1 := first slot */
> +cbz   x1, 1f
> +/* It is not in slot 0, remove the entry */
> +ldr   x0, =boot_first   /* x0 := first table */
> +str   xzr, [x0, x1, lsl #3]
> +b id_map_removed
> +
> +1:
> +/*
> + * Find the second slot used. Remove the entry for the first
> + * table if the slot is not 1 (runtime Xen mapping is 2M - 4M).
> + * For slot 1, it means the ID map was not created.
> + */
> +lsr   x1, x19, #SECOND_SHIFT
> +and   x1, 

Re: [Xen-devel] [PATCH 16/17] xen/arm64: head: Rework and document launch()

[Julien Grall]

Hi Stefano,

On 6/26/19 8:12 PM, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().

In order to avoid a branch for the decision and make the code clearer,
launch() is reworked to take in parameters the entry point and its
arguments.

Lastly, document the behavior and the main registers usage within the
function.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 41 +
  1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 4f7fa6769f..130ab66d8e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -312,6 +312,11 @@ primary_switched:
  /* Use a virtual address to access the UART. */
  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
  #endif
+PRINT("- Ready -\r\n")
+/* Setup the arguments for start_xen and jump to C world */
+mov   x0, x20/* x0 := phys_offset */
+mov   x1, x21/* x1 := paddr(FDT) */
+ldr   x2, =start_xen
  b launch
  ENDPROC(real_start)
  
@@ -374,6 +379,9 @@ secondary_switched:

  /* Use a virtual address to access the UART. */
  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
  #endif
+PRINT("- Ready -\r\n")
+/* Jump to C world */
+ldr   x2, =start_secondary
  b launch
  ENDPROC(init_secondary)
  
@@ -734,23 +742,24 @@ setup_fixmap:

  ret
  ENDPROC(setup_fixmap)
  
+/*

+ * Setup the initial stack and jump to the C world
+ *
+ * Inputs:
+ *   x0 : Argument 0 of the C function to call
+ *   x1 : Argument 1 of the C function to call
+ *   x2 : C entry point


I know it is the last one before C-land, but we might as well add a
"Clobbers" section too, just in case. Here it clobbers x4 (or x3, see
below).


Sure.





+ */
  launch:
-PRINT("- Ready -\r\n")
-
-ldr   x0, =init_data
-add   x0, x0, #INITINFO_stack /* Find the boot-time stack */
-ldr   x0, [x0]
-add   x0, x0, #STACK_SIZE/* (which grows down from the top). */
-sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
-mov   sp, x0
-
-cbnz  x22, 1f
-
-mov   x0, x20/* Marshal args: - phys_offset */
-mov   x1, x21/*   - FDT */
-b start_xen  /* and disappear into the land of C */
-1:
-b start_secondary/* (to the appropriate entry point) */
+ldr   x4, =init_data


why not use x3 instead of x4?


I think a remnant of early rework when start_secondary was taking 3 
parameters. I will update it.






+add   x4, x4, #INITINFO_stack /* Find the boot-time stack */
+ldr   x4, [x4]
+add   x4, x4, #STACK_SIZE/* (which grows down from the top). */


If you are going to respin it, could you please align the comments a bit
better (one space to the right)?


Sure.





+sub   x4, x4, #CPUINFO_sizeof /* Make room for CPU save record */
+mov   sp, x4
+
+/* Jump to C world */
+brx2
  ENDPROC(launch)
  
  /* Fail-stop */


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 17/17] xen/arm64: Zero BSS after the MMU and D-cache is turned on

[Julien Grall]

Hi Stefano,

On 6/26/19 8:29 PM, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.

Per the Image protocol [1], the state of the cache for BSS region is not
known because it is not part of the "loaded kernel image".

This means that the cache will need to be invalidated twice for the BSS
region:
 1) Before zeroing to remove any dirty cache line. Otherwise they may
 get evicted while zeroing and therefore overriding the value.
 2) After zeroing to remove any cache line that may have been
 speculated. Otherwise when turning on MMU and D-Cache, the CPU may
 see old values.

However, the only reason to have the BSS zeroed early is because the
boot page tables are part of BSS. To avoid the two cache invalidations,
it is possible to move the page tables in the section .data.page_aligned.


I am not following the last part. How is moving the boot page tables to
.data.page_aligned solving the problem? Do we need to zero
.data.page_aligned early or can we skip it because it is guaranteed to
already be zero?


Global variables are initialized to zero by default regardless the 
section they reside. Usually they are stored in BSS because it saves 
space in the binary.


With the Image protocol, BSS is not initialized by the bootloader so we 
have to do ourself.


The section .data.page_aligned is always part of the binary. So the 
compiler will write zero in the binary for any global variables part of 
that section and therefore the corresponding memory will be zeroed when 
loading the binary.


If it makes sense, I can try to incorporate that in the commit message.





A new macro DEFINE_BOOT_PAGE_TABLE is introduced to create and mark
page-tables used before BSS is zeroed. This includes all boot_* but also
xen_fixmap as zero_bss() will print a message when earlyprintk is
enabled.


On a similar note, and continuing from what I wrote above, do we need to
make sure to zero the xen_fixmap before hooking it up setup_fixmap?


See above.

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 138563: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   21 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   20 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH 15/17] xen/arm64: head: Rework and document setup_fixmap()

[Julien Grall]

Hi Stefano,

On 6/26/19 8:01 PM, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.

In the future, the boot CPU will not switch between page-tables to avoid
TLB conflict. This means the fixmap table will need to be hooked before
any use. For simplicity, setup_fixmap() will now do that job.


Can I ask you to reword this slightly, especially the last sentence? It
took me a while to understand what you meant. I suggest:

  In the future, the boot CPU will not switch between page-tables to
  avoid any TLB conflicts. Thus, the fixmap table will need to be always
  hooked before any use. Let's start doing it now in setup_fixmap().



I will update the commit message.


Acked-by: Stefano Stabellini  >

Lastly, document the behavior and the main registers usage within the
function.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 96e85f8834..4f7fa6769f 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -700,8 +700,17 @@ id_map_removed:
  ret
  ENDPROC(remove_id_map)
  
+/*

+ * Map the UART in the fixmap (when earlyprintk is used) and hook the
+ * fixmap table in the page tables.
+ *
+ * The fixmap cannot be mapped in create_page_tables because it may
+ * clash with the ID map.
+ *
+ * Clobbers x0 - x1
+ */
  setup_fixmap:
-#if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */
+#ifdef CONFIG_EARLY_PRINTK


I am curious why you made this code style change


This is the only #if defined within head.S (the rest use #ifdef) so for 
consistency. Also, it is simpler to read :).


Cheers,

--
Julien Grall
I

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

Re: [Xen-devel] [PATCH 17/17] xen/arm64: Zero BSS after the MMU and D-cache is turned on

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment BSS is zeroed before the MMU and D-Cache is turned on.
> In other words, the cache will be bypassed when zeroing the BSS section.
> 
> Per the Image protocol [1], the state of the cache for BSS region is not
> known because it is not part of the "loaded kernel image".
> 
> This means that the cache will need to be invalidated twice for the BSS
> region:
> 1) Before zeroing to remove any dirty cache line. Otherwise they may
> get evicted while zeroing and therefore overriding the value.
> 2) After zeroing to remove any cache line that may have been
> speculated. Otherwise when turning on MMU and D-Cache, the CPU may
> see old values.
> 
> However, the only reason to have the BSS zeroed early is because the
> boot page tables are part of BSS. To avoid the two cache invalidations,
> it is possible to move the page tables in the section .data.page_aligned.

I am not following the last part. How is moving the boot page tables to
.data.page_aligned solving the problem? Do we need to zero
.data.page_aligned early or can we skip it because it is guaranteed to
already be zero?


> A new macro DEFINE_BOOT_PAGE_TABLE is introduced to create and mark
> page-tables used before BSS is zeroed. This includes all boot_* but also
> xen_fixmap as zero_bss() will print a message when earlyprintk is
> enabled.

On a similar note, and continuing from what I wrote above, do we need to
make sure to zero the xen_fixmap before hooking it up setup_fixmap?


> [1] linux/Documentation/arm64/booting.txt
> 
> ---
> 
> Note that the arm32 support is not there yet. This will need to be
> addressed here or separately depending on when the Arm32 boot rework
> is sent.
> ---
>  xen/arch/arm/arm64/head.S |  6 +++---
>  xen/arch/arm/mm.c | 23 +--
>  2 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 130ab66d8e..6c3edbbc81 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -291,7 +291,6 @@ real_start_efi:
>  mov   x22, #0/* x22 := is_secondary_cpu */
>  
>  blcheck_cpu_mode
> -blzero_bss
>  blcpu_init
>  blcreate_page_tables
>  blenable_mmu
> @@ -312,6 +311,7 @@ primary_switched:
>  /* Use a virtual address to access the UART. */
>  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
> +blzero_bss
>  PRINT("- Ready -\r\n")
>  /* Setup the arguments for start_xen and jump to C world */
>  mov   x0, x20/* x0 := phys_offset */
> @@ -423,8 +423,8 @@ zero_bss:
>  cbnz  x26, skip_bss
>  
>  PRINT("- Zero BSS -\r\n")
> -load_paddr x0, __bss_start/* Load paddr of start & end of bss */
> -load_paddr x1, __bss_end
> +ldr   x0, =__bss_start   /* x0 := vaddr(__bss_start) */
> +ldr   x1, =__bss_end /* x1 := vaddr(__bss_start) */
>  
>  1:  str   xzr, [x0], #8
>  cmp   x0, x1
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 6a549e9283..0b2d07a258 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -48,6 +48,17 @@
>  #undef mfn_to_virt
>  #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
>  
> +/*
> + * Macros to define page-tables:
> + *  - DEFINE_BOOT_PAGE_TABLE is used to define page-table that are used
> + *  in assembly code before BSS is zeroed.
> + *  - DEFINE_PAGE_TABLE{,S} are used to define one or multiple
> + *  page-tables to be used after BSS is zeroed (typically they are only used
> + *  in C).
> + */
> +#define DEFINE_BOOT_PAGE_TABLE(name) 
>  \
> +lpae_t __aligned(PAGE_SIZE) __section(".data.page_aligned") 
> name[LPAE_ENTRIES]
> +
>  #define DEFINE_PAGE_TABLES(name, nr)\
>  lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
>  
> @@ -76,13 +87,13 @@ lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
>   * Finally, if EARLY_PRINTK is enabled then xen_fixmap will be mapped
>   * by the CPU once it has moved off the 1:1 mapping.
>   */
> -DEFINE_PAGE_TABLE(boot_pgtable);
> +DEFINE_BOOT_PAGE_TABLE(boot_pgtable);
>  #ifdef CONFIG_ARM_64
> -DEFINE_PAGE_TABLE(boot_first);
> -DEFINE_PAGE_TABLE(boot_first_id);
> +DEFINE_BOOT_PAGE_TABLE(boot_first);
> +DEFINE_BOOT_PAGE_TABLE(boot_first_id);
>  #endif
> -DEFINE_PAGE_TABLE(boot_second);
> -DEFINE_PAGE_TABLE(boot_third);
> +DEFINE_BOOT_PAGE_TABLE(boot_second);
> +DEFINE_BOOT_PAGE_TABLE(boot_third);
>  
>  /* Main runtime page tables */
>  
> @@ -135,7 +146,7 @@ static __initdata int xenheap_first_first_slot = -1;
>   */
>  static DEFINE_PAGE_TABLES(xen_second, 2);
>  /* First level page table used for fixmap */
> -DEFINE_PAGE_TABLE(xen_fixmap);
> +DEFINE_BOOT_PAGE_TABLE(xen_fixmap);
>  /* First level page table used to map Xen itself with the XN bit set
>   * as 

Re: [Xen-devel] [PATCH 13/17] xen/arm64: head: Don't setup the fixmap on secondary CPUs

[Julien Grall]

Hi,

On 6/26/19 7:51 PM, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register x23 holding the address to
the UART.

However, secondary CPUs are switching to the runtime page tables before
using the earlyprintk again. So settting up the fixmap in the boot pages
tables is pointless.


Typo: settting


ok.



Also, you could add that it is "impossible" to find ourselves in the
position of needing earlyprintk for secondary CPUs before the runtime
page tables are up, because it is done right after in the boot sequence.


It is kind of implied by the comment and the code below. But I can 
clearly state it.




Reviewed-by: Stefano Stabellini 


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

[Julien Grall]

Hi Stefano,

On 6/26/19 7:32 PM, Stefano Stabellini wrote:

On Wed, 26 Jun 2019, Julien Grall wrote:

Hi Stefano,

On 26/06/2019 16:27, Stefano Stabellini wrote:

On Wed, 26 Jun 2019, Julien Grall wrote:

Hi Stefano,

On 26/06/2019 00:59, Stefano Stabellini wrote:

On Tue, 25 Jun 2019, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

The current implementation of the macro PRINT will clobber
x30/lr.
This

means the user should save lr if it cares about it.


By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
expression.


No of course not! You meant x30 which is a synonym of lr! It is just
that in this case it is also supposed to clobber x0-x3 -- I got
confused! The commit message is also fine as is then. More below.



Reviewed-by: Stefano Stabellini 



Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve
lr,
the macro PRINT is modified to save and restore it.

While the comment state x3 will be clobbered, this is not the case.
So
PRINT will use x3 to preserve lr.

Lastly, take the opportunity to move the comment on top of PRINT and
use
PRINT in init_uart. Both changes will be helpful in a follow-up
patch.

Signed-off-by: Julien Grall 
---
xen/arch/arm/arm64/head.S | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index c8bbdf05a6..a5147c8d80 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -78,12 +78,17 @@
 *  x30 - lr
 */
-/* Macro to print a string to the UART, if there is one.
- * Clobbers x0-x3. */
#ifdef CONFIG_EARLY_PRINTK
+/*
+ * Macro to print a string to the UART, if there is one.
+ *
+ * Clobbers x0 - x3
+ */
#define PRINT(_s)   \
+mov   x3, lr  ; \
adr   x0, 98f ; \
blputs; \
+mov   lr, x3  ; \
RODATA_STR(98, _s)


Strangely enough I get a build error with gcc 7.3.1, but if I use x30
instead of lr, it builds fine. Have you seen this before?


Hmmm, I can't to reproduce it even on older compiler (4.9). My guess is
not
all the assembler is able to understand "lr".

In the file entry.S we have the following line:

lr  .reqx30 // link register


Could you give a try to add the line in head.S?


That works


Thank you.

I thought a bit more during the day and decided to use "x30" directly rather
than lr. We can decide to revisit it if we think the code is too difficult to
read.


I was going to suggest x30 too yesterday, but if we can make `lr' work
then that would be my preference because it makes it more immediately
obvious what the code is doing.


I will have a look to move the line in an header.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

On 26/06/2019, 18:44, "Stefano Stabellini"  wrote:

On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth  wrote:
> > 
> > 
> > 
> > On 25/06/2019, 21:27, "Rich Persaud"  wrote:
> > 
> >> On Jun 25, 2019, at 16:17, Julien Grall  wrote:
> >> 
> >> Hi Rich,
> >> 
> >> On 6/25/19 8:38 PM, Rich Persaud wrote:
>  On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
>  
>  Hi all:
>  please add your agenda items. I had only ONE series which was 
highlighted as needing attention from others. Is this seriously the only one?
> > 
> > We had quite a few additions to the agenda. One problem I have is that 
cryptpad history does not tell me who added an agenda item. We will have to 
manage this appropriately in the meeting.
> > 
> >>> Proposed agenda item: in the absence of Jira tickets, would it be 
useful to have a list (e.g. generated by a script) with the lifecycle status of 
all outstanding patch series, e.g.
> >>> METADATA
> >>> - bug fix / improvement / refactor / cleanup / new feature
> >>> - impacted Xen subsystems/components/features
> >>> - targeted version of Xen
> >>> - contributing person/org
> >>> - relevance of patch series to the goals set by RM for the next Xen 
release
> >>> - related patch series (with below status info)
> >>> STATUS:
> >>> - patch series version
> >>> - date of patch series v1
> >>> - no responses received + ping count + days since submission + days 
since ping
> >>> - reviewed with objections
> >>> - reviewed without objections, awaiting ack
> >>> - acked, awaiting merge
> >>> From such a summary, patch series could be prioritized for 
review/triage in the community call, based on uniform criteria and project-wide 
context.
> >> 
> >> While I think raising awareness of the stuck series is a good idea. I 
still have some concern regarding the prioritization. Who is going to consume 
the result of the discussion? Is it the maintainers?
> > 
> >   Anyone who typically answers the question raised by Lars in this 
thread, presumably a subset of call attendees.
> > 
> > This would only work if there was consensus on the priority amongst the 
key stake-holders. I believe that some limited prioritization has happened in 
the past, e.g. for some Arm related features for Xen 4.12 where, if I recall 
correctly you, Stefano and EPAM did this. 
> > 
> > Maybe we can trial this type of approach for a small number of series 
first. At the end of the day this is about queue management. Right now, when a 
new series comes in it ends up in one big queue (xen-devel@). Most complex 
series have to go through a series of gates (aka code reviews from different 
people) before they get applied and when a new version comes out the series 
ends up in the queue again: each reviewer today prioritizes their own review 
queues, where no-one else sees the prioritisation of other reviewers. Unless 
there is lot of spare review capacity (which there isn't) we essentially end up 
in grid-lock, with an ever-growing queue. We seem to have specific additional 
complexity in Xen because most recent series, typically involve a large number 
of reviewers.
> > 
> > In theory, there are several ways to address this:
> > * Queue management either by a set of agreed criteria which all 
reviewers follow or through some agreement about which series we actively try 
and shepherd through the gates
> > * We have an additional issue that in many areas we have multiple 
reviewers/committers reviewing the same area of code, which also frequently 
leads to slow-downs, because the multiple reviewers/committers can disagree. We 
could look at a model where the reviewers/committers agree that one takes the 
lead on reviewing a specific series. We could try and streamline the ownership 
structure to create a clearer mapping.
> > * The queues of each reviewer are somehow made public (assuming this is 
possible) and we hope that the system self-regulates. Not sure this will 
actually work
> > 
> > The big problem I have is that mailing lists really don't lend 
themselves well to highlight what is going on. We have been grappling with this 
for years and things are getting worse, not better.
> >
> > In past community calls when we tried to do this with specific series, 
in practice we ended up discovering obstacles that were concerning a specific 
series, such as unexposed dependencies, lack of HW, specs against which to 
review being too complex, ...
> > 
> > In any case, given that quite a few series were added to the agenda, 
maybe we shouldn't talk about process in the meeting, but see whether we can 
unblock those series. I am going to annotate some of the agenda items to 
highlight WHO needs to take action on items added
> > 
> > We could have a wider discussion about 

Re: [Xen-devel] [PATCH 16/17] xen/arm64: head: Rework and document launch()

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> Boot CPU and secondary CPUs will use different entry point to C code. At
> the moment, the decision on which entry to use is taken within launch().
> 
> In order to avoid a branch for the decision and make the code clearer,
> launch() is reworked to take in parameters the entry point and its
> arguments.
> 
> Lastly, document the behavior and the main registers usage within the
> function.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 41 +
>  1 file changed, 25 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 4f7fa6769f..130ab66d8e 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -312,6 +312,11 @@ primary_switched:
>  /* Use a virtual address to access the UART. */
>  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
> +PRINT("- Ready -\r\n")
> +/* Setup the arguments for start_xen and jump to C world */
> +mov   x0, x20/* x0 := phys_offset */
> +mov   x1, x21/* x1 := paddr(FDT) */
> +ldr   x2, =start_xen
>  b launch
>  ENDPROC(real_start)
>  
> @@ -374,6 +379,9 @@ secondary_switched:
>  /* Use a virtual address to access the UART. */
>  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
> +PRINT("- Ready -\r\n")
> +/* Jump to C world */
> +ldr   x2, =start_secondary
>  b launch
>  ENDPROC(init_secondary)
>  
> @@ -734,23 +742,24 @@ setup_fixmap:
>  ret
>  ENDPROC(setup_fixmap)
>  
> +/*
> + * Setup the initial stack and jump to the C world
> + *
> + * Inputs:
> + *   x0 : Argument 0 of the C function to call
> + *   x1 : Argument 1 of the C function to call
> + *   x2 : C entry point

I know it is the last one before C-land, but we might as well add a
"Clobbers" section too, just in case. Here it clobbers x4 (or x3, see
below).


> + */
>  launch:
> -PRINT("- Ready -\r\n")
> -
> -ldr   x0, =init_data
> -add   x0, x0, #INITINFO_stack /* Find the boot-time stack */
> -ldr   x0, [x0]
> -add   x0, x0, #STACK_SIZE/* (which grows down from the top). */
> -sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
> -mov   sp, x0
> -
> -cbnz  x22, 1f
> -
> -mov   x0, x20/* Marshal args: - phys_offset */
> -mov   x1, x21/*   - FDT */
> -b start_xen  /* and disappear into the land of C */
> -1:
> -b start_secondary/* (to the appropriate entry point) */
> +ldr   x4, =init_data

why not use x3 instead of x4?


> +add   x4, x4, #INITINFO_stack /* Find the boot-time stack */
> +ldr   x4, [x4]
> +add   x4, x4, #STACK_SIZE/* (which grows down from the top). */

If you are going to respin it, could you please align the comments a bit
better (one space to the right)?


> +sub   x4, x4, #CPUINFO_sizeof /* Make room for CPU save record */
> +mov   sp, x4
> +
> +/* Jump to C world */
> +brx2
>  ENDPROC(launch)
>  
>  /* Fail-stop */

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

[Xen-devel] [PATCH] x86/vvmx: set CR4 before CR0

[Andrew Cooper]

From: Sergey Dyasli 

Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2
and vice-versa).

Signed-off-by: Sergey Dyasli 
Reviewed-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Jun Nakajima 
CC: Kevin Tian 

I found this patch languishing in the XenServer patchqueue, and Sergey is OoO
so I'm submitting it on his behalf.

Without this change, nested virt is broken when L1 and L2 differ in their use
of PCID.

This is only a stopgap solution - it resolves the PCID issue without
introducing other issues, but the proper fix needs to consider all control
bits at once, rather than considering a vmentry/exit as a sequence of changes
of discrete registers.
---
 xen/arch/x86/hvm/vmx/vvmx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 7bca572d88..332623d006 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1024,11 +1024,11 @@ static void load_shadow_guest_state(struct vcpu *v)
 nvcpu->guest_cr[0] = get_vvmcs(v, CR0_READ_SHADOW);
 nvcpu->guest_cr[4] = get_vvmcs(v, CR4_READ_SHADOW);
 
-rc = hvm_set_cr0(get_vvmcs(v, GUEST_CR0), true);
+rc = hvm_set_cr4(get_vvmcs(v, GUEST_CR4), true);
 if ( rc == X86EMUL_EXCEPTION )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 
-rc = hvm_set_cr4(get_vvmcs(v, GUEST_CR4), true);
+rc = hvm_set_cr0(get_vvmcs(v, GUEST_CR0), true);
 if ( rc == X86EMUL_EXCEPTION )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 
@@ -1238,11 +1238,11 @@ static void load_vvmcs_host_state(struct vcpu *v)
 __vmwrite(vmcs_h2g_field[i].guest_field, r);
 }
 
-rc = hvm_set_cr0(get_vvmcs(v, HOST_CR0), true);
+rc = hvm_set_cr4(get_vvmcs(v, HOST_CR4), true);
 if ( rc == X86EMUL_EXCEPTION )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 
-rc = hvm_set_cr4(get_vvmcs(v, HOST_CR4), true);
+rc = hvm_set_cr0(get_vvmcs(v, HOST_CR0), true);
 if ( rc == X86EMUL_EXCEPTION )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 15/17] xen/arm64: head: Rework and document setup_fixmap()

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
> 
> In the future, the boot CPU will not switch between page-tables to avoid
> TLB conflict. This means the fixmap table will need to be hooked before
> any use. For simplicity, setup_fixmap() will now do that job.
> 
> Lastly, document the behavior and the main registers usage within the
> function.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 96e85f8834..4f7fa6769f 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -700,8 +700,17 @@ id_map_removed:
>  ret
>  ENDPROC(remove_id_map)
>  
> +/*
> + * Map the UART in the fixmap (when earlyprintk is used) and hook the
> + * fixmap table in the page tables.
> + *
> + * The fixmap cannot be mapped in create_page_tables because it may
> + * clash with the ID map.
> + *
> + * Clobbers x0 - x1

I missed this in the last email: it should be x0 - x4?


> + */
>  setup_fixmap:
> -#if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */
> +#ifdef CONFIG_EARLY_PRINTK
>  /* Add UART to the fixmap table */
>  ldr   x1, =xen_fixmap/* x1 := vaddr (xen_fixmap) */
>  lsr   x2, x23, #THIRD_SHIFT
> @@ -709,6 +718,7 @@ setup_fixmap:
>  mov   x3, #PT_DEV_L3
>  orr   x2, x2, x3 /* x2 := 4K dev map including UART */
>  str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's 
> slot */
> +#endif
>  
>  /* Map fixmap into boot_second */
>  ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
> @@ -721,7 +731,6 @@ setup_fixmap:
>  
>  /* Ensure any page table updates made above have occurred */
>  dsb   nshst
> -#endif
>  ret
>  ENDPROC(setup_fixmap)
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 15/17] xen/arm64: head: Rework and document setup_fixmap()

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
> 
> In the future, the boot CPU will not switch between page-tables to avoid
> TLB conflict. This means the fixmap table will need to be hooked before
> any use. For simplicity, setup_fixmap() will now do that job.

Can I ask you to reword this slightly, especially the last sentence? It
took me a while to understand what you meant. I suggest:

 In the future, the boot CPU will not switch between page-tables to
 avoid any TLB conflicts. Thus, the fixmap table will need to be always
 hooked before any use. Let's start doing it now in setup_fixmap().

Acked-by: Stefano Stabellini 


> Lastly, document the behavior and the main registers usage within the
> function.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 96e85f8834..4f7fa6769f 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -700,8 +700,17 @@ id_map_removed:
>  ret
>  ENDPROC(remove_id_map)
>  
> +/*
> + * Map the UART in the fixmap (when earlyprintk is used) and hook the
> + * fixmap table in the page tables.
> + *
> + * The fixmap cannot be mapped in create_page_tables because it may
> + * clash with the ID map.
> + *
> + * Clobbers x0 - x1
> + */
>  setup_fixmap:
> -#if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */
> +#ifdef CONFIG_EARLY_PRINTK

I am curious why you made this code style change


>  /* Add UART to the fixmap table */
>  ldr   x1, =xen_fixmap/* x1 := vaddr (xen_fixmap) */
>  lsr   x2, x23, #THIRD_SHIFT
> @@ -709,6 +718,7 @@ setup_fixmap:
>  mov   x3, #PT_DEV_L3
>  orr   x2, x2, x3 /* x2 := 4K dev map including UART */
>  str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's 
> slot */
> +#endif
>  
>  /* Map fixmap into boot_second */
>  ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
> @@ -721,7 +731,6 @@ setup_fixmap:
>  
>  /* Ensure any page table updates made above have occurred */
>  dsb   nshst
> -#endif
>  ret
>  ENDPROC(setup_fixmap)
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 13/17] xen/arm64: head: Don't setup the fixmap on secondary CPUs

[Stefano Stabellini]

On Mon, 10 Jun 2019, Julien Grall wrote:
> setup_fixmap() will setup the fixmap in the boot page tables in order to
> use earlyprintk and also update the register x23 holding the address to
> the UART.
> 
> However, secondary CPUs are switching to the runtime page tables before
> using the earlyprintk again. So settting up the fixmap in the boot pages
> tables is pointless.

Typo: settting

Also, you could add that it is "impossible" to find ourselves in the
position of needing earlyprintk for secondary CPUs before the runtime
page tables are up, because it is done right after in the boot sequence.

Reviewed-by: Stefano Stabellini 


> This means most of setup_fixmap() is not necessary for the secondary
> CPUs. The update of UART address is now moved out of setup_fixmap() and
> duplicated in the CPU boot and secondary CPUs boot. Additionally, the
> call to setup_fixmap() is removed from secondary CPUs boot.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 6be4af7579..192af3e8a2 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -301,6 +301,10 @@ real_start_efi:
>  brx0
>  primary_switched:
>  blsetup_fixmap
> +#ifdef CONFIG_EARLY_PRINTK
> +/* Use a virtual address to access the UART. */
> +ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
> +#endif
>  b launch
>  ENDPROC(real_start)
>  
> @@ -343,8 +347,6 @@ GLOBAL(init_secondary)
>  ldr   x0, =secondary_switched
>  brx0
>  secondary_switched:
> -blsetup_fixmap
> -
>  /*
>   * Non-boot CPUs need to move on to the proper pagetables, which were
>   * setup in init_secondary_pagetables.
> @@ -361,6 +363,10 @@ secondary_switched:
>  dsb   sy /* Ensure completion of TLB flush */
>  isb
>  
> +#ifdef CONFIG_EARLY_PRINTK
> +/* Use a virtual address to access the UART. */
> +ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
> +#endif
>  b launch
>  ENDPROC(init_secondary)
>  
> @@ -631,10 +637,6 @@ setup_fixmap:
>   * don't need the 1:1 map any more */
>  dsb   sy
>  #if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */
> -/* Non-boot CPUs don't need to rebuild the fixmap itself, just
> - * the mapping from boot_second to xen_fixmap */
> -cbnz  x22, 1f
> -
>  /* Add UART to the fixmap table */
>  ldr   x1, =xen_fixmap/* x1 := vaddr (xen_fixmap) */
>  lsr   x2, x23, #THIRD_SHIFT
> @@ -642,7 +644,6 @@ setup_fixmap:
>  mov   x3, #PT_DEV_L3
>  orr   x2, x2, x3 /* x2 := 4K dev map including UART */
>  str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's 
> slot */
> -1:
>  
>  /* Map fixmap into boot_second */
>  ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
> @@ -652,9 +653,6 @@ setup_fixmap:
>  ldr   x1, =FIXMAP_ADDR(0)
>  lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x1 := Slot for FIXMAP(0) */
>  str   x2, [x4, x1]   /* Map it in the fixmap's slot */
> -
> -/* Use a virtual address to access the UART. */
> -ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
>  
>  /*
> -- 
> 2.11.0
> 

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

[Xen-devel] [xen-unstable-smoke test] 138560: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   20 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   19 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

[Stefano Stabellini]

On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 26/06/2019 16:27, Stefano Stabellini wrote:
> > On Wed, 26 Jun 2019, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 26/06/2019 00:59, Stefano Stabellini wrote:
> > > > On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> > > > > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > > > > >The current implementation of the macro PRINT will clobber
> > > > > > > x30/lr.
> > > > > > > This
> > > > > > means the user should save lr if it cares about it.
> > > > > 
> > > > > By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
> > > > > expression.
> > > > 
> > > > No of course not! You meant x30 which is a synonym of lr! It is just
> > > > that in this case it is also supposed to clobber x0-x3 -- I got
> > > > confused! The commit message is also fine as is then. More below.
> > > > 
> > > > 
> > > > > Reviewed-by: Stefano Stabellini 
> > > > > 
> > > > > 
> > > > > > Follow-up patches will introduce more use of PRINT in place where lr
> > > > > > should be preserved. Rather than requiring all the users to preserve
> > > > > > lr,
> > > > > > the macro PRINT is modified to save and restore it.
> > > > > > 
> > > > > > While the comment state x3 will be clobbered, this is not the case.
> > > > > > So
> > > > > > PRINT will use x3 to preserve lr.
> > > > > > 
> > > > > > Lastly, take the opportunity to move the comment on top of PRINT and
> > > > > > use
> > > > > > PRINT in init_uart. Both changes will be helpful in a follow-up
> > > > > > patch.
> > > > > > 
> > > > > > Signed-off-by: Julien Grall 
> > > > > > ---
> > > > > >xen/arch/arm/arm64/head.S | 14 +-
> > > > > >1 file changed, 9 insertions(+), 5 deletions(-)
> > > > > > 
> > > > > > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > > > > > index c8bbdf05a6..a5147c8d80 100644
> > > > > > --- a/xen/arch/arm/arm64/head.S
> > > > > > +++ b/xen/arch/arm/arm64/head.S
> > > > > > @@ -78,12 +78,17 @@
> > > > > > *  x30 - lr
> > > > > > */
> > > > > >-/* Macro to print a string to the UART, if there is one.
> > > > > > - * Clobbers x0-x3. */
> > > > > >#ifdef CONFIG_EARLY_PRINTK
> > > > > > +/*
> > > > > > + * Macro to print a string to the UART, if there is one.
> > > > > > + *
> > > > > > + * Clobbers x0 - x3
> > > > > > + */
> > > > > >#define PRINT(_s)   \
> > > > > > +mov   x3, lr  ; \
> > > > > >adr   x0, 98f ; \
> > > > > >blputs; \
> > > > > > +mov   lr, x3  ; \
> > > > > >RODATA_STR(98, _s)
> > > > 
> > > > Strangely enough I get a build error with gcc 7.3.1, but if I use x30
> > > > instead of lr, it builds fine. Have you seen this before?
> > > 
> > > Hmmm, I can't to reproduce it even on older compiler (4.9). My guess is
> > > not
> > > all the assembler is able to understand "lr".
> > > 
> > > In the file entry.S we have the following line:
> > > 
> > > lr  .reqx30 // link register
> > > 
> > > 
> > > Could you give a try to add the line in head.S?
> > 
> > That works
> 
> Thank you.
> 
> I thought a bit more during the day and decided to use "x30" directly rather
> than lr. We can decide to revisit it if we think the code is too difficult to
> read.

I was going to suggest x30 too yesterday, but if we can make `lr' work
then that would be my preference because it makes it more immediately
obvious what the code is doing.

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

Re: [Xen-devel] [PATCH] xen-block: support feature-large-sector-size

[Max Reitz]

On 26.06.19 19:19, Anthony PERARD wrote:
> On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
>> On 09.04.19 18:40, Paul Durrant wrote:
>>> A recent Xen commit [1] clarified the semantics of sector based quantities
>>> used in the blkif protocol such that it is now safe to create a xen-block
>>> device with a logical_block_size != 512, as long as the device only
>>> connects to a frontend advertizing 'feature-large-block-size'.
>>>
>>> This patch modifies xen-block accordingly. It also uses a stack variable
>>> for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
>>> of the BlockConf pointer, and changes the parameters of
>>> xen_block_dataplane_create() so that the BlockBackend pointer and sector
>>> size are passed expicitly rather than implicitly via the BlockConf.
>>>
>>> These modifications have been tested against a recent Windows PV XENVBD
>>> driver [2] using a xen-disk device with a 4kB logical block size.
>>>
>>> [1] 
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
>>> [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
>>>
>>> Signed-off-by: Paul Durrant 
>>> ---
>>> Cc: Stefano Stabellini 
>>> Cc: Anthony Perard 
>>> Cc: Stefan Hajnoczi 
>>> Cc: Kevin Wolf 
>>> Cc: Max Reitz 
>>> ---
>>>  hw/block/dataplane/xen-block.c | 25 --
>>>  hw/block/dataplane/xen-block.h |  3 ++-
>>>  hw/block/xen-block.c   | 38 +-
>>>  3 files changed, 40 insertions(+), 26 deletions(-)
>>
>> Thanks, added “by frontend” to the error message and applied to my block
>> branch:
>>
>> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 
> :(, I've just sent a pull request with that patch:
> https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/20190624153257.20163-2-anthony.per...@citrix.com/

That’s just as well, then. :-)

> I guess I need to start sending an email every time I've added a patch
> to my queue.

Well, it certainly won’t hurt.  Although in this cases it’s just a bit
of an unfortunate coincidence that I looked at this patch now when Peter
seems to be away (otherwise I’d have seen it in master).

Max



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Stefano Stabellini]

On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth  wrote:
> > 
> > 
> > 
> > On 25/06/2019, 21:27, "Rich Persaud"  wrote:
> > 
> >> On Jun 25, 2019, at 16:17, Julien Grall  wrote:
> >> 
> >> Hi Rich,
> >> 
> >> On 6/25/19 8:38 PM, Rich Persaud wrote:
>  On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
>  
>  Hi all:
>  please add your agenda items. I had only ONE series which was 
>  highlighted as needing attention from others. Is this seriously the only 
>  one?
> > 
> > We had quite a few additions to the agenda. One problem I have is that 
> > cryptpad history does not tell me who added an agenda item. We will have to 
> > manage this appropriately in the meeting.
> > 
> >>> Proposed agenda item: in the absence of Jira tickets, would it be useful 
> >>> to have a list (e.g. generated by a script) with the lifecycle status of 
> >>> all outstanding patch series, e.g.
> >>> METADATA
> >>> - bug fix / improvement / refactor / cleanup / new feature
> >>> - impacted Xen subsystems/components/features
> >>> - targeted version of Xen
> >>> - contributing person/org
> >>> - relevance of patch series to the goals set by RM for the next Xen 
> >>> release
> >>> - related patch series (with below status info)
> >>> STATUS:
> >>> - patch series version
> >>> - date of patch series v1
> >>> - no responses received + ping count + days since submission + days since 
> >>> ping
> >>> - reviewed with objections
> >>> - reviewed without objections, awaiting ack
> >>> - acked, awaiting merge
> >>> From such a summary, patch series could be prioritized for review/triage 
> >>> in the community call, based on uniform criteria and project-wide context.
> >> 
> >> While I think raising awareness of the stuck series is a good idea. I 
> >> still have some concern regarding the prioritization. Who is going to 
> >> consume the result of the discussion? Is it the maintainers?
> > 
> >   Anyone who typically answers the question raised by Lars in this thread, 
> > presumably a subset of call attendees.
> > 
> > This would only work if there was consensus on the priority amongst the key 
> > stake-holders. I believe that some limited prioritization has happened in 
> > the past, e.g. for some Arm related features for Xen 4.12 where, if I 
> > recall correctly you, Stefano and EPAM did this. 
> > 
> > Maybe we can trial this type of approach for a small number of series 
> > first. At the end of the day this is about queue management. Right now, 
> > when a new series comes in it ends up in one big queue (xen-devel@). Most 
> > complex series have to go through a series of gates (aka code reviews from 
> > different people) before they get applied and when a new version comes out 
> > the series ends up in the queue again: each reviewer today prioritizes 
> > their own review queues, where no-one else sees the prioritisation of other 
> > reviewers. Unless there is lot of spare review capacity (which there isn't) 
> > we essentially end up in grid-lock, with an ever-growing queue. We seem to 
> > have specific additional complexity in Xen because most recent series, 
> > typically involve a large number of reviewers.
> > 
> > In theory, there are several ways to address this:
> > * Queue management either by a set of agreed criteria which all reviewers 
> > follow or through some agreement about which series we actively try and 
> > shepherd through the gates
> > * We have an additional issue that in many areas we have multiple 
> > reviewers/committers reviewing the same area of code, which also frequently 
> > leads to slow-downs, because the multiple reviewers/committers can 
> > disagree. We could look at a model where the reviewers/committers agree 
> > that one takes the lead on reviewing a specific series. We could try and 
> > streamline the ownership structure to create a clearer mapping.
> > * The queues of each reviewer are somehow made public (assuming this is 
> > possible) and we hope that the system self-regulates. Not sure this will 
> > actually work
> > 
> > The big problem I have is that mailing lists really don't lend themselves 
> > well to highlight what is going on. We have been grappling with this for 
> > years and things are getting worse, not better.
> >
> > In past community calls when we tried to do this with specific series, in 
> > practice we ended up discovering obstacles that were concerning a specific 
> > series, such as unexposed dependencies, lack of HW, specs against which to 
> > review being too complex, ...
> > 
> > In any case, given that quite a few series were added to the agenda, maybe 
> > we shouldn't talk about process in the meeting, but see whether we can 
> > unblock those series. I am going to annotate some of the agenda items to 
> > highlight WHO needs to take action on items added
> > 
> > We could have a wider discussion about the process at the summit, as 
> > everyone who would need to be involved is at the summit.
> 

[Xen-devel] [PATCH] xen/Kconfig: Fix -Wformat-security when compiling with Clang

[Andrew Cooper]

Clang observes:

tools/kconfig/conf.c:77:10:
warning: format string is not a string literal (potentially insecure)
  [-Wformat-security]
printf(_("aborted!\n\n"));
   ^

And it is absolutely correct.  gettext() can easily return a string with a %
in.

This could be fixed by switching to using printf("%s", _(...)), or by
switching to puts() (as there is no formatting going on), but the better
option is follow Linux and remove localisation support.

Linux changeset: 694c49a7c01cc87194be40cb26404b58b68c291c
Author: Sam Ravnborg 
Date:   Tue May 22 20:36:12 2018

kconfig: drop localization support

The localization support is broken and appears unused.
There is no google hits on the update-po-config target.
And there is no recent (5 years) activity related to the localization.

So lets just drop this as it is no longer used.

Suggested-by: Ulf Magnusson 
Suggested-by: Masahiro Yamada 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Masahiro Yamada 

[Ported to Xen]
Reported-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
---
CC: Doug Goldstein 
---
 xen/tools/kconfig/.gitignore   |   4 -
 xen/tools/kconfig/Makefile |  39 +-
 xen/tools/kconfig/POTFILES.in  |  12 --
 xen/tools/kconfig/check.sh |  13 --
 xen/tools/kconfig/conf.c   |  57 
 xen/tools/kconfig/confdata.c   |   4 +-
 xen/tools/kconfig/gconf.c  |  46 +++
 xen/tools/kconfig/kxgettext.c  | 235 -
 xen/tools/kconfig/lkc.h|  14 --
 xen/tools/kconfig/lxdialog/checklist.c |   4 +-
 xen/tools/kconfig/lxdialog/dialog.h|   6 -
 xen/tools/kconfig/lxdialog/inputbox.c  |   4 +-
 xen/tools/kconfig/lxdialog/menubox.c   |  10 +-
 xen/tools/kconfig/lxdialog/textbox.c   |   2 +-
 xen/tools/kconfig/lxdialog/yesno.c |   4 +-
 xen/tools/kconfig/mconf.c  | 141 ++--
 xen/tools/kconfig/menu.c   |  18 +--
 xen/tools/kconfig/nconf.c  | 148 ++---
 xen/tools/kconfig/nconf.h  |   1 -
 xen/tools/kconfig/qconf.cc | 112 +++-
 xen/tools/kconfig/zconf.tab.c_shipped  |   2 +-
 xen/tools/kconfig/zconf.y  |   2 +-
 22 files changed, 265 insertions(+), 613 deletions(-)
 delete mode 100644 xen/tools/kconfig/POTFILES.in
 delete mode 100755 xen/tools/kconfig/check.sh
 delete mode 100644 xen/tools/kconfig/kxgettext.c

diff --git a/xen/tools/kconfig/.gitignore b/xen/tools/kconfig/.gitignore
index be603c4fef..ca38e983d6 100644
--- a/xen/tools/kconfig/.gitignore
+++ b/xen/tools/kconfig/.gitignore
@@ -7,9 +7,6 @@ config*
 *.tab.h
 zconf.hash.c
 *.moc
-gconf.glade.h
-*.pot
-*.mo
 
 #
 # configuration programs
@@ -19,4 +16,3 @@ mconf
 nconf
 qconf
 gconf
-kxgettext
diff --git a/xen/tools/kconfig/Makefile b/xen/tools/kconfig/Makefile
index aceaaed098..c8ad69501c 100644
--- a/xen/tools/kconfig/Makefile
+++ b/xen/tools/kconfig/Makefile
@@ -2,7 +2,7 @@
 # Kernel configuration targets
 # These targets are used from top-level makefile
 
-PHONY += xconfig gconfig menuconfig config silentoldconfig update-po-config \
+PHONY += xconfig gconfig menuconfig config silentoldconfig \
localmodconfig localyesconfig
 
 ifdef KBUILD_KCONFIG
@@ -52,29 +52,6 @@ localyesconfig localmodconfig: $(obj)/streamline_config.pl 
$(obj)/conf
fi
$(Q)rm -f .tmp.config
 
-# Create new linux.pot file
-# Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files
-update-po-config: $(obj)/kxgettext $(obj)/gconf.glade.h
-   $(Q)$(kecho) "  GEN config.pot"
-   $(Q)xgettext --default-domain=linux \
-   --add-comments --keyword=_ --keyword=N_ \
-   --from-code=UTF-8   \
-   --files-from=$(srctree)/scripts/kconfig/POTFILES.in \
-   --directory=$(srctree) --directory=$(objtree)   \
-   --output $(obj)/config.pot
-   $(Q)sed -i s/CHARSET/UTF-8/ $(obj)/config.pot
-   $(Q)(for i in `ls $(srctree)/arch/*/Kconfig  \
-   $(srctree)/arch/*/um/Kconfig`;   \
-   do   \
-   $(kecho) "  GEN $$i";\
-   $(obj)/kxgettext $$i \
->> $(obj)/config.pot;   \
-   done )
-   $(Q)$(kecho) "  GEN linux.pot"
-   $(Q)msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \
-   --output $(obj)/linux.pot
-   $(Q)rm -f $(obj)/config.pot
-
 # These targets map 1:1 to the commandline options of 'conf'
 simple-targets := oldconfig allnoconfig allyesconfig allmodconfig \
alldefconfig randconfig listnewconfig olddefconfig
@@ -176,16 +153,14 @@ lxdialog += lxdialog/textbox.o lxdialog/yesno.o 
lxdialog/menubox.o
 conf-objs  := conf.o  zconf.tab.o
 mconf-objs := 

[Xen-devel] [xen-unstable-smoke test] 138559: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

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-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   19 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   18 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH] xen-block: support feature-large-sector-size

[Anthony PERARD]

On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
> On 09.04.19 18:40, Paul Durrant wrote:
> > A recent Xen commit [1] clarified the semantics of sector based quantities
> > used in the blkif protocol such that it is now safe to create a xen-block
> > device with a logical_block_size != 512, as long as the device only
> > connects to a frontend advertizing 'feature-large-block-size'.
> > 
> > This patch modifies xen-block accordingly. It also uses a stack variable
> > for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
> > of the BlockConf pointer, and changes the parameters of
> > xen_block_dataplane_create() so that the BlockBackend pointer and sector
> > size are passed expicitly rather than implicitly via the BlockConf.
> > 
> > These modifications have been tested against a recent Windows PV XENVBD
> > driver [2] using a xen-disk device with a 4kB logical block size.
> > 
> > [1] 
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
> > [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
> > 
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > Cc: Stefan Hajnoczi 
> > Cc: Kevin Wolf 
> > Cc: Max Reitz 
> > ---
> >  hw/block/dataplane/xen-block.c | 25 --
> >  hw/block/dataplane/xen-block.h |  3 ++-
> >  hw/block/xen-block.c   | 38 +-
> >  3 files changed, 40 insertions(+), 26 deletions(-)
> 
> Thanks, added “by frontend” to the error message and applied to my block
> branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block

:(, I've just sent a pull request with that patch:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/20190624153257.20163-2-anthony.per...@citrix.com/

I guess I need to start sending an email every time I've added a patch
to my queue.

Cheers,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] xen-block: support feature-large-sector-size

[Max Reitz]

On 09.04.19 18:40, Paul Durrant wrote:
> A recent Xen commit [1] clarified the semantics of sector based quantities
> used in the blkif protocol such that it is now safe to create a xen-block
> device with a logical_block_size != 512, as long as the device only
> connects to a frontend advertizing 'feature-large-block-size'.
> 
> This patch modifies xen-block accordingly. It also uses a stack variable
> for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
> of the BlockConf pointer, and changes the parameters of
> xen_block_dataplane_create() so that the BlockBackend pointer and sector
> size are passed expicitly rather than implicitly via the BlockConf.
> 
> These modifications have been tested against a recent Windows PV XENVBD
> driver [2] using a xen-disk device with a 4kB logical block size.
> 
> [1] 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
> [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Stefan Hajnoczi 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> ---
>  hw/block/dataplane/xen-block.c | 25 --
>  hw/block/dataplane/xen-block.h |  3 ++-
>  hw/block/xen-block.c   | 38 +-
>  3 files changed, 40 insertions(+), 26 deletions(-)

Thanks, added “by frontend” to the error message and applied to my block
branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 137600
 build-amd64-xsm   6 xen-buildfail REGR. vs. 137600
 build-arm64-xsm   6 xen-buildfail REGR. vs. 137600
 build-arm64   6 xen-buildfail REGR. vs. 137600
 build-i386-xsm6 xen-buildfail REGR. vs. 137600
 build-i3866 xen-buildfail REGR. vs. 137600
 build-armhf   6 xen-buildfail REGR. vs. 137600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64  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-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   

[Xen-devel] [xen-unstable-smoke test] 138557: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   18 attempts
Testing same since   138485  2019-06-25 16:00:57 Z1 days   17 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH] golang/xenlight: Add libxl_utils support

[Wei Liu]

CC George

On Wed, Jun 26, 2019 at 12:27:32PM +0200, Nicolas Belouin wrote:
> The Go bindings for libxl miss functions from libxl_utils, lets start
> with the simple libxl_domid_to_name and its counterpart
> libxl_name_to_domid.
> 
> Signed-off-by: Nicolas Belouin 
> ---
>  tools/golang/xenlight/xenlight_utils.go | 61 +
>  1 file changed, 61 insertions(+)
>  create mode 100644 tools/golang/xenlight/xenlight_utils.go
> 
> diff --git a/tools/golang/xenlight/xenlight_utils.go 
> b/tools/golang/xenlight/xenlight_utils.go
> new file mode 100644
> index 00..ab7a585ec7
> --- /dev/null
> +++ b/tools/golang/xenlight/xenlight_utils.go
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright (C) 2019 Nicolas Belouin, Gandi SAS
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; If not, see 
> .
> + */
> +package xenlight
> +
> +/*
> +#cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
> +#include 
> +#include 
> +*/
> +import "C"
> +
> +/*
> + * Other flags that may be needed at some point:
> + *  -lnl-route-3 -lnl-3
> + *
> + * To get back to static linking:
> + * #cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
> -lxentoollog -lxenevtchn -lxenctrl -lxenforeignmemory -lxencall -lz -luuid 
> -lutil
> + */
> +
> +import (
> + "unsafe"
> +)
> +
> +//char* libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
> +func (Ctx *Context) DomidToName(id Domid) (name string) {
> + cDomName := C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(id))
> + name = C.GoString(cDomName)
> + return
> +}
> +
> +//int libxl_name_to_domid(libxl_ct *ctx, const char *name, uint32_t *domid)
> +func (Ctx *Context) NameToDomid(name string) (id Domid, err error) {
> + cname := C.CString(name)
> + defer C.free(unsafe.Pointer(cname))
> +
> + var cDomId C.uint32_t
> +
> + ret := C.libxl_name_to_domid(Ctx.ctx, cname, )
> + if ret != 0 {
> + err = Error(-ret)
> + return
> + }
> +
> + id = Domid(cDomId)
> +
> + return
> +}
> -- 
> 2.22.0
> 

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

Re: [Xen-devel] [PATCH 4/5] kconfig: disable non-literal format string warnings

[Andrew Cooper]

On 26/06/2019 16:20, Roger Pau Monné wrote:
> On Wed, Jun 26, 2019 at 08:45:27AM -0600, Jan Beulich wrote:
> On 26.06.19 at 15:55,  wrote:
>>> Kconfig makes heavy use of non-literals as format strings, disable
>>> compiler warnings since this is expected usage.
>> I've never seen any with any version of gcc - are there more
>> aspects to be mentioned here?
> Oh, I've always seen them with clang. Not sure why gcc doesn't show
> such warnings.
>
> clang -Wp,-MD,tools/kconfig/.conf.o.d-DCURSES_LOC="" -DLOCALE 
> -DKBUILD_NO_NLS  -c -o tools/kconfig/conf.o tools/kconfig/conf.c
> tools/kconfig/conf.c:77:10: warning: format string is not a string literal 
> (potentially insecure)
>   [-Wformat-security]
> printf(_("aborted!\n\n"));
>^
> tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
> #define _(text) gettext(text)
> ^
> tools/kconfig/conf.c:77:10: note: treat the string as an argument to avoid 
> this
> printf(_("aborted!\n\n"));
>^
>"%s",
> tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
> #define _(text) gettext(text)
> ^
> tools/kconfig/conf.c:78:10: warning: format string is not a string literal 
> (potentially insecure)
>   [-Wformat-security]
> printf(_("Console input/output is redirected. "));
>^
> tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
> #define _(text) gettext(text)
> ^
> tools/kconfig/conf.c:78:10: note: treat the string as an argument to avoid 
> this
> printf(_("Console input/output is redirected. "));
>^
>"%s",
> tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
> #define _(text) gettext(text)
> ^

Clang is correct and GCC is wrong.  This code is plain buggy.

Its trivial to arrange for gettext to return a string with a % in it.

These want fixing to "%s", _(), or to use puts().

It looks like Linux has dropped the use of gettext in the first place. 
Look like c/s 694c49a7c01cc87194be40cb26404b58b68c291c wants backporting.

~Andrew

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

Re: [Xen-devel] xen/arm dts: Check "reg" property length in process_multiboot_node

[Viktor Mitin]

Hi Julien,

Thank you for information provided.
Per the binding, domU1 node should contain the properties
#address-cells and #size-cells.

Adding xen-devel to CC.

Thanks


On Wed, Jun 26, 2019 at 6:42 PM Julien Grall  wrote:
>
>
>
> On 26/06/2019 16:21, Viktor Mitin wrote:
> > Hi All,
>
> Hi,
>
> Would you mind to add xen-devel on CC? This discussion could benefits 
> everyone.
>
> > While setting up dom0less configuration as described in
> > docs/features/dom0less.pandoc
> > it has been found out that Xen doesn't check the length of the DT reg 
> > property.
>
> What do you mean? The panic below clearly shows Xen is checking the length of
> the DT reg property.
>
> > This seems an old issue described in [1]. However, the tests with
> > dom0less domU1 setup show that the issue is still relevant at least in
> > case of xen 4.12:
> >
> >  domU1 {
> >  compatible = "xen,domain";
> >  memory = <0x2>;
> >  cpus = 1;
> >  vpl011;
> >
> >  module@200 {
> >  compatible = "multiboot,kernel", "multiboot,module";
> >  reg = <0x200 0xff>;
> >  bootargs = "console=ttyAMA0";
> >  };
> >
> >  module@3000 {
> >  compatible = "multiboot,ramdisk", "multiboot,module";
> >  reg = <0x300 0xff>;
> >  };
> >  };
> >
> > The reg property in this example doesn't work - Xen panics with it.
> > It should be described as
> > reg = <0x0 0x200 0x0 0xff>;
> > or as
> > #address-cells <1>
> > #size-cells <1>
> > reg = <0x200 0xff>;
> >
> > In other case xen panics on the next code:
> > In xen/arch/arm/bootfdt.c:
> >
> >   if ( len < dt_cells_to_size(address_cells + size_cells) )
> >   panic("fdt: node `%s': `reg` property length is too short\n",
> >   name);
> >
> > Because in case of arm64 dom0less example reg len calculation looks next:
> > len == 8,
> > dt_cells_to_size(address_cells + size_cells) == 16
> > address_cells == 2
> > size_cells == 2
> >
> > Both solutions mentioned above has been tested and works well.
> > The thing is that dom0less documentation has and example which doesn't
> > work in case of arm64 and it should be improved with this information
> > or it needs to fix "reg" property length calculation.
>
> The example in docs/features/dom0less.pandoc does not match the bindings
> described in docs/misc/arm/device-tree/booting.txt.
>
> Per the binding, domU1 node should contain the properties #address-cells and
> #size-cells.
>
> >
> > What do you think?
>
> The code works as expected, however the documentation needs to be updated.
>
> >
> > <1>  
> > https://lists.xenproject.org/archives/html/xen-devel/2013-09/msg00642.html
> >
> > Thanks,
> > Viktor Mitin
> >
>
> --
> Julien Grall

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

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Rich Persaud]

> On Jun 26, 2019, at 06:45, Lars Kurth  wrote:
> 
> 
> 
> On 25/06/2019, 21:27, "Rich Persaud"  wrote:
> 
>> On Jun 25, 2019, at 16:17, Julien Grall  wrote:
>> 
>> Hi Rich,
>> 
>> On 6/25/19 8:38 PM, Rich Persaud wrote:
 On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
 
 Hi all:
 please add your agenda items. I had only ONE series which was highlighted 
 as needing attention from others. Is this seriously the only one?
> 
> We had quite a few additions to the agenda. One problem I have is that 
> cryptpad history does not tell me who added an agenda item. We will have to 
> manage this appropriately in the meeting.
> 
>>> Proposed agenda item: in the absence of Jira tickets, would it be useful to 
>>> have a list (e.g. generated by a script) with the lifecycle status of all 
>>> outstanding patch series, e.g.
>>> METADATA
>>> - bug fix / improvement / refactor / cleanup / new feature
>>> - impacted Xen subsystems/components/features
>>> - targeted version of Xen
>>> - contributing person/org
>>> - relevance of patch series to the goals set by RM for the next Xen release
>>> - related patch series (with below status info)
>>> STATUS:
>>> - patch series version
>>> - date of patch series v1
>>> - no responses received + ping count + days since submission + days since 
>>> ping
>>> - reviewed with objections
>>> - reviewed without objections, awaiting ack
>>> - acked, awaiting merge
>>> From such a summary, patch series could be prioritized for review/triage in 
>>> the community call, based on uniform criteria and project-wide context.
>> 
>> While I think raising awareness of the stuck series is a good idea. I still 
>> have some concern regarding the prioritization. Who is going to consume the 
>> result of the discussion? Is it the maintainers?
> 
>   Anyone who typically answers the question raised by Lars in this thread, 
> presumably a subset of call attendees.
> 
> This would only work if there was consensus on the priority amongst the key 
> stake-holders. I believe that some limited prioritization has happened in the 
> past, e.g. for some Arm related features for Xen 4.12 where, if I recall 
> correctly you, Stefano and EPAM did this. 
> 
> Maybe we can trial this type of approach for a small number of series first. 
> At the end of the day this is about queue management. Right now, when a new 
> series comes in it ends up in one big queue (xen-devel@). Most complex series 
> have to go through a series of gates (aka code reviews from different people) 
> before they get applied and when a new version comes out the series ends up 
> in the queue again: each reviewer today prioritizes their own review queues, 
> where no-one else sees the prioritisation of other reviewers. Unless there is 
> lot of spare review capacity (which there isn't) we essentially end up in 
> grid-lock, with an ever-growing queue. We seem to have specific additional 
> complexity in Xen because most recent series, typically involve a large 
> number of reviewers.
> 
> In theory, there are several ways to address this:
> * Queue management either by a set of agreed criteria which all reviewers 
> follow or through some agreement about which series we actively try and 
> shepherd through the gates
> * We have an additional issue that in many areas we have multiple 
> reviewers/committers reviewing the same area of code, which also frequently 
> leads to slow-downs, because the multiple reviewers/committers can disagree. 
> We could look at a model where the reviewers/committers agree that one takes 
> the lead on reviewing a specific series. We could try and streamline the 
> ownership structure to create a clearer mapping.
> * The queues of each reviewer are somehow made public (assuming this is 
> possible) and we hope that the system self-regulates. Not sure this will 
> actually work
> 
> The big problem I have is that mailing lists really don't lend themselves 
> well to highlight what is going on. We have been grappling with this for 
> years and things are getting worse, not better.
> 
> In past community calls when we tried to do this with specific series, in 
> practice we ended up discovering obstacles that were concerning a specific 
> series, such as unexposed dependencies, lack of HW, specs against which to 
> review being too complex, ...
> 
> In any case, given that quite a few series were added to the agenda, maybe we 
> shouldn't talk about process in the meeting, but see whether we can unblock 
> those series. I am going to annotate some of the agenda items to highlight 
> WHO needs to take action on items added
> 
> We could have a wider discussion about the process at the summit, as everyone 
> who would need to be involved is at the summit.

This has likely been raised before, but ... could the Xen community use 
Github/Gitlab PRs to reduce the overhead of managing a review queue?  PR-based 
workflows have helped open-source projects to better utilize teams for review 
queue 

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

[Julien Grall]

Hi Stefano,

On 26/06/2019 16:27, Stefano Stabellini wrote:

On Wed, 26 Jun 2019, Julien Grall wrote:

Hi Stefano,

On 26/06/2019 00:59, Stefano Stabellini wrote:

On Tue, 25 Jun 2019, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

   The current implementation of the macro PRINT will clobber x30/lr.
This

means the user should save lr if it cares about it.


By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
expression.


No of course not! You meant x30 which is a synonym of lr! It is just
that in this case it is also supposed to clobber x0-x3 -- I got
confused! The commit message is also fine as is then. More below.



Reviewed-by: Stefano Stabellini 



Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve lr,
the macro PRINT is modified to save and restore it.

While the comment state x3 will be clobbered, this is not the case. So
PRINT will use x3 to preserve lr.

Lastly, take the opportunity to move the comment on top of PRINT and use
PRINT in init_uart. Both changes will be helpful in a follow-up patch.

Signed-off-by: Julien Grall 
---
   xen/arch/arm/arm64/head.S | 14 +-
   1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index c8bbdf05a6..a5147c8d80 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -78,12 +78,17 @@
*  x30 - lr
*/
   -/* Macro to print a string to the UART, if there is one.
- * Clobbers x0-x3. */
   #ifdef CONFIG_EARLY_PRINTK
+/*
+ * Macro to print a string to the UART, if there is one.
+ *
+ * Clobbers x0 - x3
+ */
   #define PRINT(_s)   \
+mov   x3, lr  ; \
   adr   x0, 98f ; \
   blputs; \
+mov   lr, x3  ; \
   RODATA_STR(98, _s)


Strangely enough I get a build error with gcc 7.3.1, but if I use x30
instead of lr, it builds fine. Have you seen this before?


Hmmm, I can't to reproduce it even on older compiler (4.9). My guess is not
all the assembler is able to understand "lr".

In the file entry.S we have the following line:

lr  .reqx30 // link register


Could you give a try to add the line in head.S?


That works


Thank you.

I thought a bit more during the day and decided to use "x30" directly rather 
than lr. We can decide to revisit it if we think the code is too difficult to read.


Cheers,
--
Julien Grall

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

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

[Stefano Stabellini]

On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 26/06/2019 00:59, Stefano Stabellini wrote:
> > On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> > > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > > >   The current implementation of the macro PRINT will clobber x30/lr.
> > > > > This
> > > > means the user should save lr if it cares about it.
> > > 
> > > By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
> > > expression.
> > 
> > No of course not! You meant x30 which is a synonym of lr! It is just
> > that in this case it is also supposed to clobber x0-x3 -- I got
> > confused! The commit message is also fine as is then. More below.
> > 
> > 
> > > Reviewed-by: Stefano Stabellini 
> > > 
> > > 
> > > > Follow-up patches will introduce more use of PRINT in place where lr
> > > > should be preserved. Rather than requiring all the users to preserve lr,
> > > > the macro PRINT is modified to save and restore it.
> > > > 
> > > > While the comment state x3 will be clobbered, this is not the case. So
> > > > PRINT will use x3 to preserve lr.
> > > > 
> > > > Lastly, take the opportunity to move the comment on top of PRINT and use
> > > > PRINT in init_uart. Both changes will be helpful in a follow-up patch.
> > > > 
> > > > Signed-off-by: Julien Grall 
> > > > ---
> > > >   xen/arch/arm/arm64/head.S | 14 +-
> > > >   1 file changed, 9 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > > > index c8bbdf05a6..a5147c8d80 100644
> > > > --- a/xen/arch/arm/arm64/head.S
> > > > +++ b/xen/arch/arm/arm64/head.S
> > > > @@ -78,12 +78,17 @@
> > > >*  x30 - lr
> > > >*/
> > > >   -/* Macro to print a string to the UART, if there is one.
> > > > - * Clobbers x0-x3. */
> > > >   #ifdef CONFIG_EARLY_PRINTK
> > > > +/*
> > > > + * Macro to print a string to the UART, if there is one.
> > > > + *
> > > > + * Clobbers x0 - x3
> > > > + */
> > > >   #define PRINT(_s)   \
> > > > +mov   x3, lr  ; \
> > > >   adr   x0, 98f ; \
> > > >   blputs; \
> > > > +mov   lr, x3  ; \
> > > >   RODATA_STR(98, _s)
> > 
> > Strangely enough I get a build error with gcc 7.3.1, but if I use x30
> > instead of lr, it builds fine. Have you seen this before?
> 
> Hmmm, I can't to reproduce it even on older compiler (4.9). My guess is not
> all the assembler is able to understand "lr".
> 
> In the file entry.S we have the following line:
> 
> lr  .reqx30 // link register
> 
> 
> Could you give a try to add the line in head.S?

That works

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

Re: [Xen-devel] [PATCH 4/5] kconfig: disable non-literal format string warnings

[Roger Pau Monné]

On Wed, Jun 26, 2019 at 08:45:27AM -0600, Jan Beulich wrote:
> >>> On 26.06.19 at 15:55,  wrote:
> > Kconfig makes heavy use of non-literals as format strings, disable
> > compiler warnings since this is expected usage.
> 
> I've never seen any with any version of gcc - are there more
> aspects to be mentioned here?

Oh, I've always seen them with clang. Not sure why gcc doesn't show
such warnings.

clang -Wp,-MD,tools/kconfig/.conf.o.d-DCURSES_LOC="" -DLOCALE 
-DKBUILD_NO_NLS  -c -o tools/kconfig/conf.o tools/kconfig/conf.c
tools/kconfig/conf.c:77:10: warning: format string is not a string literal 
(potentially insecure)
  [-Wformat-security]
printf(_("aborted!\n\n"));
   ^
tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
#define _(text) gettext(text)
^
tools/kconfig/conf.c:77:10: note: treat the string as an argument to avoid this
printf(_("aborted!\n\n"));
   ^
   "%s",
tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
#define _(text) gettext(text)
^
tools/kconfig/conf.c:78:10: warning: format string is not a string literal 
(potentially insecure)
  [-Wformat-security]
printf(_("Console input/output is redirected. "));
   ^
tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
#define _(text) gettext(text)
^
tools/kconfig/conf.c:78:10: note: treat the string as an argument to avoid this
printf(_("Console input/output is redirected. "));
   ^
   "%s",
tools/kconfig/lkc.h:34:17: note: expanded from macro '_'
#define _(text) gettext(text)
^
[...]

> 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Doug Goldstein 
> > ---
> >  xen/tools/kconfig/Makefile.kconfig | 5 +
> >  1 file changed, 5 insertions(+)
> 
> You Cc list looks to be too short for this change.

That's what get_maintainer.pl has given me. Maybe the syntax in
MAINTAINERS is not correct, or get_maintainer.pl needs adjustments.

> 
> > --- a/xen/tools/kconfig/Makefile.kconfig
> > +++ b/xen/tools/kconfig/Makefile.kconfig
> > @@ -43,6 +43,11 @@ FORCE:
> >  # Sets toolchain binaries to use
> >  include $(XEN_ROOT)/config/$(shell uname -s).mk
> >  
> > +# Disable format warnings, kconfig makes heavy use of non-literal format
> > +# strings.
> > +HOSTCFLAGS += -Wno-format
> > +HOSTCXXFLAGS += -Wno-format
> 
> But this disables far more warnings than ones for non-literal format
> strings, at least afaict.

Sorry, it should be -Wno-format-security. I think I dropped the
-security part while copying.

Thanks, Roger.

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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Stefano Stabellini]

On Wed, 26 Jun 2019, Juergen Gross wrote:
> On 26.06.19 14:21, Chao Gao wrote:
> > On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
> > > On 24.06.19 20:47, Stefano Stabellini wrote:
> > > > + xen-devel
> > > > 
> > > > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > > > Hi all,
> > > > > 
> > > > > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > > > > x86 with Xen 4.12. It is not easy for me to get access, and especially
> > > > > change components, on this particular system, and I don't have access
> > > > > to
> > > > > other x86 boxes at the moment, so apologies for the partial
> > > > > information
> > > > > report. The setup is as follow:
> > > > > 
> > > > > - two PCI devices have been assigned to a HVM guest, everything is
> > > > > fine
> > > > > - reboot the guest from inside, i.e. `reboot' in Linux
> > > > > - after the reboot completes, only one device is assigned
> > > > > 
> > > > > Before the reboot, I see all the appropriate xenstore entries for both
> > > > > devices. Everything is fine. After the reboot, I can only see the
> > > > > xenstore entries of one device. It is as if the other device
> > > > > "disappeared" without throwing any errors.
> > > > > 
> > > > > Have you seen this before? Do you know if it has been fixed in
> > > > > staging?
> > > > > I noticed this fix which seems to be very relevant:
> > > > > 
> > > > > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
> > > > > 
> > > > > but it is already included in 4.12.
> > > 
> > > Stefano, could you please try the attached patch? It is only compile
> > > tested for now.
> > > 
> > > 
> > > Juergen
> > 
> > > From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001
> > > From: Juergen Gross 
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > Date: Wed, 26 Jun 2019 08:15:28 +0200
> > > Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot
> > > 
> > > After a reboot of a guest only the first pci device configuration will
> > > be retrieved from Xenstore resulting in loss of any further assigned
> > > passed through pci devices.
> > > 
> > > The main reason is that all passed through pci devices reside under a
> > > common root device "0" in Xenstore. So when the device list is rebuilt
> > > from Xenstore after a reboot the sub-devices below that root device
> > > need to be selected instead of using the root device number as a
> > > selector.
> > > 
> > > Fix that by adding a new member to struct libxl_device_type which when
> > > set is used to get the number of devices. Add such a member for pci to
> > > get the correct number of pci devices instead of implying it from the
> > > number of pci root devices (which will always be 1).
> > > 
> > > While at it fix the type of libxl__device_pci_from_xs_be() to match
> > > the one of the .from_xenstore member of struct libxl_device_type. This
> > > fixes a latent bug checking the return value of a function returning
> > > void.
> > > 
> > > Signed-off-by: Juergen Gross 
> > 
> > Tested-by: Chao Gao 
> 
> Thanks!

Thank you very much both of you! I'll let you know if it works.

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

[Xen-devel] [xen-unstable-smoke test] 138555: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z1 days   17 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   16 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-4.6-testing test] 138426: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 
127792
 test-xtf-amd64-amd64-3   108 leak-check/checkfail REGR. vs. 127792
 test-xtf-amd64-amd64-5   108 leak-check/checkfail REGR. vs. 127792
 test-xtf-amd64-amd64-1   108 leak-check/checkfail REGR. vs. 127792
 test-xtf-amd64-amd64-4   108 leak-check/checkfail REGR. vs. 127792
 test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 
127792
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
127792
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 127792
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 127792
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 127792
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
127792
 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 127792
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 127792
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 127792
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 127792
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 127792

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-2  108 leak-check/check fail in 138333 pass in 138426
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1   fail pass in 138333

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   70 xtf/test-hvm64-xsa-278  fail blocked in 127792
 test-xtf-amd64-amd64-1   70 xtf/test-hvm64-xsa-278  fail blocked in 127792
 test-xtf-amd64-amd64-3   107 xtf/test-pv64-xsa-279  fail blocked in 127792
 test-xtf-amd64-amd64-5   107 xtf/test-pv64-xsa-279  fail blocked in 127792
 test-xtf-amd64-amd64-1   107 xtf/test-pv64-xsa-279  fail blocked in 127792
 test-xtf-amd64-amd64-4   107 xtf/test-pv64-xsa-279  fail blocked in 127792
 test-xtf-amd64-amd64-2 70 xtf/test-hvm64-xsa-278 fail in 138333 blocked in 
127792
 test-xtf-amd64-amd64-2 107 xtf/test-pv64-xsa-279 fail in 138333 blocked in 
127792
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 138333 like 
127792
 test-xtf-amd64-amd64-2  87 xtf/test-pv64-pv-fsgsbase fail in 138333 never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail in 138333 
never pass
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 127746
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 127746
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 127746
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 127792
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 127792
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 127792
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 127792
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 127792
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   80 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   87 xtf/test-pv64-pv-fsgsbasefail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   80 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   87 xtf/test-pv64-pv-fsgsbasefail   never pass
 test-xtf-amd64-amd64-1   80 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   87 xtf/test-pv64-pv-fsgsbasefail   never pass
 test-xtf-amd64-amd64-2   80 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   80 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   87 xtf/test-pv64-pv-fsgsbasefail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 

Re: [Xen-devel] [PATCH 4/5] kconfig: disable non-literal format string warnings

[Jan Beulich]

>>> On 26.06.19 at 15:55,  wrote:
> Kconfig makes heavy use of non-literals as format strings, disable
> compiler warnings since this is expected usage.

I've never seen any with any version of gcc - are there more
aspects to be mentioned here?

> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Doug Goldstein 
> ---
>  xen/tools/kconfig/Makefile.kconfig | 5 +
>  1 file changed, 5 insertions(+)

You Cc list looks to be too short for this change.

> --- a/xen/tools/kconfig/Makefile.kconfig
> +++ b/xen/tools/kconfig/Makefile.kconfig
> @@ -43,6 +43,11 @@ FORCE:
>  # Sets toolchain binaries to use
>  include $(XEN_ROOT)/config/$(shell uname -s).mk
>  
> +# Disable format warnings, kconfig makes heavy use of non-literal format
> +# strings.
> +HOSTCFLAGS += -Wno-format
> +HOSTCXXFLAGS += -Wno-format

But this disables far more warnings than ones for non-literal format
strings, at least afaict.

Jan


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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Juergen Gross]

On 26.06.19 16:34, Chao Gao wrote:

On Wed, Jun 26, 2019 at 03:36:35PM +0200, Juergen Gross wrote:

On 26.06.19 14:21, Chao Gao wrote:

On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:

On 24.06.19 20:47, Stefano Stabellini wrote:

+ xen-devel

On Mon, 24 Jun 2019, Stefano Stabellini wrote:

Hi all,

I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular system, and I don't have access to
other x86 boxes at the moment, so apologies for the partial information
report. The setup is as follow:

- two PCI devices have been assigned to a HVM guest, everything is fine
- reboot the guest from inside, i.e. `reboot' in Linux
- after the reboot completes, only one device is assigned

Before the reboot, I see all the appropriate xenstore entries for both
devices. Everything is fine. After the reboot, I can only see the
xenstore entries of one device. It is as if the other device
"disappeared" without throwing any errors.

Have you seen this before? Do you know if it has been fixed in staging?
I noticed this fix which seems to be very relevant:

https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html

but it is already included in 4.12.


Stefano, could you please try the attached patch? It is only compile
tested for now.


Juergen


>From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001

From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson 
Cc: Wei Liu 
Date: Wed, 26 Jun 2019 08:15:28 +0200
Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot

After a reboot of a guest only the first pci device configuration will
be retrieved from Xenstore resulting in loss of any further assigned
passed through pci devices.

The main reason is that all passed through pci devices reside under a
common root device "0" in Xenstore. So when the device list is rebuilt

>from Xenstore after a reboot the sub-devices below that root device

need to be selected instead of using the root device number as a
selector.

Fix that by adding a new member to struct libxl_device_type which when
set is used to get the number of devices. Add such a member for pci to
get the correct number of pci devices instead of implying it from the
number of pci root devices (which will always be 1).

While at it fix the type of libxl__device_pci_from_xs_be() to match
the one of the .from_xenstore member of struct libxl_device_type. This
fixes a latent bug checking the return value of a function returning
void.

Signed-off-by: Juergen Gross 


Tested-by: Chao Gao 


Thanks!



Note that I just tested it on RELEASE-4.12.0, not staging.

I also found USB device would miss across reboot. Is there someone
willing to fix it too?


I'll have a look.



In guest configuration file, it has following two lines:

usbctrl=['type=devicemodel,version=1']
usbdev=['type=hostdev,hostbus=1,hostaddr=3,controller=0,port=1']

Attachments are output of 'xenstore-ls' before and after reboot


Oh, this seems to be an issue related to qemu parameters. The USB
device is completely emulated by the device model, it is not a PV
device.

Not my area of expertise, I guess.


Juergen

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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Chao Gao]

On Wed, Jun 26, 2019 at 03:36:35PM +0200, Juergen Gross wrote:
>On 26.06.19 14:21, Chao Gao wrote:
>>On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
>>>On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel

On Mon, 24 Jun 2019, Stefano Stabellini wrote:
>Hi all,
>
>I might have found a bug with PCI passthrough to a Linux HVM guest on
>x86 with Xen 4.12. It is not easy for me to get access, and especially
>change components, on this particular system, and I don't have access to
>other x86 boxes at the moment, so apologies for the partial information
>report. The setup is as follow:
>
>- two PCI devices have been assigned to a HVM guest, everything is fine
>- reboot the guest from inside, i.e. `reboot' in Linux
>- after the reboot completes, only one device is assigned
>
>Before the reboot, I see all the appropriate xenstore entries for both
>devices. Everything is fine. After the reboot, I can only see the
>xenstore entries of one device. It is as if the other device
>"disappeared" without throwing any errors.
>
>Have you seen this before? Do you know if it has been fixed in staging?
>I noticed this fix which seems to be very relevant:
>
>https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
>
>but it is already included in 4.12.
>>>
>>>Stefano, could you please try the attached patch? It is only compile
>>>tested for now.
>>>
>>>
>>>Juergen
>>
>>>From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001
>>>From: Juergen Gross 
>>>To: xen-devel@lists.xenproject.org
>>>Cc: Ian Jackson 
>>>Cc: Wei Liu 
>>>Date: Wed, 26 Jun 2019 08:15:28 +0200
>>>Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot
>>>
>>>After a reboot of a guest only the first pci device configuration will
>>>be retrieved from Xenstore resulting in loss of any further assigned
>>>passed through pci devices.
>>>
>>>The main reason is that all passed through pci devices reside under a
>>>common root device "0" in Xenstore. So when the device list is rebuilt
>>>from Xenstore after a reboot the sub-devices below that root device
>>>need to be selected instead of using the root device number as a
>>>selector.
>>>
>>>Fix that by adding a new member to struct libxl_device_type which when
>>>set is used to get the number of devices. Add such a member for pci to
>>>get the correct number of pci devices instead of implying it from the
>>>number of pci root devices (which will always be 1).
>>>
>>>While at it fix the type of libxl__device_pci_from_xs_be() to match
>>>the one of the .from_xenstore member of struct libxl_device_type. This
>>>fixes a latent bug checking the return value of a function returning
>>>void.
>>>
>>>Signed-off-by: Juergen Gross 
>>
>>Tested-by: Chao Gao 
>
>Thanks!
>
>>
>>Note that I just tested it on RELEASE-4.12.0, not staging.
>>
>>I also found USB device would miss across reboot. Is there someone
>>willing to fix it too?
>
>I'll have a look.
>

In guest configuration file, it has following two lines:

usbctrl=['type=devicemodel,version=1']
usbdev=['type=hostdev,hostbus=1,hostaddr=3,controller=0,port=1']

Attachments are output of 'xenstore-ls' before and after reboot 

Thanks
Chao

tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   control = ""
feature-poweroff = "1"
feature-reboot = "1"
feature-suspend = "1"
   domid = "0"
   name = "Domain-0"
   device-model = ""
0 = ""
 backends = ""
  console = ""
  vkbd = ""
  qdisk = ""
  9pfs = ""
  qusb = ""
  vfb = ""
  qnic = ""
 state = "running"
37 = ""
 backends = ""
  console = ""
  vkbd = ""
  9pfs = ""
  qusb = ""
 state = "running"
   device = ""
vbd = ""
 51712 = ""
  backend = "/local/domain/0/backend/qdisk/0/51712"
  backend-id = "0"
  state = "3"
  virtual-device = "51712"
  device-type = "disk"
  protocol = "x86_64-abi"
  ring-ref = "8"
  event-channel = "76"
  feature-persistent = "1"
   backend = ""
qdisk = ""
 0 = ""
  51712 = ""
   frontend = "/local/domain/0/device/vbd/51712"
   params = "qcow2:centos.qcow2"
   frontend-id = "0"
   online = "1"
   removable = "0"
   bootable = "1"
   state = "2"
   dev = "xvda"
   type = "qdisk"
   mode = "w"
   device-type = "disk"
   discard-enable = "1"
   feature-flush-cache = "1"
   info = "0"
   max-ring-page-order = "4"
   feature-discard = "1"
   hotplug-status = "connected"
 37 = ""
  51712 = ""
   frontend = "/local/domain/37/device/vbd/51712"
   params = "qcow2:/home/nervalusr/chao/centos.qcow2"
   frontend-id = "37"
   online = "1"
   removable = "0"
   bootable = "1"
   state = "4"
   dev = "xvda"
   type = "qdisk"
   mode = "w"
   device-type = "disk"
   discard-enable = "1"
 

[Xen-devel] [xen-unstable-smoke test] 138550: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z0 days   16 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   15 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] Xen Project Community Call Sign-up-sheet for future calls

[Lars Kurth]

Hi all,

I have been using a probably a fairly old list of people to CC on mail related 
to community calls. If you received this mail and don’t want to be on the CC 
list, please remove your name and e-mail address from the list in 
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

If you want to be on it, please add yourself following the format in the sheet

Going forward, I will use the sign-up sheet for Community call related e-mails. 
The call is normally on the 1st Thursday of every month at @15:00 UTC, except 
in cases where there is a public holiday affecting most of us. In such cases we 
will change the date in the meeting prior to the call. 

Best Regards
Lars

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

[Xen-devel] [PATCH 2/5] kconfig: don't pass ARCH and SRCARCH on the sub-make call

[Roger Pau Monne]

and instead export them from the top-level Xen makefile.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index c80914c31d..3e3d08d1cc 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -21,8 +21,8 @@ MAKEFLAGS += -rR
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
 
-ARCH=$(XEN_TARGET_ARCH)
-SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
s'/arm\(32\|64\)/arm/g')
+export ARCH=$(XEN_TARGET_ARCH)
+export SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
s'/arm\(32\|64\)/arm/g')
 
 # Don't break if the build process wasn't called from the top level
 # we need XEN_TARGET_ARCH to generate the proper config
@@ -267,14 +267,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
randconfig $(notdir $(wildcard arch/$(SRCARCH)/configs/*_defconfig))
 .PHONY: $(kconfig)
 $(kconfig):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" silentoldconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" defconfig
 
 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;
-- 
2.20.1 (Apple Git-117)


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

[Xen-devel] [PATCH 4/5] kconfig: disable non-literal format string warnings

[Roger Pau Monne]

Kconfig makes heavy use of non-literals as format strings, disable
compiler warnings since this is expected usage.

Signed-off-by: Roger Pau Monné 
---
Cc: Doug Goldstein 
---
 xen/tools/kconfig/Makefile.kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/tools/kconfig/Makefile.kconfig 
b/xen/tools/kconfig/Makefile.kconfig
index 138bf3f1b7..763de37a14 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -43,6 +43,11 @@ FORCE:
 # Sets toolchain binaries to use
 include $(XEN_ROOT)/config/$(shell uname -s).mk
 
+# Disable format warnings, kconfig makes heavy use of non-literal format
+# strings.
+HOSTCFLAGS += -Wno-format
+HOSTCXXFLAGS += -Wno-format
+
 # include the original Makefile and Makefile.host from Linux
 include $(src)/Makefile
 include $(src)/Makefile.host
-- 
2.20.1 (Apple Git-117)


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

[Xen-devel] [PATCH 1/5] make: simplify setting HOST{CC/CXX}

[Roger Pau Monne]

Infer the values of HOST{CC/CXX} from CC/CXX if unset, do this in
StdGNU.mk, together with the rest of the toolchain variables.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk| 10 --
 config/StdGNU.mk |  4 
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/Config.mk b/Config.mk
index 417039d7f6..1a1cc09881 100644
--- a/Config.mk
+++ b/Config.mk
@@ -39,22 +39,12 @@ DESTDIR ?= /
 # Allow phony attribute to be listed as dependency rather than fake target
 .PHONY: .phony
 
-# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
-ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
-HOSTCC ?= $(CC)
-HOSTCXX ?= $(CXX)
-endif
-
 # Use Clang/LLVM instead of GCC?
 clang ?= n
 ifeq ($(clang),n)
 gcc := y
-HOSTCC ?= gcc
-HOSTCXX ?= g++
 else
 gcc := n
-HOSTCC ?= clang
-HOSTCXX ?= clang++
 endif
 
 DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard $(DEPS
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 490ebdf23c..7b7dfe0440 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -9,6 +9,10 @@ CC?= $(CROSS_COMPILE)gcc
 CXX   ?= $(CROSS_COMPILE)g++
 LD_LTO?= $(CROSS_COMPILE)ld
 endif
+
+HOSTCC?= $(CC)
+HOSTCXX   ?= $(CXX)
+
 CPP   ?= $(CC) -E
 AR?= $(CROSS_COMPILE)ar
 RANLIB?= $(CROSS_COMPILE)ranlib
-- 
2.20.1 (Apple Git-117)


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

[Xen-devel] [PATCH 0/5] build improvements/fixes after b41666f2c1

[Roger Pau Monne]

Hello,

The following fixes arise from the travis-ci fallout caused by
b41666f2c1 ('config: don't hardcode toolchain binaries'). First patches
aim to simplify and group together the place where toolchain binaries to
be used by the build system. Last patch changes the travis-ci build
script to accommodate the changes introduced by b41666f2c1.

Thanks, Roger.

Roger Pau Monne (5):
  make: simplify setting HOST{CC/CXX}
  kconfig: don't pass ARCH and SRCARCH on the sub-make call
  kconfig: include default toolchain values
  kconfig: disable non-literal format string warnings
  travis: pass a correct CC/CXX if CROSS_COMPILE is defined

 Config.mk  | 10 --
 config/StdGNU.mk   |  4 
 scripts/travis-build   |  8 
 xen/Makefile   | 10 +-
 xen/tools/kconfig/Makefile.kconfig | 12 
 5 files changed, 25 insertions(+), 19 deletions(-)

-- 
2.20.1 (Apple Git-117)


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

[Xen-devel] [PATCH 5/5] travis: pass a correct CC/CXX if CROSS_COMPILE is defined

[Roger Pau Monne]

After b41666f2c1 Xen no longer overwrites the names of the build
toolchain utilities required during the build process, and instead
uses the values from the environment.

In that case, if the user wants to define CC or other variables to
point to specific toolchain utilities to use it must also take into
account that such variables must be prefixed with CROSS_COMPILE, since
Xen will no longer do this.

Fixes: b41666f2c1 ('config: don't hardcode toolchain binaries')
Signed-off-by: Roger Pau Monné 
---
Cc: Doug Goldstein 
---
 scripts/travis-build | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/travis-build b/scripts/travis-build
index 0cb15a89e4..a264e286b2 100755
--- a/scripts/travis-build
+++ b/scripts/travis-build
@@ -1,6 +1,14 @@
 #!/bin/bash -ex
 
+# Set HOST{CC/CXX} in case we are cross building
+export HOSTCC=${CC}
+export HOSTCXX=${CXX}
+# Prefix environment CC/CXX with CROSS_COMPILE if present
+export CC=${CROSS_COMPILE}${CC}
+export CXX=${CROSS_COMPILE}${CXX}
+
 $CC --version
+[[ "${CC}" != "${HOSTCC}" ]] && $HOSTCC --version
 
 # random config or default config
 if [[ "${RANDCONFIG}" == "y" ]]; then
-- 
2.20.1 (Apple Git-117)


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

[Xen-devel] [PATCH 3/5] kconfig: include default toolchain values

[Roger Pau Monne]

Include config/$(OS).mk which contains the default values for the
toolchain variables. This removes the need to pass HOST{CC/CXX} as
parameters from the high level make target.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Doug Goldstein 
---
 xen/Makefile   | 6 +++---
 xen/tools/kconfig/Makefile.kconfig | 7 +++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 3e3d08d1cc..620af7883c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,14 +267,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
randconfig $(notdir $(wildcard arch/$(SRCARCH)/configs/*_defconfig))
 .PHONY: $(kconfig)
 $(kconfig):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" $@
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" silentoldconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig HOSTCC="$(HOSTCC)" 
HOSTCXX="$(HOSTCXX)" defconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig defconfig
 
 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;
diff --git a/xen/tools/kconfig/Makefile.kconfig 
b/xen/tools/kconfig/Makefile.kconfig
index dbd8912015..138bf3f1b7 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -35,15 +35,14 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
 # provide our shell
 CONFIG_SHELL := $(SHELL)
 
-# provide the host compiler
-HOSTCC ?= gcc
-HOSTCXX ?= g++
-
 # force target
 PHONY += FORCE
 
 FORCE:
 
+# Sets toolchain binaries to use
+include $(XEN_ROOT)/config/$(shell uname -s).mk
+
 # include the original Makefile and Makefile.host from Linux
 include $(src)/Makefile
 include $(src)/Makefile.host
-- 
2.20.1 (Apple Git-117)


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

Re: [Xen-devel] [PATCH v2 4/7] Revert "xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests."

[Thomas Gleixner]

On Wed, 26 Jun 2019, Juergen Gross wrote:
> On 24.06.19 14:02, Zhenzhong Duan wrote:
> > This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
> > 
> > Instead we use an unified parameter 'nopv' for all the hypervisor
> > platforms.
> > 
> > Signed-off-by: Zhenzhong Duan 
> > Cc: Boris Ostrovsky 
> > Cc: Juergen Gross 
> > Cc: Stefano Stabellini 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: Borislav Petkov 
> > Cc: xen-devel@lists.xenproject.org
> 
> Reviewed-by: Juergen Gross 

You're really sure that you want to break existing setups which might use
that already?

Command line parameters are ABI. You can map xen_nopv to the new shiny nopv
implementation but removing it?

Your decision, but you've been told :)

Thanks,

tglx

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

[Xen-devel] [PATCH] libxl: fix pci device re-assigning after domain reboot

[Juergen Gross]

After a reboot of a guest only the first pci device configuration will
be retrieved from Xenstore resulting in loss of any further assigned
passed through pci devices.

The main reason is that all passed through pci devices reside under a
common root device "0" in Xenstore. So when the device list is rebuilt
from Xenstore after a reboot the sub-devices below that root device
need to be selected instead of using the root device number as a
selector.

Fix that by adding a new member to struct libxl_device_type which when
set is used to get the number of devices. Add such a member for pci to
get the correct number of pci devices instead of implying it from the
number of pci root devices (which will always be 1).

While at it fix the type of libxl__device_pci_from_xs_be() to match
the one of the .from_xenstore member of struct libxl_device_type. This
fixes a latent bug checking the return value of a function returning
void.

Signed-off-by: Juergen Gross 
Tested-by: Chao Gao 
---
 tools/libxl/libxl_device.c   | 24 +++-
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_pci.c  | 35 ++-
 3 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index db6c0203b7..a2569102ee 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -2026,6 +2026,7 @@ void *libxl__device_list(libxl__gc *gc, const struct 
libxl_device_type *dt,
 char *libxl_path;
 char **dir = NULL;
 unsigned int ndirs = 0;
+unsigned int ndevs = 0;
 int rc;
 
 *num = 0;
@@ -2037,21 +2038,34 @@ void *libxl__device_list(libxl__gc *gc, const struct 
libxl_device_type *dt,
 dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, );
 
 if (dir && ndirs) {
-list = libxl__malloc(NOGC, dt->dev_elem_size * ndirs);
+if (dt->get_num) {
+if (ndirs != 1) {
+LOGD(ERROR, domid, "multiple entries in %s\n", libxl_path);
+rc = ERROR_FAIL;
+goto out;
+}
+rc = dt->get_num(gc, GCSPRINTF("%s/%s", libxl_path, *dir), );
+if (rc) goto out;
+} else {
+ndevs = ndirs;
+}
+list = libxl__malloc(NOGC, dt->dev_elem_size * ndevs);
 item = list;
 
-while (*num < ndirs) {
+while (*num < ndevs) {
 dt->init(item);
-++(*num);
 
 if (dt->from_xenstore) {
+int nr = dt->get_num ? *num : atoi(*dir);
 char *device_libxl_path = GCSPRINTF("%s/%s", libxl_path, *dir);
-rc = dt->from_xenstore(gc, device_libxl_path, atoi(*dir), 
item);
+rc = dt->from_xenstore(gc, device_libxl_path, nr, item);
 if (rc) goto out;
 }
 
 item = (uint8_t *)item + dt->dev_elem_size;
-++dir;
+++(*num);
+if (!dt->get_num)
+++dir;
 }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3be5c644c1..a3102871f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3707,6 +3707,7 @@ typedef void (*device_merge_fn_t)(libxl_ctx *, void *, 
void *);
 typedef int (*device_dm_needed_fn_t)(void *, unsigned);
 typedef void (*device_update_config_fn_t)(libxl__gc *, void *, void *);
 typedef int (*device_update_devid_fn_t)(libxl__gc *, uint32_t, void *);
+typedef int (*device_get_num_fn_t)(libxl__gc *, const char *, unsigned int *);
 typedef int (*device_from_xenstore_fn_t)(libxl__gc *, const char *,
  libxl_devid, void *);
 typedef int (*device_set_xenstore_config_fn_t)(libxl__gc *, uint32_t, void *,
@@ -3730,6 +3731,7 @@ struct libxl_device_type {
 device_dm_needed_fn_t   dm_needed;
 device_update_config_fn_t   update_config;
 device_update_devid_fn_tupdate_devid;
+device_get_num_fn_t get_num;
 device_from_xenstore_fn_t   from_xenstore;
 device_set_xenstore_config_fn_t set_xenstore_config;
 };
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4ec6872798..03beb865d9 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1547,12 +1547,13 @@ int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t 
domid,
 return AO_INPROGRESS;
 }
 
-static void libxl__device_pci_from_xs_be(libxl__gc *gc,
- const char *be_path,
- int nr, libxl_device_pci *pci)
+static int libxl__device_pci_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_devid nr, void *data)
 {
 char *s;
 unsigned int domain = 0, bus = 0, dev = 0, func = 0, vdevfn = 0;
+libxl_device_pci *pci = data;
 
 s = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/dev-%d", be_path, nr));
 

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Juergen Gross]

On 26.06.19 14:21, Chao Gao wrote:

On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:

On 24.06.19 20:47, Stefano Stabellini wrote:

+ xen-devel

On Mon, 24 Jun 2019, Stefano Stabellini wrote:

Hi all,

I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular system, and I don't have access to
other x86 boxes at the moment, so apologies for the partial information
report. The setup is as follow:

- two PCI devices have been assigned to a HVM guest, everything is fine
- reboot the guest from inside, i.e. `reboot' in Linux
- after the reboot completes, only one device is assigned

Before the reboot, I see all the appropriate xenstore entries for both
devices. Everything is fine. After the reboot, I can only see the
xenstore entries of one device. It is as if the other device
"disappeared" without throwing any errors.

Have you seen this before? Do you know if it has been fixed in staging?
I noticed this fix which seems to be very relevant:

https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html

but it is already included in 4.12.


Stefano, could you please try the attached patch? It is only compile
tested for now.


Juergen



From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson 
Cc: Wei Liu 
Date: Wed, 26 Jun 2019 08:15:28 +0200
Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot

After a reboot of a guest only the first pci device configuration will
be retrieved from Xenstore resulting in loss of any further assigned
passed through pci devices.

The main reason is that all passed through pci devices reside under a
common root device "0" in Xenstore. So when the device list is rebuilt
from Xenstore after a reboot the sub-devices below that root device
need to be selected instead of using the root device number as a
selector.

Fix that by adding a new member to struct libxl_device_type which when
set is used to get the number of devices. Add such a member for pci to
get the correct number of pci devices instead of implying it from the
number of pci root devices (which will always be 1).

While at it fix the type of libxl__device_pci_from_xs_be() to match
the one of the .from_xenstore member of struct libxl_device_type. This
fixes a latent bug checking the return value of a function returning
void.

Signed-off-by: Juergen Gross 


Tested-by: Chao Gao 


Thanks!



Note that I just tested it on RELEASE-4.12.0, not staging.

I also found USB device would miss across reboot. Is there someone
willing to fix it too?


I'll have a look.


Juergen

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

Re: [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs

[Andrew Cooper]

On 04/06/2019 13:15, Jan Beulich wrote:
> For find_iommu_for_device() to consistently (independent of ACPI tables)
> return NULL for the PCI devices corresponding to IOMMUs, make sure
> IOMMUs don't get mapped to themselves by ivrs_mappings[].
>
> While amd_iommu_add_device() won't be called for IOMMUs from
> pci_add_device(), as IOMMUs have got marked r/o,
> _setup_hwdom_pci_devices() calls there nevertheless. Avoid issuing the
> bogus debugging only "No iommu for ...; cannot be handed to ..." log
> message as well as the non-debugging "setup ... for ... failed (-19)"
> one.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Chao Gao]

On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
>On 24.06.19 20:47, Stefano Stabellini wrote:
>>+ xen-devel
>>
>>On Mon, 24 Jun 2019, Stefano Stabellini wrote:
>>>Hi all,
>>>
>>>I might have found a bug with PCI passthrough to a Linux HVM guest on
>>>x86 with Xen 4.12. It is not easy for me to get access, and especially
>>>change components, on this particular system, and I don't have access to
>>>other x86 boxes at the moment, so apologies for the partial information
>>>report. The setup is as follow:
>>>
>>>- two PCI devices have been assigned to a HVM guest, everything is fine
>>>- reboot the guest from inside, i.e. `reboot' in Linux
>>>- after the reboot completes, only one device is assigned
>>>
>>>Before the reboot, I see all the appropriate xenstore entries for both
>>>devices. Everything is fine. After the reboot, I can only see the
>>>xenstore entries of one device. It is as if the other device
>>>"disappeared" without throwing any errors.
>>>
>>>Have you seen this before? Do you know if it has been fixed in staging?
>>>I noticed this fix which seems to be very relevant:
>>>
>>>https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
>>>
>>>but it is already included in 4.12.
>
>Stefano, could you please try the attached patch? It is only compile
>tested for now.
>
>
>Juergen

>From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001
>From: Juergen Gross 
>To: xen-devel@lists.xenproject.org
>Cc: Ian Jackson 
>Cc: Wei Liu 
>Date: Wed, 26 Jun 2019 08:15:28 +0200
>Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot
>
>After a reboot of a guest only the first pci device configuration will
>be retrieved from Xenstore resulting in loss of any further assigned
>passed through pci devices.
>
>The main reason is that all passed through pci devices reside under a
>common root device "0" in Xenstore. So when the device list is rebuilt
>from Xenstore after a reboot the sub-devices below that root device
>need to be selected instead of using the root device number as a
>selector.
>
>Fix that by adding a new member to struct libxl_device_type which when
>set is used to get the number of devices. Add such a member for pci to
>get the correct number of pci devices instead of implying it from the
>number of pci root devices (which will always be 1).
>
>While at it fix the type of libxl__device_pci_from_xs_be() to match
>the one of the .from_xenstore member of struct libxl_device_type. This
>fixes a latent bug checking the return value of a function returning
>void.
>
>Signed-off-by: Juergen Gross 

Tested-by: Chao Gao 

Note that I just tested it on RELEASE-4.12.0, not staging.

I also found USB device would miss across reboot. Is there someone
willing to fix it too?

Thanks
Chao

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

[Xen-devel] [xen-unstable-smoke test] 138547: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z2 days
Failing since138482  2019-06-25 15:00:47 Z0 days   15 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   14 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [linux-next test] 138418: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine 11 examine-serial/bootloaderfail  like 138073
 build-armhf-pvops 6 kernel-build fail  like 138073
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138073
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 138073
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 138073
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 138073
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 138073
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 138073
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 138073
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxe2d28c40292bdc35553d599e5bbbeaefbab49416
baseline version:
 linux241e39004581475b2802cd63c111fec43bb0123e

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   138418  2019-06-24 09:19:21 Z2 days1 attempts

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

Re: [Xen-devel] [PATCH] xen/public: arch-arm: Use xen_mk_ullong instead of suffixing value with ULL

[Alexandru Stefan ISAILA]

Looks good to me

> There are a few places in include/public/arch-arm.h that are still
> suffixing immediate with ULL instead of using xen_mk_ullong.
> 
> The latter allows a consumer to easily tweak the header if ULL is not
> supported.
> 
> So switch the remaining users of ULL to xen_mk_ullong.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Alexandru Isaila 

Cheers
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 11/17] xen/arm64: head: Document enable_mmu()

[Julien Grall]

Hi Stefano,

On 26/06/2019 02:03, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

Document the behavior and the main registers usage within enable_mmu().

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 7b92c1c8eb..d673f7c0d8 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -583,6 +583,13 @@ virtphys_clash:
  ret
  ENDPROC(create_page_tables)
  
+/*

+ * Turn on the Data Cache and the MMU. The function will return on the ID
+ * mapping. In other word, the caller is responsible to switch to the runtime
+ * mapping.
+ *
+ * Clobbers x0 - x1
+ */


as it calls PRINT, shouldn't it be x0 - x3?


You are right. I will update the comment.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 10/17] xen/arm64: head: Improve coding style and document create_pages_tables()

[Julien Grall]

Hi Stefano,

On 26/06/2019 02:03, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

Adjust the coding style used in the comments within create_pages_tables()

Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within the function, so it does
not need to be part of the common register.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 34 +++---
  1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index ee0024173e..7b92c1c8eb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -70,7 +70,7 @@
   *  x22 - is_secondary_cpu
   *  x23 - UART address
   *  x24 -
- *  x25 - identity map in place
+ *  x25 -
   *  x26 - skip_zero_bss (boot cpu only)
   *  x27 -
   *  x28 -
@@ -443,16 +443,27 @@ cpu_init:
  ret
  ENDPROC(cpu_init)
  
+/*

+ * Rebuild the boot pagetable's first-level entries. The structure
+ * is described in mm.c.
+ *
+ * After the CPU enables paging it will add the fixmap mapping
+ * to these page tables, however this may clash with the 1:1
+ * mapping. So each CPU must rebuild the page tables here with
+ * the 1:1 in place.
+ *
+ * Inputs:
+ *   x19: paddr(start)
+ *   x20: phys offset


Is x20 actually used?


Yes via the macro load_paddr.



The rest looks fine.



+ * Clobbers x0 - x4, x25
+ *
+ * Register usage within this function:
+ *   x25: Identity map in place
+ */
  create_page_tables:
-/* Rebuild the boot pagetable's first-level entries. The structure
- * is described in mm.c.
- *
- * After the CPU enables paging it will add the fixmap mapping
- * to these page tables, however this may clash with the 1:1
- * mapping. So each CPU must rebuild the page tables here with
- * the 1:1 in place. */
-
-/* If Xen is loaded at exactly XEN_VIRT_START then we don't
+/*
+ * If Xen is loaded at exactly XEN_VIRT_START then we don't
   * need an additional 1:1 mapping, the virtual mapping will
   * suffice.
   */
@@ -476,7 +487,8 @@ create_page_tables:
  cbz   x1, 1f /* It's in slot 0, map in boot_first
* or boot_second later on */
  
-/* Level zero does not support superpage mappings, so we have

+/*
+ * Level zero does not support superpage mappings, so we have
   * to use an extra first level page in which we create a 1GB mapping.
   */
  load_paddr x2, boot_first_id
--
2.11.0



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/public: arch-arm: Use xen_mk_ullong instead of suffixing value with ULL

[Julien Grall]

Hi,

Gentle ping.

Cheers,

On 03/06/2019 17:08, Julien Grall wrote:

There are a few places in include/public/arch-arm.h that are still
suffixing immediate with ULL instead of using xen_mk_ullong.

The latter allows a consumer to easily tweak the header if ULL is not
supported.

So switch the remaining users of ULL to xen_mk_ullong.

Signed-off-by: Julien Grall 
---
  xen/include/public/arch-arm.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eb424e8286..f550137089 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -407,12 +407,12 @@ typedef uint64_t xen_callback_t;
  #define GUEST_GICV3_GICR0_SIZE xen_mk_ullong(0x0100)
  
  /* ACPI tables physical address */

-#define GUEST_ACPI_BASE 0x2000ULL
-#define GUEST_ACPI_SIZE 0x0200ULL
+#define GUEST_ACPI_BASE xen_mk_ullong(0x2000)
+#define GUEST_ACPI_SIZE xen_mk_ullong(0x0200)
  
  /* PL011 mappings */

-#define GUEST_PL011_BASE0x2200ULL
-#define GUEST_PL011_SIZE0x1000ULL
+#define GUEST_PL011_BASExen_mk_ullong(0x2200)
+#define GUEST_PL011_SIZExen_mk_ullong(0x1000)
  
  /*

   * 16MB == 4096 pages reserved for guest to use as a region to map its



--
Julien Grall

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

[Xen-devel] [OSSTEST PATCH] starvation: Do not give up if there are other jobs running

[Ian Jackson]

We want those other jobs to finish so that we can include the time
they took, and the fact that they completed, in our calculations.

Signed-off-by: Ian Jackson 
---
 ts-hosts-allocate-Executive | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 6b3da600..079ef1d1 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -788,9 +788,17 @@ sub starving ($$) {
 my $maxfin=0;
 while (my ($j,$st,$fin) = $starvation_q->fetchrow_array()) {
if ($st eq 'preparing' ||
-   $st eq 'queued' ||
-   $st eq 'running') {
+   $st eq 'queued') {
$w++;
+   } elsif ($st eq 'running') {
+   # We don't quit if there are still jobs running.  Instead
+   # we wait until they are done and then see if how much we
+   # would be delaying their results.  This does mean that a
+   # flight can be kept going, rather than being treated as
+   # starved, by a constant trickle of late jobs.  But that
+   # is indistinguishable from a flight which is at the head
+   # of the queue for a small set of resources.
+   return (0, "job $j status $st, don't give up just yet");
} else {
$d++;
return (0, "job $j status $st but no step finished time!")
-- 
2.11.0


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

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

On 25/06/2019, 21:27, "Rich Persaud"  wrote:

> On Jun 25, 2019, at 16:17, Julien Grall  wrote:
> 
> Hi Rich,
> 
> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>> On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
>>> 
>>> Hi all:
>>> please add your agenda items. I had only ONE series which was 
highlighted as needing attention from others. Is this seriously the only one?

We had quite a few additions to the agenda. One problem I have is that cryptpad 
history does not tell me who added an agenda item. We will have to manage this 
appropriately in the meeting.

>> Proposed agenda item: in the absence of Jira tickets, would it be useful 
to have a list (e.g. generated by a script) with the lifecycle status of all 
outstanding patch series, e.g.
>> METADATA
>> - bug fix / improvement / refactor / cleanup / new feature
>> - impacted Xen subsystems/components/features
>> - targeted version of Xen
>> - contributing person/org
>> - relevance of patch series to the goals set by RM for the next Xen 
release
>> - related patch series (with below status info)
>> STATUS:
>> - patch series version
>> - date of patch series v1
>> - no responses received + ping count + days since submission + days 
since ping
>> - reviewed with objections
>> - reviewed without objections, awaiting ack
>> - acked, awaiting merge
>> From such a summary, patch series could be prioritized for review/triage 
in the community call, based on uniform criteria and project-wide context.
> 
> While I think raising awareness of the stuck series is a good idea. I 
still have some concern regarding the prioritization. Who is going to consume 
the result of the discussion? Is it the maintainers?

Anyone who typically answers the question raised by Lars in this thread, 
presumably a subset of call attendees.

This would only work if there was consensus on the priority amongst the key 
stake-holders. I believe that some limited prioritization has happened in the 
past, e.g. for some Arm related features for Xen 4.12 where, if I recall 
correctly you, Stefano and EPAM did this. 

Maybe we can trial this type of approach for a small number of series first. At 
the end of the day this is about queue management. Right now, when a new series 
comes in it ends up in one big queue (xen-devel@). Most complex series have to 
go through a series of gates (aka code reviews from different people) before 
they get applied and when a new version comes out the series ends up in the 
queue again: each reviewer today prioritizes their own review queues, where 
no-one else sees the prioritisation of other reviewers. Unless there is lot of 
spare review capacity (which there isn't) we essentially end up in grid-lock, 
with an ever-growing queue. We seem to have specific additional complexity in 
Xen because most recent series, typically involve a large number of reviewers.

In theory, there are several ways to address this:
* Queue management either by a set of agreed criteria which all reviewers 
follow or through some agreement about which series we actively try and 
shepherd through the gates
* We have an additional issue that in many areas we have multiple 
reviewers/committers reviewing the same area of code, which also frequently 
leads to slow-downs, because the multiple reviewers/committers can disagree. We 
could look at a model where the reviewers/committers agree that one takes the 
lead on reviewing a specific series. We could try and streamline the ownership 
structure to create a clearer mapping.
* The queues of each reviewer are somehow made public (assuming this is 
possible) and we hope that the system self-regulates. Not sure this will 
actually work

The big problem I have is that mailing lists really don't lend themselves well 
to highlight what is going on. We have been grappling with this for years and 
things are getting worse, not better.

In past community calls when we tried to do this with specific series, in 
practice we ended up discovering obstacles that were concerning a specific 
series, such as unexposed dependencies, lack of HW, specs against which to 
review being too complex, ...

In any case, given that quite a few series were added to the agenda, maybe we 
shouldn't talk about process in the meeting, but see whether we can unblock 
those series. I am going to annotate some of the agenda items to highlight WHO 
needs to take action on items added

We could have a wider discussion about the process at the summit, as everyone 
who would need to be involved is at the summit. 

Regards
Lars



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

Re: [Xen-devel] [PATCH v3] xen/public: arch-arm: Restrict the visibility of struct vcpu_guest_core_regs

[Julien Grall]

Hi,

It looks like I forgot to CC Stefano on this one.

Cheers,

On 06/06/2019 18:10, Julien Grall wrote:

Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.

However, the structure is only needed by the tools and Xen. It is also
not expected to be ever used outside of that context. So we could save us
some headache by only declaring the structure for Xen and tools.

Suggested-by: Andrew Cooper 
Signed-off-by: Julien Grall 

---
 This is a follow-up of the discussion [1].

 [1] <3c245c5b-51c6-1d0e-ad6c-424145731...@arm.com>

 Changes in v3:
 - Avoid introduce a new #ifdef in the header by moving the
 definitions later on.
---
  xen/include/public/arch-arm.h | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eb424e8286..14e4cbad06 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -197,6 +197,18 @@
  } while ( 0 )
  #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
  
+typedef uint64_t xen_pfn_t;

+#define PRI_xen_pfn PRIx64
+#define PRIu_xen_pfn PRIu64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong PRIx64
+
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
  /* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
  # define __DECL_REG(n64, n32) union {  \
@@ -272,18 +284,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
  
  #undef __DECL_REG
  
-typedef uint64_t xen_pfn_t;

-#define PRI_xen_pfn PRIx64
-#define PRIu_xen_pfn PRIu64
-
-/* Maximum number of virtual CPUs in legacy multi-processor guests. */
-/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
-#define XEN_LEGACY_MAX_VCPUS 1
-
-typedef uint64_t xen_ulong_t;
-#define PRI_xen_ulong PRIx64
-
-#if defined(__XEN__) || defined(__XEN_TOOLS__)
  struct vcpu_guest_context {
  #define _VGCF_online   0
  #define VGCF_online(1<<_VGCF_online)



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt

[Julien Grall]

Gentle ping.

Cheers,

On 02/06/2019 11:26, Julien Grall wrote:

While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state.

For host interrupt (i.e routed to Xen), the deactivation of the
interrupt is done at the end of the handling. This can alternatively be
done outside of the handler by calling gic_set_active_state().

At the moment, gic_set_active_state() is only called by the vGIC for
interrupt routed to the guest. It is hard to find a reason for Xen to
directly play with the active state for interrupt routed to Xen.

To simplify the handling of host interrupt, gic_set_activate_state() is
now restricted to interrupts routed to guest.

This means the _IRQ_PENDING logic is now unecessary on Arm as a same
interrupt can never come up while in the loop and nobody should play
with the flag behind our back.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - gic_set_active_state should only be called on interrupt routed
 to guest.
 - Update the commit message
---
  xen/arch/arm/irq.c| 32 ++--
  xen/include/asm-arm/gic.h |  4 
  2 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index c51cf333ce..3877657a52 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -199,6 +199,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
  {
  struct irq_desc *desc = irq_to_desc(irq);
+struct irqaction *action;
  
  perfc_incr(irqs);
  
@@ -242,35 +243,22 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)

  goto out_no_end;
  }
  
-set_bit(_IRQ_PENDING, >status);

-
-/*
- * Since we set PENDING, if another processor is handling a different
- * instance of this same irq, the other processor will take care of it.
- */
-if ( test_bit(_IRQ_DISABLED, >status) ||
- test_bit(_IRQ_INPROGRESS, >status) )
+if ( test_bit(_IRQ_DISABLED, >status) )
  goto out;
  
  set_bit(_IRQ_INPROGRESS, >status);
  
-while ( test_bit(_IRQ_PENDING, >status) )

-{
-struct irqaction *action;
+action = desc->action;
  
-clear_bit(_IRQ_PENDING, >status);

-action = desc->action;
+spin_unlock_irq(>lock);
  
-spin_unlock_irq(>lock);

-
-do
-{
-action->handler(irq, action->dev_id, regs);
-action = action->next;
-} while ( action );
+do
+{
+action->handler(irq, action->dev_id, regs);
+action = action->next;
+} while ( action );
  
-spin_lock_irq(>lock);

-}
+spin_lock_irq(>lock);
  
  clear_bit(_IRQ_INPROGRESS, >status);
  
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h

index fab02f19f7..876727c144 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -400,9 +400,13 @@ static inline unsigned int gic_get_nr_lrs(void)
   * Set the active state of an IRQ. This should be used with care, as this
   * directly forces the active bit, without considering the GIC state machine.
   * For private IRQs this only works for those of the current CPU.
+ *
+ * This should only be called with interrupt routed to guest. The flow
+ * of interrupt routed to Xen any software change of the state.
   */
  static inline void gic_set_active_state(struct irq_desc *irqd, bool state)
  {
+ASSERT(test_bit(_IRQ_GUEST, >status));
  gic_hw_ops->set_active_state(irqd, state);
  }
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH 09/17] xen/arm64: head: Improve coding style and document cpu_init()

[Julien Grall]

Hi Stefano,

On 26/06/2019 02:01, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.

Lastly, document the behavior and the main registers usage within the
function.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 19 ++-
  1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 6aa3148192..ee0024173e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -396,19 +396,26 @@ skip_bss:
  ret
  ENDPROC(zero_bss)
  
+/*

+ * Initialize the processor for turning the MMU on.
+ *
+ * Clobbers x0 - x4


Shouldn't it be x0 - x3?


Yes it should be. I will update the comment.

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH V1] iommu/arm: Add Renesas IPMMU-VMSA support

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

The purpose of this patch is to add IPMMU-VMSA support to Xen on ARM.

The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.

Please note, this driver is supposed to work only with newest
Gen3 SoCs revisions which IPMMU hardware supports stage 2 translation
table format and is able to use CPU's P2M table as is if one is
3-level page table (up to 40 bit IPA).

This driver is based on Linux's IPMMU-VMSA driver from Renesas BSP:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.14.75-ltsi/rcar-3.9.2
and Xen's SMMU driver:
xen/drivers/passthrough/arm/smmu.c

Although Xen driver has a lot in common with Linux driver, it is not
a "direct ported" copy and should be treated as such.

Driver was tested on Gen3 H3 ES3.0 based boards using current staging
(7d1460c xen/arm: optee: fix compilation with GCC 4.8)
in a system with several DMA masters being assigned to different guest domains.

You can find it here:
repo: https://github.com/otyshchenko1/xen.git branch: ipmmu_upstream1

Oleksandr Tyshchenko (1):
  iommu/arm: Add Renesas IPMMU-VMSA support

 xen/arch/arm/platforms/Kconfig   |1 +
 xen/drivers/passthrough/Kconfig  |   13 +
 xen/drivers/passthrough/arm/Makefile |1 +
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 1487 ++
 4 files changed, 1502 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/ipmmu-vmsa.c

-- 
2.7.4


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

[Xen-devel] [PATCH] golang/xenlight: Add libxl_utils support

[Nicolas Belouin]

The Go bindings for libxl miss functions from libxl_utils, lets start
with the simple libxl_domid_to_name and its counterpart
libxl_name_to_domid.

Signed-off-by: Nicolas Belouin 
---
 tools/golang/xenlight/xenlight_utils.go | 61 +
 1 file changed, 61 insertions(+)
 create mode 100644 tools/golang/xenlight/xenlight_utils.go

diff --git a/tools/golang/xenlight/xenlight_utils.go 
b/tools/golang/xenlight/xenlight_utils.go
new file mode 100644
index 00..ab7a585ec7
--- /dev/null
+++ b/tools/golang/xenlight/xenlight_utils.go
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2019 Nicolas Belouin, Gandi SAS
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+package xenlight
+
+/*
+#cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
+#include 
+#include 
+*/
+import "C"
+
+/*
+ * Other flags that may be needed at some point:
+ *  -lnl-route-3 -lnl-3
+ *
+ * To get back to static linking:
+ * #cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
-lxentoollog -lxenevtchn -lxenctrl -lxenforeignmemory -lxencall -lz -luuid 
-lutil
+ */
+
+import (
+   "unsafe"
+)
+
+//char* libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
+func (Ctx *Context) DomidToName(id Domid) (name string) {
+   cDomName := C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(id))
+   name = C.GoString(cDomName)
+   return
+}
+
+//int libxl_name_to_domid(libxl_ct *ctx, const char *name, uint32_t *domid)
+func (Ctx *Context) NameToDomid(name string) (id Domid, err error) {
+   cname := C.CString(name)
+   defer C.free(unsafe.Pointer(cname))
+
+   var cDomId C.uint32_t
+
+   ret := C.libxl_name_to_domid(Ctx.ctx, cname, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   id = Domid(cDomId)
+
+   return
+}
-- 
2.22.0


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

[Xen-devel] [xen-unstable-smoke test] 138542: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days   14 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   13 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [PATCH V1] iommu/arm: Add Renesas IPMMU-VMSA support

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.

Please note, current driver is supposed to work only with newest
Gen3 SoCs revisions which IPMMU hardware supports stage 2 translation
table format and is able to use CPU's P2M table as is if one is
3-level page table (up to 40 bit IPA).

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/platforms/Kconfig   |1 +
 xen/drivers/passthrough/Kconfig  |   13 +
 xen/drivers/passthrough/arm/Makefile |1 +
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 1487 ++
 4 files changed, 1502 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/ipmmu-vmsa.c

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index bc0e9cd..c93a6b2 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -25,6 +25,7 @@ config RCAR3
bool "Renesas RCar3 support"
depends on ARM_64
select HAS_SCIF
+   select IPMMU_VMSA
---help---
Enable all the required drivers for Renesas RCar3
 
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index a3c0649..e57aa29 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -12,4 +12,17 @@ config ARM_SMMU
 
  Say Y here if your SoC includes an IOMMU device implementing the
  ARM SMMU architecture.
+
+config IPMMU_VMSA
+   bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs"
+   default y
+   depends on ARM_64
+   ---help---
+ Support for implementations of the Renesas IPMMU-VMSA found
+ in R-Car Gen3 SoCs.
+
+ Say Y here if you are using newest R-Car Gen3 SoCs revisions which 
IPMMU
+ hardware supports stage 2 translation table format and is able to use
+ CPU's P2M table as is.
+
 endif
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index b3efcfd..40ac7a9 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
 obj-y += iommu.o
 obj-$(CONFIG_ARM_SMMU) += smmu.o
+obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c 
b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
new file mode 100644
index 000..5091c61
--- /dev/null
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -0,0 +1,1487 @@
+/*
+ * xen/drivers/passthrough/arm/ipmmu-vmsa.c
+ *
+ * Driver for the Renesas IPMMU-VMSA found in R-Car Gen3 SoCs.
+ *
+ * The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
+ * which provides address translation and access protection functionalities
+ * to processing units and interconnect networks.
+ *
+ * Please note, current driver is supposed to work only with newest Gen3 SoCs
+ * revisions which IPMMU hardware supports stage 2 translation table format and
+ * is able to use CPU's P2M table as is.
+ *
+ * Based on Linux's IPMMU-VMSA driver from Renesas BSP:
+ *drivers/iommu/ipmmu-vmsa.c
+ * you can found at:
+ *url: git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
+ *branch: v4.14.75-ltsi/rcar-3.9.2
+ *commit: a5266d298124874c2c06b8b13d073f6ecc2ee355
+ * and Xen's SMMU driver:
+ *xen/drivers/passthrough/arm/smmu.c
+ *
+ * Copyright (C) 2016-2019 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
+
+/* Device logger functions */
+#define dev_print(dev, lvl, fmt, ...)\
+printk(lvl "ipmmu: %s: " fmt, dev_name(dev), ## __VA_ARGS__)
+
+#define dev_info(dev, fmt, ...)\
+dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
+#define dev_warn(dev, fmt, ...)\
+dev_print(dev, XENLOG_WARNING, fmt, ## __VA_ARGS__)
+#define dev_err(dev, fmt, ...) \
+dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+#define dev_err_ratelimited(dev, fmt, ...)\
+dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+/*
+ * Gen3 SoCs make use of up to 8 IPMMU contexts (sets of page table) and
+ * these can be managed independently. Each context is mapped to one Xen 
domain.
+ */
+#define 

[Xen-devel] [xen-unstable-coverity test] 138539: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
baseline version:
 xen  11911563610786615c2b3a01cdcaaf09a6f9e38d

Last test of basis   138366  2019-06-23 09:18:37 Z3 days
Testing same since   138539  2019-06-26 09:20:52 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1191156361..85fd4f7a09  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d -> 
coverity-tested/smoke

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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> On 25.06.19 at 17:53,  wrote:
> > Indeed, precisely.  Are happy with me doing a force push now ?
> 
> I think so, yes.

Now done.  I have un-stopped 4.6 and 4.7.  (I don't expect 4.6 to do
anything.)

Ian.

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

Re: [Xen-devel] [PATCH v2 4/7] Revert "xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests."

[Juergen Gross]

On 24.06.19 14:02, Zhenzhong Duan wrote:

This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.

Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org


Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v2 3/7] x86: Add nopv parameter to disable PV extensions

[Juergen Gross]

On 24.06.19 14:02, Zhenzhong Duan wrote:

In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.

However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do it.

There are guest types which just won't work without PV extensions,
like Xen PV, Xen PVH and jailhouse. add a "ignore_nopv" member to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.

There is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.

Suggested-by: Juergen Gross 
Signed-off-by: Zhenzhong Duan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Jan Kiszka 
Cc: Boris Ostrovsky 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org


Reviewed-by: Juergen Gross 


Juergen

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

[Xen-devel] [xen-unstable-smoke test] 138538: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days   13 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   12 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

Re: [Xen-devel] [PATCH 08/17] xen/arm64: head: Rework and document zero_bss()

[Julien Grall]

Hi Stefano,

On 26/06/2019 02:01, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed. It also means that x26 does not need to set and is now only
used by the boot CPU.

Lastly, document the behavior and the main registers usage within the
function.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 87fcd3be6c..6aa3148192 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -71,7 +71,7 @@
   *  x23 - UART address
   *  x24 -
   *  x25 - identity map in place
- *  x26 - skip_zero_bss
+ *  x26 - skip_zero_bss (boot cpu only)


you could remove this, see below...



   *  x27 -
   *  x28 -
   *  x29 -
@@ -313,8 +313,6 @@ GLOBAL(init_secondary)
  sub   x20, x19, x0   /* x20 := phys-offset */
  
  mov   x22, #1/* x22 := is_secondary_cpu */

-/* Boot CPU already zero BSS so skip it on secondary CPUs. */
-mov   x26, #1/* X26 := skip_zero_bss */
  
  mrs   x0, mpidr_el1

  ldr   x13, =(~MPIDR_HWID_MASK)
@@ -337,7 +335,6 @@ GLOBAL(init_secondary)
  PRINT(" booting -\r\n")
  #endif
  blcheck_cpu_mode
-blzero_bss
  blcpu_init
  blcreate_page_tables
  blenable_mmu
@@ -375,6 +372,14 @@ check_cpu_mode:
  b fail
  ENDPROC(check_cpu_mode)
  
+/*

+ * Zero BSS
+ *
+ * Inputs:
+ *   x26: Do we need to zero BSS?
+ *
+ * Clobbers x0 - x3
+ */
  zero_bss:
  /* Zero BSS only when requested */
  cbnz  x26, skip_bss


In the commit message you wrote: "It also means that x26 does not need
to set and is now only used by the boot CPU." I think this statement is
correct, so you could also remove this "cbnz  x26, skip_bss" and also
the skip_bss label below.


I meant x26 does not need to be set on the secondary CPUs. However, we still 
need to keep it for boot CPU as we don't want to zero BSS when booting via EFI.


This is because the EFI stub will store information in BSS. Note that BSS was 
zeroed by EFI loader before hand.


I will reword the commit message.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 06/17] xen/arm64: head: Introduce distinct paths for the boot CPU and secondary CPUs

[Julien Grall]

Hi Stefano,

On 26/06/2019 02:00, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.

In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate functions. Furthermore, the paths for the boot
CPU and secondary CPUs are now distincted and for now will call each


I notice a few typo in my commit message:

s/distincted/distinct/


functions.

Follow-ups will remove unecessary calls and do further improvement


s/unecessary/unnecessary/


+launch:
  PRINT("- Ready -\r\n")
  
  /* The boot CPU should go straight into C now */

@@ -594,7 +635,6 @@ paging:
  dsb   sy /* Ensure completion of TLB flush */
  isb
  
-launch:


Just below PRINT("- Ready -\r\n"), there is still a:

   cbz   x22, launch

moving the launch label up it looks like it will cause an infinite loop?


Urgh. this line is dropped in a later patch, so the issue only would happen 
during bisection.


I will update the code to avoid the infinite loop here.



Everything else looks good, and I like the reorg of the code.


Thank you! I will rework the arm32 code the same way then :).





  ldr   x0, =init_data
  add   x0, x0, #INITINFO_stack /* Find the boot-time stack */
  ldr   x0, [x0]
@@ -609,6 +649,7 @@ launch:
  b start_xen  /* and disappear into the land of C */
  1:
  b start_secondary/* (to the appropriate entry point) */
+ENDPROC(launch)




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 05/17] xen/arm64: head: Introduce print_reg

[Julien Grall]

Hi Stefano,

On 26/06/2019 01:09, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

At the moment, the user should save x30/lr if it cares about it.

Follow-up patches will introduce more use of putn in place where lr
should be preserved.

Furthermore, any user of putn should also move the value to register x0
if it was stored in a different register.

For convenience, a new macro is introduced to print a given register.
The macro will take care for us to move the value to x0 and also
preserve lr.

Lastly the new macro is used to replace all the callsite of putn. This
will simplify rework/review later on.

Note that CurrentEL is now stored in x5 instead of x4 because the latter
will be clobbered by the macro print_reg.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 29 ++---
  1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 84e26582c4..9142b4a774 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -90,8 +90,25 @@
  blputs; \
  mov   lr, x3  ; \
  RODATA_STR(98, _s)
+
+/*
+ * Macro to print the value of register \xb
+ *
+ * Clobbers x0 - x4
+ */
+.macro print_reg xb
+mov   x4, lr
+mov   x0, \xb
+blputn
+mov   lr, x4


I have the same weird issues with my compiler as before, replacing 'lr'
with 'x30' solves the problem.


Can you have a try with the following line?

lr  .reqx30 // link register

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 04/17] xen/arm64: head: Don't "reserve" x24 for the CPUID

[Julien Grall]

Hi Stefano,

On 26/06/2019 01:01, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

After the recent rework, the CPUID is only used at the very beginning of
the secondary CPUs boot path. So there is no need to "reserve" x24 for
he CPUID.


If you are going to resend the series it would probably make sense to
fold it in the previous patch, but it is also OK as is


I am planning to resend the series. So I will fold it.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

[Julien Grall]

Hi Stefano,

On 26/06/2019 00:59, Stefano Stabellini wrote:

On Tue, 25 Jun 2019, Stefano Stabellini wrote:

On Mon, 10 Jun 2019, Julien Grall wrote:

  The current implementation of the macro PRINT will clobber x30/lr. This

means the user should save lr if it cares about it.


By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
expression.


No of course not! You meant x30 which is a synonym of lr! It is just
that in this case it is also supposed to clobber x0-x3 -- I got
confused! The commit message is also fine as is then. More below.



Reviewed-by: Stefano Stabellini 



Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve lr,
the macro PRINT is modified to save and restore it.

While the comment state x3 will be clobbered, this is not the case. So
PRINT will use x3 to preserve lr.

Lastly, take the opportunity to move the comment on top of PRINT and use
PRINT in init_uart. Both changes will be helpful in a follow-up patch.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm64/head.S | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index c8bbdf05a6..a5147c8d80 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -78,12 +78,17 @@
   *  x30 - lr
   */
  
-/* Macro to print a string to the UART, if there is one.

- * Clobbers x0-x3. */
  #ifdef CONFIG_EARLY_PRINTK
+/*
+ * Macro to print a string to the UART, if there is one.
+ *
+ * Clobbers x0 - x3
+ */
  #define PRINT(_s)   \
+mov   x3, lr  ; \
  adr   x0, 98f ; \
  blputs; \
+mov   lr, x3  ; \
  RODATA_STR(98, _s)


Strangely enough I get a build error with gcc 7.3.1, but if I use x30
instead of lr, it builds fine. Have you seen this before?


Hmmm, I can't to reproduce it even on older compiler (4.9). My guess is not all 
the assembler is able to understand "lr".


In the file entry.S we have the following line:

lr  .reqx30 // link register


Could you give a try to add the line in head.S?


The error is:

arm64/head.S: Assembler messages:
arm64/head.S:272: Error: operand 1 must be an integer register -- `mov lr,x3'
[...]
arm64/head.S:272: Error: undefined symbol lr used as an immediate value
[...]



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest

[Juergen Gross]

On 26.06.19 10:56, Zhenzhong Duan wrote:


On 2019/6/25 20:31, Juergen Gross wrote:

On 24.06.19 14:02, Zhenzhong Duan wrote:

PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.

In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the detection of PVH in xen_platform_hvm(),
xen_pvh_domain() could be used for that purpose.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org
---
  arch/x86/xen/enlighten_hvm.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 7fcb4ea..26939e7 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
  #include "mmu.h"
  #include "smp.h"
  +extern bool nopv;
  static unsigned long shared_info_pfn;
    void xen_hvm_init_shared_info(void)
@@ -226,20 +227,24 @@ static uint32_t __init xen_platform_hvm(void)
  if (xen_pv_domain())
  return 0;
  +#ifdef CONFIG_XEN_PVH
+    /* Test for PVH domain (PVH boot path taken overrides ACPI 
flags). */

+    if (!x86_platform.legacy.rtc && x86_platform.legacy.no_vga)
+    xen_pvh = true;


Sorry, this won't work, as ACPI tables are scanned only some time later.

Hmm, right. Thanks for point out.


You can test for xen_pvh being true here (for the case where the guest
has been booted via the Xen-PVH boot entry) and handle that case, but
the case of a PVH guest started via the normal boot entry (like via
grub2) and nopv specified is difficult. The only idea I have right now
would be to use another struct hypervisor_x86 for that case which will
only be used for Xen HVM/PVH _and_ nopv specified. It should be a copy
of the bare metal variant, but a special guest_late_init member issuing
a big fat warning in case PVH is being detected.


After that warning, I guess PVH will run into hang finally? If it's 
true, BUG() is better?


Adding another hypervisor_x86 is a bit redundant, I think of below change.

I'll test it tomorrow. But appreciate your suggestion whether it's 
feasible. Thanks


Yes, this seems to be a viable option.



--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
  #include "mmu.h"
  #include "smp.h"

+extern bool nopv;
  static unsigned long shared_info_pfn;

  void xen_hvm_init_shared_info(void)
@@ -221,11 +222,37 @@ bool __init xen_hvm_need_lapic(void)
     return true;
  }

+static __init void xen_hvm_nopv_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+   if (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga)
+   return;
+
+   /* PVH detected. */
+   xen_pvh = true;
+
+   printk(KERN_CRIT "nopv parameter isn't supported in PVH guest\n");
+   BUG();
+#endif
+}
+
+
  static uint32_t __init xen_platform_hvm(void)
  {
     if (xen_pv_domain())
     return 0;

+   if (xen_pvh_domain() && nopv)
+   {
+   /* guest booting via the Xen-PVH boot entry goes here */


Mind adjusting indentation of that comment?

+   printk(KERN_INFO "nopv parameter is ignored in PVH 
guest\n");

+   }
+   else if (nopv)
+   {
+   /* guest booting via normal boot entry (like via grub2) goes 
here */


Same again?

With those corrected and no other changes you can add my:

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest

[Zhenzhong Duan]

On 2019/6/25 20:31, Juergen Gross wrote:

On 24.06.19 14:02, Zhenzhong Duan wrote:

PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.

In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the detection of PVH in xen_platform_hvm(),
xen_pvh_domain() could be used for that purpose.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org
---
  arch/x86/xen/enlighten_hvm.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 7fcb4ea..26939e7 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
  #include "mmu.h"
  #include "smp.h"
  +extern bool nopv;
  static unsigned long shared_info_pfn;
    void xen_hvm_init_shared_info(void)
@@ -226,20 +227,24 @@ static uint32_t __init xen_platform_hvm(void)
  if (xen_pv_domain())
  return 0;
  +#ifdef CONFIG_XEN_PVH
+    /* Test for PVH domain (PVH boot path taken overrides ACPI 
flags). */

+    if (!x86_platform.legacy.rtc && x86_platform.legacy.no_vga)
+    xen_pvh = true;


Sorry, this won't work, as ACPI tables are scanned only some time later.

Hmm, right. Thanks for point out.


You can test for xen_pvh being true here (for the case where the guest
has been booted via the Xen-PVH boot entry) and handle that case, but
the case of a PVH guest started via the normal boot entry (like via
grub2) and nopv specified is difficult. The only idea I have right now
would be to use another struct hypervisor_x86 for that case which will
only be used for Xen HVM/PVH _and_ nopv specified. It should be a copy
of the bare metal variant, but a special guest_late_init member issuing
a big fat warning in case PVH is being detected.


After that warning, I guess PVH will run into hang finally? If it's 
true, BUG() is better?


Adding another hypervisor_x86 is a bit redundant, I think of below change.

I'll test it tomorrow. But appreciate your suggestion whether it's 
feasible. Thanks


--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
 #include "mmu.h"
 #include "smp.h"

+extern bool nopv;
 static unsigned long shared_info_pfn;

 void xen_hvm_init_shared_info(void)
@@ -221,11 +222,37 @@ bool __init xen_hvm_need_lapic(void)
    return true;
 }

+static __init void xen_hvm_nopv_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+   if (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga)
+   return;
+
+   /* PVH detected. */
+   xen_pvh = true;
+
+   printk(KERN_CRIT "nopv parameter isn't supported in PVH guest\n");
+   BUG();
+#endif
+}
+
+
 static uint32_t __init xen_platform_hvm(void)
 {
    if (xen_pv_domain())
    return 0;

+   if (xen_pvh_domain() && nopv)
+   {
+   /* guest booting via the Xen-PVH boot entry goes here */
+   printk(KERN_INFO "nopv parameter is ignored in PVH 
guest\n");

+   }
+   else if (nopv)
+   {
+   /* guest booting via normal boot entry (like via grub2) goes here */
+   x86_init.hyper.guest_late_init = 
xen_hvm_nopv_guest_late_init;

+   return 0;
+   }
    return xen_cpuid_base();
 }

@@ -258,4 +285,5 @@ static __init void xen_hvm_guest_late_init(void)
    .init.init_mem_mapping  = xen_hvm_init_mem_mapping,
    .init.guest_late_init   = xen_hvm_guest_late_init,
    .runtime.pin_vcpu   = xen_pin_vcpu,
+   .ignore_nopv    = true,
 };


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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

[Jan Beulich]

>>> On 25.06.19 at 17:53,  wrote:
> Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> I've taken a look. The guests now triple fault during BIOS initialization:
> 
> Thanks.  Hrm.
> 
>> I wouldn't be surprised if the rombios build is broken - did you happen
>> to compare those binaries? Otoh I can't seem to spot any fixes in
>> master that would look like possibly addressing build issues with a
>> newer tool chain (other than cases where the build itself would fail).
> 
> No, I haven't compared the rombios binaries.
> 
>> Irrespective of this I'm not really opposed to a force push as you've
>> suggested, despite being afraid that this may hide an actual issue.
>> That's even more so that by now 4.7 has gone out of security
>> support, and hence we only need it now for 4.8's -prev tests.
> 
> Indeed, precisely.  Are happy with me doing a force push now ?

I think so, yes.

Jan



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

[Xen-devel] [xen-unstable-smoke test] 138537: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days   12 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   11 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-unstable-smoke test] 138531: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days   11 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days   10 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich 

[Xen-devel] [xen-4.7-testing test] 138414: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-prev   6 xen-buildfail REGR. vs. 133596
 build-amd64-prev  6 xen-buildfail REGR. vs. 133596

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-3   70 xtf/test-hvm64-xsa-278 fail pass in 138307
 test-xtf-amd64-amd64-4   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 138307

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-3  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 133596
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133596
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133596
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133596
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133596
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133596
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133596
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133596
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133596
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133596
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 133596
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  e3b4ec6dc77acc13b603497185086cfa96749d19
baseline 

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Juergen Gross]

On 24.06.19 20:47, Stefano Stabellini wrote:

+ xen-devel

On Mon, 24 Jun 2019, Stefano Stabellini wrote:

Hi all,

I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular system, and I don't have access to
other x86 boxes at the moment, so apologies for the partial information
report. The setup is as follow:

- two PCI devices have been assigned to a HVM guest, everything is fine
- reboot the guest from inside, i.e. `reboot' in Linux
- after the reboot completes, only one device is assigned

Before the reboot, I see all the appropriate xenstore entries for both
devices. Everything is fine. After the reboot, I can only see the
xenstore entries of one device. It is as if the other device
"disappeared" without throwing any errors.

Have you seen this before? Do you know if it has been fixed in staging?
I noticed this fix which seems to be very relevant:

https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html

but it is already included in 4.12.


Stefano, could you please try the attached patch? It is only compile
tested for now.


Juergen
>From ea95dcdfc60a895cc43baf34c8e0fb088e10008d Mon Sep 17 00:00:00 2001
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson 
Cc: Wei Liu 
Date: Wed, 26 Jun 2019 08:15:28 +0200
Subject: [PATCH] libxl: fix pci device re-assigning after domain reboot

After a reboot of a guest only the first pci device configuration will
be retrieved from Xenstore resulting in loss of any further assigned
passed through pci devices.

The main reason is that all passed through pci devices reside under a
common root device "0" in Xenstore. So when the device list is rebuilt
from Xenstore after a reboot the sub-devices below that root device
need to be selected instead of using the root device number as a
selector.

Fix that by adding a new member to struct libxl_device_type which when
set is used to get the number of devices. Add such a member for pci to
get the correct number of pci devices instead of implying it from the
number of pci root devices (which will always be 1).

While at it fix the type of libxl__device_pci_from_xs_be() to match
the one of the .from_xenstore member of struct libxl_device_type. This
fixes a latent bug checking the return value of a function returning
void.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl_device.c   | 24 +++-
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_pci.c  | 35 ++-
 3 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index db6c0203b7..a2569102ee 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -2026,6 +2026,7 @@ void *libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
 char *libxl_path;
 char **dir = NULL;
 unsigned int ndirs = 0;
+unsigned int ndevs = 0;
 int rc;
 
 *num = 0;
@@ -2037,21 +2038,34 @@ void *libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
 dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, );
 
 if (dir && ndirs) {
-list = libxl__malloc(NOGC, dt->dev_elem_size * ndirs);
+if (dt->get_num) {
+if (ndirs != 1) {
+LOGD(ERROR, domid, "multiple entries in %s\n", libxl_path);
+rc = ERROR_FAIL;
+goto out;
+}
+rc = dt->get_num(gc, GCSPRINTF("%s/%s", libxl_path, *dir), );
+if (rc) goto out;
+} else {
+ndevs = ndirs;
+}
+list = libxl__malloc(NOGC, dt->dev_elem_size * ndevs);
 item = list;
 
-while (*num < ndirs) {
+while (*num < ndevs) {
 dt->init(item);
-++(*num);
 
 if (dt->from_xenstore) {
+int nr = dt->get_num ? *num : atoi(*dir);
 char *device_libxl_path = GCSPRINTF("%s/%s", libxl_path, *dir);
-rc = dt->from_xenstore(gc, device_libxl_path, atoi(*dir), item);
+rc = dt->from_xenstore(gc, device_libxl_path, nr, item);
 if (rc) goto out;
 }
 
 item = (uint8_t *)item + dt->dev_elem_size;
-++dir;
+++(*num);
+if (!dt->get_num)
+++dir;
 }
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3be5c644c1..a3102871f3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3707,6 +3707,7 @@ typedef void (*device_merge_fn_t)(libxl_ctx *, void *, void *);
 typedef int (*device_dm_needed_fn_t)(void *, unsigned);
 typedef void (*device_update_config_fn_t)(libxl__gc *, void *, void *);
 typedef int (*device_update_devid_fn_t)(libxl__gc *, uint32_t, void *);
+typedef int (*device_get_num_fn_t)(libxl__gc *, const char *, unsigned int