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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00bcb5c27a5bb781099482c5763937334be91e76
baseline version:
 ovmf 7822a1d91d53e80525f571183a24d54488f5437f

Last test of basis   100541  2016-08-18 09:15:15 Z0 days
Testing same since   100552  2016-08-19 03:16:58 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=00bcb5c27a5bb781099482c5763937334be91e76
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
00bcb5c27a5bb781099482c5763937334be91e76
+ branch=ovmf
+ revision=00bcb5c27a5bb781099482c5763937334be91e76
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x00bcb5c27a5bb781099482c5763937334be91e76 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [xen-unstable baseline-only test] 67556: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67556 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67556/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/checkfail REGR. vs. 67551
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 67551
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 67551
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install  fail REGR. vs. 67551

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 67551
 build-i386-rumpuserxen6 xen-buildfail   like 67551
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67551
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67551

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952
baseline version:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a

Last test of basis67551  2016-08-17 22:24:23 Z1 days
Testing same since67556  2016-08-18 11:47:17 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Lars Kurth 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7822a1d91d53e80525f571183a24d54488f5437f
baseline version:
 ovmf 7503cd70fb864a5663edb121c9b2488b4c69e7f5

Last test of basis67553  2016-08-18 05:22:29 Z0 days
Testing same since67557  2016-08-18 17:21:52 Z0 days1 attempts


People who touched revisions under test:
  Eugene Cohen 
  Jiaxin Wu 
  Prince Agyeman 
  Star Zeng 
  Zhang Lubo 

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



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

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

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


Push not applicable.


commit 7822a1d91d53e80525f571183a24d54488f5437f
Author: Jiaxin Wu 
Date:   Mon Aug 15 11:49:56 2016 +0800

NetworkPkg/IpSecDxe: Fix wrong IKE header "FLAG" update

*v2: update the commit log and refine the code comments.

There are three kinds of IKE Exchange process:
#1. Initial Exchange
#2. CREATE_CHILD_SA_Exchange
#3. Information Exchange

The IKE header "FLAG" update is incorrect in #2 and #3 exchange,
which may cause the continue session failure. This patch is used
to correct the updates of IKE header "FLAG" according the RFC4306
section 3.1.

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

commit 40b83d6114f55ed975d9d632f0cd9679781c64e0
Author: Jiaxin Wu 
Date:   Mon Aug 15 11:27:59 2016 +0800

NetworkPkg/IpSecDxe: Fix UEFI IKE Initial Exchange failure

*v2: update the commit log.

IKE Initial Exchange message should cover below process:
   InitiatorResponder
Message1 HDR,SAil,KEi,Ni  -->
Message2  <--   HDR,SArl,KEr,Nr,[CERTREQ]
Message3 HDR,SK{} -->
Message4  <--   HDR,SK{}

If Initial Exchange message is initiated by Linux IKE, it works well.
But the failure will happen if it's initiated by UEFI IKE. This issue
is caused by the no status check of NotifyCookiePayload.

While parsing the IKEv2 packet for IKE_SA_INIT exchange, if the packet
doesn't contain COOKIE Notify payload, EFI_INVALID_PARAMETER will be
returned from Ikev2ParserNotifyCookiePayload(). Current implementation
return this error status directly, then the session will be broken. The
correct behavior should check this status. If no COOKIE Notify payload,
initiator don't need to retry the IKE_SA_INIT.

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

commit efe3f0099c0b986a01c2e8c7ca8ceacedcc965ba
Author: Prince Agyeman 
Date:   Wed Aug 17 10:55:22 2016 -0700

CorebootPayloadPkg: fixed GCC49 and GCC5 hang in PeiCore

Section alignment of .data in GCC49 and GCC5 are 0x40
rather than 0x20 in GCC48 and below.
This causes a hang in PeiCore.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Prince Agyeman 
Reviewed by: Maurice Ma 

commit 617ef660f2e095310bd08d55248bd859908fecf2
Author: Prince Agyeman 
Date:   Wed Aug 17 09:32:12 2016 -0700

CorebootPayloadPkg 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100528
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100528
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100528

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

version targeted for testing:
 qemuu02b1ad881cbb1795029737a9077db60267dc0c6f
baseline version:
 qemuu5f0e775348082c355769a3df612e055abea61c06

Last test of basis   100528  2016-08-17 07:58:34 Z1 days
Failing since100542  2016-08-18 10:13:31 Z0 days2 attempts
Testing same since   100546  2016-08-18 15:18:29 Z0 days1 attempts


People who touched revisions under test:
  Denis V. Lunev 
  Dmitry Fleytman 
  Evgeny Yakovlev 
  Fam Zheng 
  Jason Wang 
  Li Qiang 
  Li Zhijian 
  Peter Maydell 
  Prasad J Pandit 
  Stefan Hajnoczi 
  Zhang Chen 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67549
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67549

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

version targeted for testing:
 qemuu5f0e775348082c355769a3df612e055abea61c06
baseline version:
 qemuuf3b9e787aee6ef7d216b616675db0f1c124da5e4

Last test of basis67549  2016-08-17 08:17:05 Z1 days
Testing same since67555  2016-08-18 08:46:39 Z0 days1 attempts


People who touched revisions under test:
  Chanho Park 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Eduardo Habkost 
  Kevin Wolf 
  Marc-André Lureau 
  Max Reitz 
  Michal Privoznik 
  Peter Maydell 
  Peter Xu 
  Thomas Huth 

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

[Xen-devel] [xen-unstable test] 100544: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100537
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100537
 build-amd64-rumpuserxen   6 xen-buildfail  like 100539
 build-i386-rumpuserxen6 xen-buildfail  like 100539
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100539
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100539
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100539
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100539

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

version targeted for testing:
 xen  361db13b0380a3462f788d44076f42f6f155e719
baseline version:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952

Last test of basis   100539  2016-08-18 05:15:52 Z0 days
Testing same since   100544  2016-08-18 13:44:07 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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

Re: [Xen-devel] [PATCHv2] x86: Add a tboot Kconfig option

[Doug Goldstein]

On 8/18/16 6:44 PM, Derek Straka wrote:
> Allows for the conditional inclusion of tboot related functionality
> via Kconfig
> 
> The default configuration for the new CONFIG_TBOOT option is 'y', so the
> behavior out of the box remains unchanged.  The addition of the option allows
> advanced users to disable system behaviors associated with tboot at compile
> time rather than relying on the run-time detection and configuration.
> 
> The CONFIG_CRYPTO option is 'n' by default and selected by the individual 
> users
> that require the functionality.  Currently, the only user is tboot.
> 
> Signed-off-by: Derek Straka 
> ---

Reviewed-by: Doug Goldstein 


>  
> +config CRYPTO
> + bool
> + default n
> +

If a v3 happens (or the committer wants to change it) this can be
"def_bool n".

-- 
Doug Goldstein



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

[Xen-devel] [PATCHv2] x86: Add a tboot Kconfig option

[Derek Straka]

Allows for the conditional inclusion of tboot related functionality
via Kconfig

The default configuration for the new CONFIG_TBOOT option is 'y', so the
behavior out of the box remains unchanged.  The addition of the option allows
advanced users to disable system behaviors associated with tboot at compile
time rather than relying on the run-time detection and configuration.

The CONFIG_CRYPTO option is 'n' by default and selected by the individual users
that require the functionality.  Currently, the only user is tboot.

Signed-off-by: Derek Straka 
---
 xen/Rules.mk|  2 +-
 xen/arch/x86/Kconfig| 11 +++
 xen/arch/x86/Makefile   |  2 +-
 xen/common/Kconfig  |  4 
 xen/include/asm-x86/tboot.h | 16 
 5 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index ebe1dc0..a190ff0 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -44,7 +44,7 @@ ALL_OBJS-y   += $(BASEDIR)/common/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/drivers/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
-ALL_OBJS-$(CONFIG_X86)   += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(CONFIG_CRYPTO)   += $(BASEDIR)/crypto/built_in.o
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index c1e9279..265fd79 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -76,6 +76,17 @@ config HVM_FEP
  for use in production.
 
  If unsure, say N.
+
+config TBOOT
+   def_bool y
+   prompt "Xen tboot support" if EXPERT = "y"
+   depends on X86
+   select CRYPTO
+   ---help---
+ Allows support for Trusted Boot using the Intel(R) Trusted Execution
+ Technology (TXT)
+
+ If unsure, say Y.
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b18f033..5b9e9da 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -62,7 +62,7 @@ obj-y += trace.o
 obj-y += traps.o
 obj-y += usercopy.o
 obj-y += x86_emulate.o
-obj-y += tboot.o
+obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 51afa24..e2dd89f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -218,6 +218,10 @@ config SCHED_DEFAULT
 
 endmenu
 
+config CRYPTO
+   bool
+   default n
+
 # Enable/Disable live patching support
 config LIVEPATCH
bool "Live patching support (TECH PREVIEW)"
diff --git a/xen/include/asm-x86/tboot.h b/xen/include/asm-x86/tboot.h
index d242862..59ed449 100644
--- a/xen/include/asm-x86/tboot.h
+++ b/xen/include/asm-x86/tboot.h
@@ -119,6 +119,7 @@ typedef struct __packed {
 
 extern tboot_shared_t *g_tboot_shared;
 
+#ifdef CONFIG_TBOOT
 void tboot_probe(void);
 void tboot_shutdown(uint32_t shutdown_type);
 int tboot_in_measured_env(void);
@@ -127,6 +128,21 @@ int tboot_parse_dmar_table(acpi_table_handler 
dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
 int tboot_wake_ap(int apicid, unsigned long sipi_vec);
+#else
+static inline void tboot_probe(void) {}
+static inline void tboot_shutdown(uint32_t shutdown_type) {}
+static inline int tboot_in_measured_env(void) { return 0; }
+static inline int tboot_protect_mem_regions(void) { return 1; }
+
+static inline int tboot_parse_dmar_table(acpi_table_handler dmar_handler)
+{
+return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
+}
+
+static inline int tboot_s3_resume(void) { return 0; }
+static inline void tboot_s3_error(int error) {}
+static inline int tboot_wake_ap(int apicid, unsigned long sipi_vec) { return 
1; }
+#endif /* CONFIG_TBOOT */
 
 #endif /* __TBOOT_H__ */
 
-- 
1.9.1


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

Re: [Xen-devel] unable start xen in hikey

[Kamenee Arumugam]

Yes, I did try "make dtbs" too, but no difference and it doesn't generate
.dtb file. here is the cmd I used:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image  dtbs


Thanks,
Kamenee

On Thu, Aug 18, 2016 at 5:22 PM, Meng Xu  wrote:

> On Thu, Aug 18, 2016 at 5:11 PM, Kamenee Arumugam
>  wrote:
> > Hi Konrad,
> >
> > I have already specified that in my xen.cfg :
> >
> > options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
> > dtuart=/smb/uart@f7113000
> > kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
> > dtb=hi6220-hikey.dtb
> >
> > Chen,
> >
> > I am using linux kernel from 96 boards repo:
> > https://github.com/96boards/linux.git and I compile using this command
> as
> > below:
> >
> > make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> >
> > There was no dtb file produced after the compilation finished. But i saw
> a
> > trace log mentioning , make: Nothing to be done for
> > `arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts'.
> >
> >  Correct me if the make command above is wrong?
>
> Then did you compile the device tree using command "make dtbs" as I
> mentioned in previous email?
>
>
> Meng
> >
> >
> > Thanks,
> > Kamenee
> >
> > On Thu, Aug 18, 2016 at 3:46 PM, Konrad Rzeszutek Wilk
> >  wrote:
> >>
> >> On Wed, Aug 17, 2016 at 06:30:23PM -0400, Kamenee Arumugam wrote:
> >> > Hi Chen,
> >> >
> >> > My previous issue was resolved when i used hi6220-hikey.dtb from this
> >> > source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
> >> > download linux kernel, there doesn't seems to contain
> hi6220-hikey.dtb.
> >> >
> >> > But now it got stuck while loading Dom0 and below are log traces:
> >> >
> >> >
> >> > (XEN) *** LOADING DOMAIN 0 ***
> >> > (XEN) Loading kernel from boot module @ 7a037000
> >> > (XEN) Loading ramdisk from boot module @ 0ae0
> >> > (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> >> > (XEN) BANK[0] 0x004000-0x006000 (512MB)
> >> > (XEN) Grant table range: 0x0005c0-0x0005c54000
> >> > (XEN) Loading zImage from 7a037000 to
> >> > 4008-40ce8c00
> >> > (XEN) Loading dom0 initrd from 0ae0 to
> >> > 0x4820-0x48a0
> >> > (XEN) Allocating PPI 16 for event channel interrupt
> >> > (XEN) Loading dom0 DTB to 0x4800-0x4800af11
> >> > (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
> >> > (XEN) ..done.
> >> > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> >> > (XEN) Std. Loglevel: Errors and warnings
> >> > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> >> > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch
> >> > input
> >> > to Xen)
> >> > (XEN) Freed 284kB init memory.
> >> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> >> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> >> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> >> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> >> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
> >> > (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
> >> > (XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
> >> > (XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0
> >> >
> >> > It just hang there after the last line above.
> >> > I have looked into those messages " d0v3: vGICD: unhandled word write
> >> > 0x to ICACTIVER0"  and linux kernel already taking care to
> >> > ignore
> >> > it. Therefore, I believe this is not contributing to there hang here.
> >> > Any
> >> > idea on this issue?
> >>
> >> It looks like you did not let the kernel use the console so nothing
> >> was printed.
> >>
> >> Make sure you have 'console=hvc0' on your Linux line.
> >
> >
>
>
>
> --
> ---
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania
> http://www.cis.upenn.edu/~mengxu/
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] unable start xen in hikey

[Meng Xu]

On Thu, Aug 18, 2016 at 5:11 PM, Kamenee Arumugam
 wrote:
> Hi Konrad,
>
> I have already specified that in my xen.cfg :
>
> options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
> dtuart=/smb/uart@f7113000
> kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
> dtb=hi6220-hikey.dtb
>
> Chen,
>
> I am using linux kernel from 96 boards repo:
> https://github.com/96boards/linux.git and I compile using this command as
> below:
>
> make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>
> There was no dtb file produced after the compilation finished. But i saw a
> trace log mentioning , make: Nothing to be done for
> `arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts'.
>
>  Correct me if the make command above is wrong?

Then did you compile the device tree using command "make dtbs" as I
mentioned in previous email?


Meng
>
>
> Thanks,
> Kamenee
>
> On Thu, Aug 18, 2016 at 3:46 PM, Konrad Rzeszutek Wilk
>  wrote:
>>
>> On Wed, Aug 17, 2016 at 06:30:23PM -0400, Kamenee Arumugam wrote:
>> > Hi Chen,
>> >
>> > My previous issue was resolved when i used hi6220-hikey.dtb from this
>> > source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
>> > download linux kernel, there doesn't seems to contain hi6220-hikey.dtb.
>> >
>> > But now it got stuck while loading Dom0 and below are log traces:
>> >
>> >
>> > (XEN) *** LOADING DOMAIN 0 ***
>> > (XEN) Loading kernel from boot module @ 7a037000
>> > (XEN) Loading ramdisk from boot module @ 0ae0
>> > (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
>> > (XEN) BANK[0] 0x004000-0x006000 (512MB)
>> > (XEN) Grant table range: 0x0005c0-0x0005c54000
>> > (XEN) Loading zImage from 7a037000 to
>> > 4008-40ce8c00
>> > (XEN) Loading dom0 initrd from 0ae0 to
>> > 0x4820-0x48a0
>> > (XEN) Allocating PPI 16 for event channel interrupt
>> > (XEN) Loading dom0 DTB to 0x4800-0x4800af11
>> > (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
>> > (XEN) ..done.
>> > (XEN) Initial low memory virq threshold set at 0x4000 pages.
>> > (XEN) Std. Loglevel: Errors and warnings
>> > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
>> > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch
>> > input
>> > to Xen)
>> > (XEN) Freed 284kB init memory.
>> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
>> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
>> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
>> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
>> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
>> > (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
>> > (XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
>> > (XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0
>> >
>> > It just hang there after the last line above.
>> > I have looked into those messages " d0v3: vGICD: unhandled word write
>> > 0x to ICACTIVER0"  and linux kernel already taking care to
>> > ignore
>> > it. Therefore, I believe this is not contributing to there hang here.
>> > Any
>> > idea on this issue?
>>
>> It looks like you did not let the kernel use the console so nothing
>> was printed.
>>
>> Make sure you have 'console=hvc0' on your Linux line.
>
>



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

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

Re: [Xen-devel] [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

[Corey Minyard]

Sorry this took so long, but I have finally tested this, it seems to 
work fine:


Tested-by: Corey Minyard 
Reviewed-by: Corey Minyard 

On 08/10/2016 03:09 AM, Hidehiro Kawai wrote:

Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).

In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online.  As the result, kdump
routines fail to save other CPUs' registers.  Additionally for MIPS
OCTEON, it misses to stop the watchdog timer.

To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
weak function, and it just call smp_send_stop().  Architecture
codes should override it so that kdump can work appropriately.
This patch provides MIPS version.

Reported-by: Daniel Walker 
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai 
Cc: Ralf Baechle 
Cc: David Daney 
Cc: Aaro Koskinen 
Cc: "Steven J. Hill" 
Cc: Corey Minyard 

---
I'm not familiar with MIPS, and I don't have a test environment and
just did build tests only.  Please don't apply this patch until
someone does enough tests, otherwise simply drop this patch.
---
  arch/mips/cavium-octeon/setup.c  |   14 ++
  arch/mips/include/asm/kexec.h|1 +
  arch/mips/kernel/crash.c |   18 +-
  arch/mips/kernel/machine_kexec.c |1 +
  4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index cb16fcc..5537f95 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -267,6 +267,17 @@ static void octeon_crash_shutdown(struct pt_regs *regs)
default_machine_crash_shutdown(regs);
  }
  
+#ifdef CONFIG_SMP

+void octeon_crash_smp_send_stop(void)
+{
+   int cpu;
+
+   /* disable watchdogs */
+   for_each_online_cpu(cpu)
+   cvmx_write_csr(CVMX_CIU_WDOGX(cpu_logical_map(cpu)), 0);
+}
+#endif
+
  #endif /* CONFIG_KEXEC */
  
  #ifdef CONFIG_CAVIUM_RESERVE32

@@ -911,6 +922,9 @@ void __init prom_init(void)
_machine_kexec_shutdown = octeon_shutdown;
_machine_crash_shutdown = octeon_crash_shutdown;
_machine_kexec_prepare = octeon_kexec_prepare;
+#ifdef CONFIG_SMP
+   _crash_smp_send_stop = octeon_crash_smp_send_stop;
+#endif
  #endif
  
  	octeon_user_io_init();

diff --git a/arch/mips/include/asm/kexec.h b/arch/mips/include/asm/kexec.h
index ee25ebb..493a3cc 100644
--- a/arch/mips/include/asm/kexec.h
+++ b/arch/mips/include/asm/kexec.h
@@ -45,6 +45,7 @@ extern const unsigned char kexec_smp_wait[];
  extern unsigned long secondary_kexec_args[4];
  extern void (*relocated_kexec_smp_wait) (void *);
  extern atomic_t kexec_ready_to_reboot;
+extern void (*_crash_smp_send_stop)(void);
  #endif
  #endif
  
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c

index 610f0f3..1723b17 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -47,9 +47,14 @@ static void crash_shutdown_secondary(void *passed_regs)
  
  static void crash_kexec_prepare_cpus(void)

  {
+   static int cpus_stopped;
unsigned int msecs;
+   unsigned int ncpus;
  
-	unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */

+   if (cpus_stopped)
+   return;
+
+   ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
  
  	dump_send_ipi(crash_shutdown_secondary);

smp_wmb();
@@ -64,6 +69,17 @@ static void crash_kexec_prepare_cpus(void)
cpu_relax();
mdelay(1);
}
+
+   cpus_stopped = 1;
+}
+
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+   if (_crash_smp_send_stop)
+   _crash_smp_send_stop();
+
+   crash_kexec_prepare_cpus();
  }
  
  #else /* !defined(CONFIG_SMP)  */

diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c
index 50980bf3..5972520 100644
--- a/arch/mips/kernel/machine_kexec.c
+++ b/arch/mips/kernel/machine_kexec.c
@@ -25,6 +25,7 @@ void (*_machine_crash_shutdown)(struct pt_regs *regs) = NULL;
  #ifdef CONFIG_SMP
  void (*relocated_kexec_smp_wait) (void *);
  atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
+void (*_crash_smp_send_stop)(void) = NULL;
  #endif
  
  int






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

Re: [Xen-devel] unable start xen in hikey

[Kamenee Arumugam]

Hi Konrad,

I have already specified that in my xen.cfg :

options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
dtuart=/smb/uart@f7113000
kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
dtb=hi6220-hikey.dtb

Chen,

I am using linux kernel from 96 boards repo:  https://github.com/96boards/
linux.git  and I compile using this
command as below:

make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts

There was no dtb file produced after the compilation finished. But i saw a
trace log mentioning , make: Nothing to be done for
`arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts'.

 Correct me if the make command above is wrong?


Thanks,
Kamenee

On Thu, Aug 18, 2016 at 3:46 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> On Wed, Aug 17, 2016 at 06:30:23PM -0400, Kamenee Arumugam wrote:
> > Hi Chen,
> >
> > My previous issue was resolved when i used hi6220-hikey.dtb from this
> > source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
> > download linux kernel, there doesn't seems to contain hi6220-hikey.dtb.
> >
> > But now it got stuck while loading Dom0 and below are log traces:
> >
> >
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Loading kernel from boot module @ 7a037000
> > (XEN) Loading ramdisk from boot module @ 0ae0
> > (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> > (XEN) BANK[0] 0x004000-0x006000 (512MB)
> > (XEN) Grant table range: 0x0005c0-0x0005c54000
> > (XEN) Loading zImage from 7a037000 to
> > 4008-40ce8c00
> > (XEN) Loading dom0 initrd from 0ae0 to
> > 0x4820-0x48a0
> > (XEN) Allocating PPI 16 for event channel interrupt
> > (XEN) Loading dom0 DTB to 0x4800-0x4800af11
> > (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
> > (XEN) ..done.
> > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > (XEN) Std. Loglevel: Errors and warnings
> > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
> > to Xen)
> > (XEN) Freed 284kB init memory.
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0
> >
> > It just hang there after the last line above.
> > I have looked into those messages " d0v3: vGICD: unhandled word write
> > 0x to ICACTIVER0"  and linux kernel already taking care to ignore
> > it. Therefore, I believe this is not contributing to there hang here. Any
> > idea on this issue?
>
> It looks like you did not let the kernel use the console so nothing
> was printed.
>
> Make sure you have 'console=hvc0' on your Linux line.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] unable start xen in hikey

[Konrad Rzeszutek Wilk]

On Wed, Aug 17, 2016 at 06:30:23PM -0400, Kamenee Arumugam wrote:
> Hi Chen,
> 
> My previous issue was resolved when i used hi6220-hikey.dtb from this
> source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
> download linux kernel, there doesn't seems to contain hi6220-hikey.dtb.
> 
> But now it got stuck while loading Dom0 and below are log traces:
> 
> 
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 7a037000
> (XEN) Loading ramdisk from boot module @ 0ae0
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x004000-0x006000 (512MB)
> (XEN) Grant table range: 0x0005c0-0x0005c54000
> (XEN) Loading zImage from 7a037000 to
> 4008-40ce8c00
> (XEN) Loading dom0 initrd from 0ae0 to
> 0x4820-0x48a0
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0x4800-0x4800af11
> (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
> (XEN) ..done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
> to Xen)
> (XEN) Freed 284kB init memory.
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0
> 
> It just hang there after the last line above.
> I have looked into those messages " d0v3: vGICD: unhandled word write
> 0x to ICACTIVER0"  and linux kernel already taking care to ignore
> it. Therefore, I believe this is not contributing to there hang here. Any
> idea on this issue?

It looks like you did not let the kernel use the console so nothing
was printed.

Make sure you have 'console=hvc0' on your Linux line.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb
baseline version:
 xen  361db13b0380a3462f788d44076f42f6f155e719

Last test of basis   100543  2016-08-18 11:01:54 Z0 days
Testing same since   100548  2016-08-18 17:07:26 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7503cd70fb864a5663edb121c9b2488b4c69e7f5
baseline version:
 ovmf fd4d9c6495109979eb17779e07666c7c11c79c6a

Last test of basis67550  2016-08-17 08:19:21 Z1 days
Testing same since67553  2016-08-18 05:22:29 Z0 days1 attempts


People who touched revisions under test:
  edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
  Gary Lin 
  Gary Lin [mailto:g...@suse.com]
  Jeff Fan 
  Laszlo Ersek 
  Michael Kinney 
  Ruiyu Ni 
  Wei, David 

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



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

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

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


Push not applicable.

(No revision log; it would be 1222 lines long.)

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

[Xen-devel] [distros-debian-wheezy test] 67554: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   66969

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v4 02/16] libxl/arm: prepare for constructing ACPI tables

[Julien Grall]

On 16/08/16 11:24, Shannon Zhao wrote:

From: Shannon Zhao 

It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI.


It would be worth to mention that the code is only built for 64-bit 
toolstack.




Signed-off-by: Shannon Zhao 
---
 tools/libxl/Makefile  |  4 +++
 tools/libxl/libxl_arm.c   | 23 +++-
 tools/libxl/libxl_arm.h   | 44 +++
 tools/libxl/libxl_arm_acpi.c  | 61 +++
 xen/include/public/arch-arm.h |  4 +++
 5 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_arm.h
 create mode 100644 tools/libxl/libxl_arm_acpi.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a148374..6139bed 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -90,6 +90,10 @@ acpi:

 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
+LIBXL_OBJS-$(CONFIG_ARM_64) += libxl_arm_acpi.o


As mentioned above this will only enable ACPI when the toolstack is 
built for 64-bit. Although it might be possible to have 32-bit toolstack.


I guess it is fine for now, however I would like to avoid the #if 
defined(__aarch64__) in the code by introduce a libxl_arm_no_acpi.c 
similar to how it is done for other options (see in the Makefile).



+
+libxl_arm_acpi.o: libxl_arm_acpi.c
+   $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c

 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index bd3d611..8c7fc09 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1,6 +1,7 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 #include "libxl_libfdt_compat.h"
+#include "libxl_arm.h"

 #include 
 #include 
@@ -885,8 +886,28 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
libxl__domain_build_state *state,
struct xc_dom_image *dom)
 {
+int rc;
+
 assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-return libxl__prepare_dtb(gc, info, state, dom);
+rc = libxl__prepare_dtb(gc, info, state, dom);
+if (rc) goto out;
+
+if (!libxl_defbool_val(info->acpi)) {
+LOG(DEBUG, "Generating ACPI tables is disabled by user.");
+rc = 0;
+goto out;
+}
+
+if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {


Can you add a comment in the code explaining that ACPI is only supported 
for 64-bit guest for now.



+LOG(ERROR, "Can not enable libxl option 'acpi' for %s", 
dom->guest_type);
+rc = ERROR_FAIL;
+goto out;
+}
+
+rc = libxl__prepare_acpi(gc, info, state, dom);
+
+out:
+return rc;
 }

 static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
new file mode 100644
index 000..fe1c05f
--- /dev/null
+++ b/tools/libxl/libxl_arm.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2016  Linaro Ltd.
+ *
+ * Author: Shannon Zhao 
+ *
+ * This program 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 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ */
+
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+#include 
+
+#if defined(__aarch64__)
+_hidden
+int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
+libxl__domain_build_state *state,
+struct xc_dom_image *dom);
+#else
+_hidden
+static inline int libxl__prepare_acpi(libxl__gc *gc,
+  libxl_domain_build_info *info,

Can y

+  libxl__domain_build_state *state,
+  struct xc_dom_image *dom)
+{
+return 0;


this should be either an ASSERT or return an error value to avoid any 
mis-usage.



+}
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
new file mode 100644
index 000..ec6cf08
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -0,0 +1,61 @@
+/*
+ * ARM DomU ACPI generation
+ *
+ * Copyright (C) 2016  Linaro Ltd.
+ *
+ * Author: Shannon Zhao 
+ *
+ * This program is free software; you can redistribute it and/or 

Re: [Xen-devel] [PATCH] tools/xenalyze: append argp LD flags if needed

[Wei Liu]

Queued.

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

Re: [Xen-devel] [PATCH v8 00/13] Load BIOS via toolstack instead of been embedded in hvmloader

[Wei Liu]

I've made the required adjustment and queued up this series.

Wei.

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

Re: [Xen-devel] [PATCH] arm64: head: Fill image size

[Julien Grall]

Hello Peng,

On 16/08/16 03:58, Peng Fan wrote:

When booting xen from U-Boot, U-Boot will use the image size
info. Because this information is lacked in XEN image,U-Boot
assume the image size is 16MB to memmove, which will cost lots
time on simulation platform.


The patch looks good to me, however I would prefer if you update all the 
header rather than updating only the field you care.


You can give a look to commit a2c1d73b94ed49f5fac12e95052d7b140783f800 
"arm64: Update the Image header" in Linux for more details.


Regards,



Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/arm64/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 91e2817..9fade07 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -115,7 +115,7 @@ efi_head:
 add x13, x18, #0x16
 b   real_start   /* branch to kernel start */
 .quad   0/* Image load offset from start of RAM */
-.quad   0/* reserved */
+.quad   _end - start /* Effective size of Image, little-endian 
*/
 .quad   0/* reserved */
 .quad   0/* reserved */
 .quad   0/* reserved */



--
Julien Grall

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

Re: [Xen-devel] [PATCH v8 07/13] hvmloader: Locate the BIOS blob

[Wei Liu]

On Thu, Aug 18, 2016 at 04:48:20PM +0100, Andrew Cooper wrote:
> On 18/08/16 16:39, Jan Beulich wrote:
>  On 18.08.16 at 16:13,  wrote:
> >> From: Anthony PERARD 
> >>
> >> The BIOS blob can be found an entry called "firmware" of the modlist of
> >> the hvm_start_info struct.
> >>
> >> The found BIOS blob is not loaded by this patch, but only passed as
> >> argument to bios_load() function.
> >>
> >> Signed-off-by: Anthony PERARD 
> > Acked-by: Jan Beulich 
> > provided Andrew confirms his concerns have got addressed and a
> > few minor things get taken care of:
> 
> They haven't, but I am planning some fixes anyway, so I will adjust
> things there.  They are not worth letting this series drag on even longer.
> 

Can I turn this into an ack?

I can fix the issues Jan pointed out why committing.

Wei.

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

Re: [Xen-devel] unable start xen in hikey

[Chenxiao Zhao]

It seems that you are using a dtb file that is not compatible with XEN
hypervisor on hikey. I strongly suggest you compile the kernel from source
in 96boards's repository. When you compile the kernel it will compile the
dtb from dts as well.

On Thu, Aug 18, 2016 at 6:30 AM Kamenee Arumugam 
wrote:

> Hi Chen,
>
> My previous issue was resolved when i used hi6220-hikey.dtb from this
> source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
> download linux kernel, there doesn't seems to contain hi6220-hikey.dtb.
>
> But now it got stuck while loading Dom0 and below are log traces:
>
>
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 7a037000
> (XEN) Loading ramdisk from boot module @ 0ae0
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x004000-0x006000 (512MB)
> (XEN) Grant table range: 0x0005c0-0x0005c54000
> (XEN) Loading zImage from 7a037000 to
> 4008-40ce8c00
> (XEN) Loading dom0 initrd from 0ae0 to
> 0x4820-0x48a0
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0x4800-0x4800af11
> (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
> (XEN) ..done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
> to Xen)
> (XEN) Freed 284kB init memory.
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
> (XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0
>
> It just hang there after the last line above.
> I have looked into those messages " d0v3: vGICD: unhandled word write
> 0x to ICACTIVER0"  and linux kernel already taking care to ignore
> it. Therefore, I believe this is not contributing to there hang here. Any
> idea on this issue?
>
> Thanks,
> Kamenee
>
>
> On Wed, Aug 10, 2016 at 9:11 PM, Chenxiao Zhao 
> wrote:
>
>> You should compile kernel first. Please follow the "Getting Started" page
>> on 96boards
>>
>> On 8/10/2016 7:07 AM, Kamenee Arumugam wrote:
>>
>>> Hi Chen,
>>>
>>> I have tried to flash UEFI in my board with latest one but still facing
>>> the same issue. Regarding to use dtb file from kernel source, I couldnt
>>> find hi6220-hikey.dtb in my source kernel. i am downloading my kernel
>>> source from
>>> here: https://github.com/96boards/linux/tree/android-hikey-linaro-4.1
>>>
>>> I only could find hi6220-hikey.dts file in the kernel source. Therefore
>>> download from other github but which is correct one that i need to use?
>>> In case, I am using incorrect kernel source, pls point to me to correct
>>> one if you aware of?
>>>
>>> Thanks,
>>> Kamenee
>>>
>>> On Thu, Aug 4, 2016 at 11:06 PM, Chenxiao Zhao >> > wrote:
>>>
>>> The xen.cfg file seems fine to me. I suggest you try to use the dtb
>>> file compiled from the kernel source and update UEFI bootloader on
>>> hikey board to the latest version.
>>>
>>> hope this could help.
>>>
>>> On 8/4/2016 11:02 PM, Kamenee Arumugam wrote:
>>>
>>> I have already pass hi6220-key.dtb in my xen.cfg:
>>>
>>> options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
>>> dtuart=/smb/uart@f7113000
>>> kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
>>> dtb=hi6220-hikey.dtb
>>>
>>> I download the hi6220-hikey.dtb from this site:
>>>
>>> https://android.googlesource.com/device/linaro/hikey-kernel/+/f117fa12746b59aa0a1a4d6335145e58935c422b/hi6220-hikey.dtb
>>> <
>>> https://android.googlesource.com/device/linaro/hikey-kernel/+/f117fa12746b59aa0a1a4d6335145e58935c422b/hi6220-hikey.dtb
>>> >
>>>
>>>
>>> Firstly, I build kernel using the command below:
>>>
>>> make -j24 Image hi6220-hikey.dtb
>>>
>>> I placed hikey6220-hikey.dtb in linux directory level. I also
>>> copied the
>>> dtb into sd before booting up. Please correct me if my steps are
>>> wrong.
>>>
>>>
>>> On Thu, Aug 4, 2016 at 3:27 AM, Chenxiao Zhao
>>> 
>>> >> >> wrote:
>>>
>>> you have to pass hi6220-key.dtb to xen.
>>>
>>> On 

Re: [Xen-devel] [PATCH v8 07/13] hvmloader: Locate the BIOS blob

[Andrew Cooper]

On 18/08/16 16:39, Jan Beulich wrote:
 On 18.08.16 at 16:13,  wrote:
>> From: Anthony PERARD 
>>
>> The BIOS blob can be found an entry called "firmware" of the modlist of
>> the hvm_start_info struct.
>>
>> The found BIOS blob is not loaded by this patch, but only passed as
>> argument to bios_load() function.
>>
>> Signed-off-by: Anthony PERARD 
> Acked-by: Jan Beulich 
> provided Andrew confirms his concerns have got addressed and a
> few minor things get taken care of:

They haven't, but I am planning some fixes anyway, so I will adjust
things there.  They are not worth letting this series drag on even longer.

>
>> --- a/tools/firmware/hvmloader/hvmloader.c
>> +++ b/tools/firmware/hvmloader/hvmloader.c
>> @@ -266,10 +266,57 @@ static void acpi_enable_sci(void)
>>  BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
>>  }
>>  
>> +const struct hvm_modlist_entry *get_module_entry(
>> +const struct hvm_start_info *info,
>> +const char *name)
>> +{
>> +const struct hvm_modlist_entry *modlist =
>> +(struct hvm_modlist_entry *)(uintptr_t)info->modlist_paddr;
>> +unsigned int i;
>> +
>> +if ( !modlist ||
>> + info->modlist_paddr > UINTPTR_MAX ||
>> + (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
>> +> UINTPTR_MAX
>> + )
> Urgh?
>
>> +return NULL;
>> +
>> +for ( i = 0; i < info->nr_modules; i++ )
>> +{
>> +char *module_name = (char*)(uintptr_t)modlist[i].cmdline_paddr;
>> +
>> +/* Skip if the module or its cmdline is missing. */
>> +if ( !module_name || !modlist[i].paddr )
>> +continue;
>> +
>> +/* Skip if the cmdline can not be read. */
> cannot (afaik)
>
>> +if ( modlist[i].cmdline_paddr > UINTPTR_MAX ||
>> + (modlist[i].cmdline_paddr + strlen(name)) > UINTPTR_MAX )
>> +continue;
>> +
>> +if ( !strcmp(name, module_name) )
>> +{
>> +if ( modlist[i].paddr > UINTPTR_MAX ||
>> + modlist[i].size > UINTPTR_MAX ||
>> + (modlist[i].paddr + modlist[i].size - 1) > UINTPTR_MAX )
>> +{
>> +printf("Can not load \"%s\" from 0x"PRIllx" (0x"PRIllx")\n",
> Same here.

"can not" is valid, but it is very uncommon to use.  The double n is
awkward to pronounce, which is why "cannot" (with only a single n to
pronounce) is the more common form.

~Andrew

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

Re: [Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

[Wei Liu]

On Wed, Aug 17, 2016 at 04:13:29PM +0100, Paul Durrant wrote:
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v8 07/13] hvmloader: Locate the BIOS blob

[Jan Beulich]

>>> On 18.08.16 at 16:13,  wrote:
> From: Anthony PERARD 
> 
> The BIOS blob can be found an entry called "firmware" of the modlist of
> the hvm_start_info struct.
> 
> The found BIOS blob is not loaded by this patch, but only passed as
> argument to bios_load() function.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Jan Beulich 
provided Andrew confirms his concerns have got addressed and a
few minor things get taken care of:

> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -266,10 +266,57 @@ static void acpi_enable_sci(void)
>  BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
>  }
>  
> +const struct hvm_modlist_entry *get_module_entry(
> +const struct hvm_start_info *info,
> +const char *name)
> +{
> +const struct hvm_modlist_entry *modlist =
> +(struct hvm_modlist_entry *)(uintptr_t)info->modlist_paddr;
> +unsigned int i;
> +
> +if ( !modlist ||
> + info->modlist_paddr > UINTPTR_MAX ||
> + (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
> +> UINTPTR_MAX
> + )

Urgh?

> +return NULL;
> +
> +for ( i = 0; i < info->nr_modules; i++ )
> +{
> +char *module_name = (char*)(uintptr_t)modlist[i].cmdline_paddr;
> +
> +/* Skip if the module or its cmdline is missing. */
> +if ( !module_name || !modlist[i].paddr )
> +continue;
> +
> +/* Skip if the cmdline can not be read. */

cannot (afaik)

> +if ( modlist[i].cmdline_paddr > UINTPTR_MAX ||
> + (modlist[i].cmdline_paddr + strlen(name)) > UINTPTR_MAX )
> +continue;
> +
> +if ( !strcmp(name, module_name) )
> +{
> +if ( modlist[i].paddr > UINTPTR_MAX ||
> + modlist[i].size > UINTPTR_MAX ||
> + (modlist[i].paddr + modlist[i].size - 1) > UINTPTR_MAX )
> +{
> +printf("Can not load \"%s\" from 0x"PRIllx" (0x"PRIllx")\n",

Same here.

Jan


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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[One Thousand Gnomes]

On Thu, 18 Aug 2016 05:12:54 -0600
"Jan Beulich"  wrote:

> >>> On 18.08.16 at 12:16,  wrote:  
> > On 18/08/16 11:06, Jan Beulich wrote:  
> > On 17.08.16 at 22:32,  wrote:  
> >>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
> >>>The comment says:
> >>>" /* Low ISA region is always mapped WB in page table. No need to 
> >>> track   
> > *"  
> >> As per above it's not clear to me what this comment is backed by.  
> > 
> > This states what is in the pagetables.  Not the combined result with MTRRs.
> > 
> > WB in the pagetables and WC/UB in the MTRRs is a legal combination which
> > functions correctly.  
> 
> True, but then again - haven't I been told multiple times that Linux
> nowadays prefers to run without using MTRRs?

The BIOS sets up the fixed MTRR registers for the 640K-1MB window. Those
are separate to the variable range MTRR registers used for main memory
with specific mappings for segments A000 to BFFF then C000-C7FF /
C800-CFFF / etc up to .

Alan

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

Re: [Xen-devel] [Design RFC] Towards work-conserving RTDS scheduler

[Meng Xu]

On Thu, Aug 18, 2016 at 6:22 AM, Dario Faggioli
 wrote:
> On Tue, 2016-08-09 at 09:57 -0400, Meng Xu wrote:
>> On Mon, Aug 8, 2016 at 5:38 AM, Dario Faggioli
>>  wrote:
>> >
>> > I'm just thinking out loud and
>> > wondering:
>> >  - could it be useful to have a scheduling analysis in place for
>> > the
>> >scheduler in work conserving mode (one, of course, that takes
>> > into
>> >account and give guarantees on the otherwise idle bandwidth... I
>> >know that the existing one holds! :-P) ?
>> >  - if yes, do you already have one --or do you think it will be
>> >possible to develop one-- for your priority-index based model?
>> I think I could potentially develop one such analysis.
>>
> Great. Let me know if you need any help writing the paper! :-P

Sure, I definitely will. :-D
I'm in the middle of another work. I need to do some survey on the
literatures (such as the ones you mentioned) about the work-conserving
real-time scheduling. The ideal goal in my mind is to have the
scheduler become work-conserving, and we can have a paper as a "side
product".  ;-)

Thanks and best regards,

Meng

-- 

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100528
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 100528

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100528
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100528
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100528

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

version targeted for testing:
 qemuu4b887ae65880bf7eae53ba8af40599581fe759e5
baseline version:
 qemuu5f0e775348082c355769a3df612e055abea61c06

Last test of basis   100528  2016-08-17 07:58:34 Z1 days
Testing same since   100542  2016-08-18 10:13:31 Z0 days1 attempts


People who touched revisions under test:
  Fam Zheng 
  Peter Maydell 

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

[Xen-devel] [PATCH v8 11/13] hvmloader: Always build-in SeaBIOS and OVMF loader

[Wei Liu]

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/Makefile| 11 +--
 tools/firmware/hvmloader/hvmloader.c |  4 
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index dee1c6b..9f7357f 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -37,6 +37,7 @@ OBJS  = hvmloader.o mp_tables.o util.o smbios.o
 OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
+OBJS += ovmf.o seabios.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
@@ -57,11 +58,6 @@ endif
 
 ROMS := 
 
-ifeq ($(CONFIG_OVMF),y)
-OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF
-endif
-
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
@@ -69,11 +65,6 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
-ifeq ($(CONFIG_SEABIOS),y)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-endif
-
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 0d56f7d..e8d2cf5 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -222,12 +222,8 @@ struct bios_info {
 #ifdef ENABLE_ROMBIOS
 { "rombios", _config, },
 #endif
-#ifdef ENABLE_SEABIOS
 { "seabios", _config, },
-#endif
-#ifdef ENABLE_OVMF
 { "ovmf", _config, },
-#endif
 { NULL, NULL }
 };
 
-- 
2.1.4


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

[Xen-devel] [PATCH v8 12/13] configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

[Wei Liu]

From: Anthony PERARD 

... to compile SeaBIOS and OVMF. Only depend on CONFIG_*.

If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 

---
Please, run ./autogen.sh on this patch.

No change in V5.

Change in V4:
- change subject prefix
---
 tools/configure | 8 
 tools/configure.ac  | 6 --
 tools/firmware/Makefile | 8 
 3 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/tools/configure b/tools/configure
index c182391..81ccf34 100755
--- a/tools/configure
+++ b/tools/configure
@@ -695,8 +695,6 @@ APPEND_INCLUDES
 PREPEND_LIB
 PREPEND_INCLUDES
 EXTRA_QEMUU_CONFIGURE_ARGS
-ovmf_path
-seabios_path
 qemu_xen_systemd
 qemu_xen_path
 qemu_xen
@@ -4442,6 +4440,8 @@ _ACEOF
 # Check whether --with-system-seabios was given.
 if test "${with_system_seabios+set}" = set; then :
   withval=$with_system_seabios;
+# Disable compilation of SeaBIOS.
+seabios=n
 case $withval in
 no) seabios_path= ;;
 *)  seabios_path=$withval ;;
@@ -4450,7 +4450,6 @@ if test "${with_system_seabios+set}" = set; then :
 fi
 
 
-
 cat >>confdefs.h <<_ACEOF
 #define SEABIOS_PATH "${seabios_path:-$XENFIRMWAREDIR/bios.bin}"
 _ACEOF
@@ -4460,6 +4459,8 @@ _ACEOF
 # Check whether --with-system-ovmf was given.
 if test "${with_system_ovmf+set}" = set; then :
   withval=$with_system_ovmf;
+# Disable compilation of OVMF.
+ovmf=n
 case $withval in
 no) ovmf_path= ;;
 *)  ovmf_path=$withval ;;
@@ -4468,7 +4469,6 @@ if test "${with_system_ovmf+set}" = set; then :
 fi
 
 
-
 cat >>confdefs.h <<_ACEOF
 #define OVMF_PATH "${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"
 _ACEOF
diff --git a/tools/configure.ac b/tools/configure.ac
index ed10902..c12ad79 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -215,12 +215,13 @@ AC_ARG_WITH([system-seabios],
 AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
[Use system supplied seabios PATH instead of building and installing
 our own version]),[
+# Disable compilation of SeaBIOS.
+seabios=n
 case $withval in
 no) seabios_path= ;;
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AC_SUBST(seabios_path)
 AC_DEFINE_UNQUOTED([SEABIOS_PATH],
["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
[SeaBIOS path])
@@ -229,12 +230,13 @@ AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
[Use system supplied OVMF PATH instead of building and installing
 our own version]),[
+# Disable compilation of OVMF.
+ovmf=n
 case $withval in
 no) ovmf_path= ;;
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AC_SUBST(ovmf_path)
 AC_DEFINE_UNQUOTED([OVMF_PATH],
["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
[OVMF path])
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 82b1f6b..cf09ad2 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,12 +6,8 @@ TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
-ifeq ($(OVMF_PATH),)
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
-endif
-ifeq ($(SEABIOS_PATH),)
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
-endif
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
@@ -46,15 +42,11 @@ install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
-ifeq ($(SEABIOS_PATH),)
$(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/bios.bin
 endif
-endif
 ifeq ($(CONFIG_OVMF),y)
-ifeq ($(OVMF_PATH),)
$(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
 endif
-endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
2.1.4


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

[Xen-devel] [PATCH v8 10/13] hvmloader: bios->bios_load() now needs to be defined

[Wei Liu]

From: Anthony PERARD 

All BIOSes but ROMBIOS needs to be loaded via modules.

ROMBIOS is handled as a special case.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
Change in V5:
- rename patch, was:
  "hvmloader: Specific bios_load function required"

No change in V4.

Change in V3:
- reprint Main BIOS in bios map with now available information from bios
  modules.
- handle rombios, and keep its built-in ROMs.
---
 tools/firmware/hvmloader/hvmloader.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 1032e3c..0d56f7d 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -353,22 +353,26 @@ int main(void)
 
 printf("Loading %s ...\n", bios->name);
 bios_module = get_module_entry(hvm_start_info, "firmware");
-if ( bios_module && bios->bios_load )
+if ( bios_module )
 {
 uint32_t paddr = bios_module->paddr;
 
 bios->bios_load(bios, (void*)paddr, bios_module->size);
 }
-else if ( bios->bios_load )
+#ifdef ENABLE_ROMBIOS
+else if ( bios == _config )
 {
 bios->bios_load(bios, NULL, 0);
 }
+#endif
 else
 {
-BUG_ON(bios->bios_address + bios->image_size >
-   HVMLOADER_PHYSICAL_ADDRESS);
-memcpy((void *)bios->bios_address, bios->image,
-   bios->image_size);
+/*
+ * If there is no BIOS module supplied and if there is no embeded BIOS
+ * image, then we failed. Only rombios might have an embedded bios 
blob.
+ */
+printf("no BIOS ROM image found\n");
+BUG();
 }
 
 if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
-- 
2.1.4


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

[Xen-devel] [PATCH v8 13/13] docs/misc/hvmlite: Point to the canonical definition of hvm_start_info

[Wei Liu]

From: Anthony PERARD 

The C struct in the document is no more in sync with the actual
definition of the PVHv2 boot start info.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
Acked-by: Wei Liu 
---
 docs/misc/hvmlite.markdown | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index c1b75c6..69d90fe 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -37,24 +37,8 @@ following machine state:
 All other processor registers and flag bits are unspecified. The OS is in
 charge of setting up it's own stack, GDT and IDT.
 
-The format of the boot start info structure is the following (pointed to
-be %ebx):
-
-struct hvm_start_info {
-#define HVM_START_MAGIC_VALUE 0x336ec578
-uint32_t magic; /* Contains the magic value 0x336ec578 
  */
-/* ("xEn3" with the 0x80 bit of the "E" 
set).*/
-uint32_t flags; /* SIF_xxx flags.  
  */
-uint32_t cmdline_paddr; /* Physical address of the command line.   
  */
-uint32_t nr_modules;/* Number of modules passed to the kernel. 
  */
-uint32_t modlist_paddr; /* Physical address of an array of 
  */
-/* hvm_modlist_entry.  
  */
-};
-
-struct hvm_modlist_entry {
-uint32_t paddr; /* Physical address of the module. 
  */
-uint32_t size;  /* Size of the module in bytes.
  */
-};
+The format of the boot start info structure (pointed to by %ebx) can be found
+in xen/include/public/arch-x86/hvm/start_info.h
 
 Other relevant information needed in order to boot a guest kernel
 (console page address, xenstore event channel...) can be obtained
-- 
2.1.4


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

[Xen-devel] [PATCH v8 03/13] configure: #define SEABIOS_PATH and OVMF_PATH

[Wei Liu]

From: Anthony PERARD 

Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not defined via --with-system-seabios or
--with-system-ovmf, then default to the Xen firmware directory.

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 
---
Please, run ./autogen.sh on this patch.

Change in V5:
  - rename seabios.bin to bios.bin.
---
 tools/config.h.in  |  6 ++
 tools/configure| 10 ++
 tools/configure.ac |  6 ++
 3 files changed, 22 insertions(+)

diff --git a/tools/config.h.in b/tools/config.h.in
index 478a2cc..f65eec4 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -96,6 +96,9 @@
 /* libutil header file name */
 #undef INCLUDE_LIBUTIL_H
 
+/* OVMF path */
+#undef OVMF_PATH
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
@@ -117,6 +120,9 @@
 /* Qemu Xen path */
 #undef QEMU_XEN_PATH
 
+/* SeaBIOS path */
+#undef SEABIOS_PATH
+
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
diff --git a/tools/configure b/tools/configure
index 51f16c5..c182391 100755
--- a/tools/configure
+++ b/tools/configure
@@ -4451,6 +4451,11 @@ fi
 
 
 
+cat >>confdefs.h <<_ACEOF
+#define SEABIOS_PATH "${seabios_path:-$XENFIRMWAREDIR/bios.bin}"
+_ACEOF
+
+
 
 # Check whether --with-system-ovmf was given.
 if test "${with_system_ovmf+set}" = set; then :
@@ -4464,6 +4469,11 @@ fi
 
 
 
+cat >>confdefs.h <<_ACEOF
+#define OVMF_PATH "${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"
+_ACEOF
+
+
 
 # Check whether --with-extra-qemuu-configure-args was given.
 if test "${with_extra_qemuu_configure_args+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 3a4abb5..ed10902 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -221,6 +221,9 @@ AC_ARG_WITH([system-seabios],
 esac
 ],[])
 AC_SUBST(seabios_path)
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],
+   ["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
+   [SeaBIOS path])
 
 AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
@@ -232,6 +235,9 @@ AC_ARG_WITH([system-ovmf],
 esac
 ],[])
 AC_SUBST(ovmf_path)
+AC_DEFINE_UNQUOTED([OVMF_PATH],
+   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
+   [OVMF path])
 
 AC_ARG_WITH([extra-qemuu-configure-args],
 AS_HELP_STRING([--with-extra-qemuu-configure-args@<:@="--ARG1 ..."@:>@],
-- 
2.1.4


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

[Xen-devel] [PATCH v8 00/13] Load BIOS via toolstack instead of been embedded in hvmloader

[Wei Liu]

This is version 8 of this series, rebased on top of staging.

The only change is "hvmloader: Check modules whereabouts in perform_tests" is
dropped.

The only unacked patch is "hvmloader: Locate the BIOS blob". I figured that
Anthony has answered Andrew's question and there is nothing to change.

I've only CC'ed relevant people on the unacked patch and this cover letter.

Wei.

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 

Anthony PERARD (13):
  libxc: Rework extra module initialisation
  libxc: Prepare a start info structure for hvmloader
  configure: #define SEABIOS_PATH and OVMF_PATH
  firmware/makefile: install BIOS blob ...
  libxl: Load guest BIOS from file
  hvmloader: Grab the hvm_start_info pointer
  hvmloader: Locate the BIOS blob
  hvmloader: Load SeaBIOS from hvm_start_info modules
  hvmloader: Load OVMF from modules
  hvmloader: bios->bios_load() now needs to be defined
  hvmloader: Always build-in SeaBIOS and OVMF loader
  configure: do not depend on SEABIOS_PATH or OVMF_PATH ...
  docs/misc/hvmlite: Point to the canonical definition of hvm_start_info

 docs/man/xl.cfg.pod.5.in |   9 +++
 docs/misc/hvmlite.markdown   |  20 +
 tools/config.h.in|   6 ++
 tools/configure  |  14 +++-
 tools/configure.ac   |  12 ++-
 tools/firmware/Makefile  |  10 ++-
 tools/firmware/hvmloader/Makefile|  39 +
 tools/firmware/hvmloader/config.h|   2 +-
 tools/firmware/hvmloader/hvmloader.c |  82 ---
 tools/firmware/hvmloader/ovmf.c  |  34 
 tools/firmware/hvmloader/rombios.c   |   3 +-
 tools/firmware/hvmloader/seabios.c   |  25 +++---
 tools/firmware/hvmloader/util.h  |   3 +
 tools/libxc/include/xc_dom.h |   3 +
 tools/libxc/xc_dom_hvmloader.c   | 136 ++-
 tools/libxc/xc_dom_x86.c | 152 +--
 tools/libxl/libxl.h  |   8 ++
 tools/libxl/libxl_dom.c  |  61 ++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_paths.c|  10 +++
 tools/libxl/libxl_types.idl  |   1 +
 tools/libxl/xl_cmdimpl.c |  11 ++-
 22 files changed, 401 insertions(+), 242 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v8 09/13] hvmloader: Load OVMF from modules

[Wei Liu]

From: Anthony PERARD 

... and do not include the OVMF ROM into hvmloader anymore.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Change in V5:
- define OVMF_END macro
- fix some cast coding style

Change in V4:
- check if source and dest of ovmf binary does not overlaps

Change in V3:
- change makefile to not include ovmf rom into roms.inc.
- update the struct bios_config with bios destination
---
 tools/firmware/hvmloader/Makefile | 15 +--
 tools/firmware/hvmloader/ovmf.c   | 31 ++-
 2 files changed, 15 insertions(+), 31 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index ed0bfad..dee1c6b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -43,7 +43,6 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -61,12 +60,6 @@ ROMS :=
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
 CFLAGS += -DENABLE_OVMF
-ifeq ($(OVMF_PATH),)
-   OVMF_ROM := $(OVMF_DIR)/ovmf.bin
-else
-   OVMF_ROM := $(OVMF_PATH)
-endif
-ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -85,7 +78,7 @@ endif
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o: roms.inc
+rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -102,12 +95,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(OVMF_ROM),)
-   echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
-   sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
-   echo "#endif" >> $@.new 
-endif 
-
 ifneq ($(STDVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 60d000f..b4bcc93 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -34,17 +34,11 @@
 #include 
 #include 
 
-#define ROM_INCLUDE_OVMF
-#include "roms.inc"
-
-#define OVMF_SIZE   (sizeof(ovmf))
 #define OVMF_MAXOFFSET  0x000FULL
-#define OVMF_BEGIN  (0x1ULL - ((OVMF_SIZE + 
OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET))
-#define OVMF_END(OVMF_BEGIN + OVMF_SIZE)
+#define OVMF_END0x1ULL
 #define LOWCHUNK_BEGIN  0x000F
 #define LOWCHUNK_SIZE   0x0001
 #define LOWCHUNK_MAXOFFSET  0x
-#define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
 extern unsigned char dsdt_anycpu_qemu_xen[];
@@ -97,24 +91,31 @@ static void ovmf_load(const struct bios_config *config,
   void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
-uint64_t addr = OVMF_BEGIN;
+uint64_t addr = OVMF_END
+- ((bios_length + OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET);
+uint64_t ovmf_end = addr + bios_length;
+
+ovmf_config.bios_address = addr;
+ovmf_config.image_size = bios_length;
 
 /* Copy low-reset vector portion. */
-memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
-   + OVMF_SIZE
-   - LOWCHUNK_SIZE,
+memcpy((void *)LOWCHUNK_BEGIN,
+   (uint8_t *)bios_addr + bios_length - LOWCHUNK_SIZE,
LOWCHUNK_SIZE);
 
 /* Ensure we have backing page prior to moving FD. */
-while ( (addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT) )
+while ( (addr >> PAGE_SHIFT) != (ovmf_end >> PAGE_SHIFT) )
 {
 mfn = (uint32_t) (addr >> PAGE_SHIFT);
 addr += PAGE_SIZE;
 mem_hole_populate_ram(mfn, 1);
 }
 
+/* Check that source and destination does not overlaps. */
+BUG_ON(addr + bios_length > (unsigned)bios_addr &&
+   addr < (unsigned)bios_addr + bios_length);
 /* Copy FD. */
-memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+memcpy((void *)ovmf_config.bios_address, bios_addr, bios_length);
 }
 
 static void ovmf_acpi_build_tables(void)
@@ -151,10 +152,6 @@ static void ovmf_setup_e820(void)
 struct bios_config ovmf_config =  {
 .name = "OVMF",
 
-.image = ovmf,
-.image_size = sizeof(ovmf),
-
-.bios_address = OVMF_BEGIN,
 .bios_load = ovmf_load,
 
 .load_roms = 0,
-- 
2.1.4


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

[Xen-devel] [PATCH v8 07/13] hvmloader: Locate the BIOS blob

[Wei Liu]

From: Anthony PERARD 

The BIOS blob can be found an entry called "firmware" of the modlist of
the hvm_start_info struct.

The found BIOS blob is not loaded by this patch, but only passed as
argument to bios_load() function.

Signed-off-by: Anthony PERARD 

---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 

No change in v8.

Changes in V6:
- cast addresses to uintptr_t instead of uint32_t.
- use UINTPTR_MAX for the upper boundary checks.
- Do a full check of every things that are used, check that modlist,
  cmdlines, modules lives below 4GB and does not cross the boundary.

Changes in V5:
- don't BUG() on module's paddr having value 0, and just skip.
- fix some coding style
- rename module name to "firmware" (was "bios")
- less use of BUG_ON in get_module_entry() and skip entries instead.
  Only BUG() if the module which match name is not accessible.

Changes in V4:
- add more BUG_ON into get_module_entry(). Check that modules paddr and
  size are 32bits.

Changes in V3:
- fix some codying style
- use module.cmdline to look for a module name instead of the main cmdline
  from hvm_start_info.
---
 tools/firmware/hvmloader/config.h|  2 +-
 tools/firmware/hvmloader/hvmloader.c | 60 ++--
 tools/firmware/hvmloader/ovmf.c  |  3 +-
 tools/firmware/hvmloader/rombios.c   |  3 +-
 4 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index da1e7cf..a4429f4 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -22,7 +22,7 @@ struct bios_config {
 /* ROMS */
 void (*load_roms)(void);
 
-void (*bios_load)(const struct bios_config *config);
+void (*bios_load)(const struct bios_config *config, void *addr, uint32_t 
size);
 
 void (*bios_info_setup)(void);
 void (*bios_info_finish)(void);
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 67a18af..1032e3c 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -266,10 +266,57 @@ static void acpi_enable_sci(void)
 BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
 }
 
+const struct hvm_modlist_entry *get_module_entry(
+const struct hvm_start_info *info,
+const char *name)
+{
+const struct hvm_modlist_entry *modlist =
+(struct hvm_modlist_entry *)(uintptr_t)info->modlist_paddr;
+unsigned int i;
+
+if ( !modlist ||
+ info->modlist_paddr > UINTPTR_MAX ||
+ (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
+> UINTPTR_MAX
+ )
+return NULL;
+
+for ( i = 0; i < info->nr_modules; i++ )
+{
+char *module_name = (char*)(uintptr_t)modlist[i].cmdline_paddr;
+
+/* Skip if the module or its cmdline is missing. */
+if ( !module_name || !modlist[i].paddr )
+continue;
+
+/* Skip if the cmdline can not be read. */
+if ( modlist[i].cmdline_paddr > UINTPTR_MAX ||
+ (modlist[i].cmdline_paddr + strlen(name)) > UINTPTR_MAX )
+continue;
+
+if ( !strcmp(name, module_name) )
+{
+if ( modlist[i].paddr > UINTPTR_MAX ||
+ modlist[i].size > UINTPTR_MAX ||
+ (modlist[i].paddr + modlist[i].size - 1) > UINTPTR_MAX )
+{
+printf("Can not load \"%s\" from 0x"PRIllx" (0x"PRIllx")\n",
+   name, PRIllx_arg(modlist[i].paddr),
+   PRIllx_arg(modlist[i].size));
+BUG();
+}
+return [i];
+}
+}
+
+return NULL;
+}
+
 int main(void)
 {
 const struct bios_config *bios;
 int acpi_enabled;
+const struct hvm_modlist_entry *bios_module;
 
 /* Initialise hypercall stubs with RET, rendering them no-ops. */
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -305,8 +352,17 @@ int main(void)
 }
 
 printf("Loading %s ...\n", bios->name);
-if ( bios->bios_load )
-bios->bios_load(bios);
+bios_module = get_module_entry(hvm_start_info, "firmware");
+if ( bios_module && bios->bios_load )
+{
+uint32_t paddr = bios_module->paddr;
+
+bios->bios_load(bios, (void*)paddr, bios_module->size);
+}
+else if ( bios->bios_load )
+{
+bios->bios_load(bios, NULL, 0);
+}
 else
 {
 BUG_ON(bios->bios_address + bios->image_size >
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index e7d0785..60d000f 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -93,7 +93,8 @@ static void ovmf_finish_bios_info(void)
 info->checksum = -checksum;
 }
 
-static void ovmf_load(const struct bios_config 

[Xen-devel] [PATCH v8 02/13] libxc: Prepare a start info structure for hvmloader

[Wei Liu]

From: Anthony PERARD 

... and load BIOS/UEFI firmware into guest memory.

This adds a new firmware module, system_firmware_module. It is loaded in
the guest memory and final location is provided to hvmloader via the
hvm_start_info struct.

This patch create the hvm_start_info struct for HVM guest that have a
device model, so this is now common code with HVM guest without device
model.

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 
---
Changes in v8:
- rebased on top of staging

Changes in V6:
- change description (for verbose output) of the allocation of
  hvm_start_info from "HVMlite start info" to "HVM start info".

Changes in V5:
- in alloc_magic_pages_hvm, check dom->device_model only once instead of
  twice (fold second if into previous else)
- rework add_module_to_list to make it easier to read
- also comment about the intended memory layout of start_info and the
  modules
- in bootlate_hvm(), drop start_page and use start_info as they point to
  the same address
- rename xc_dom_image.bios_module to xc_dom_image.system_firmware_module
- rename module name to "firmware" (was "bios")

Changes in V4:
- change title to suggest the change of beavior
- remove code to load acpi tables (dsdt)
- Update public/xen.h about hvm_start_info available on other HVM guest
  in %ebx.

Changes in V3:
- rename acpi_table_module to full_acpi_module.
- factorise module loading, using new function to load existing optinal
  module, this should not change anything
- should now use the same code to loads modules as for HVMlite VMs.
  this avoid duplication of code.
- no more generic cmdline with a list of modules, each module have its name
  in the module specific cmdline.
- scope change for common code between hvmlite and hvmloader
---
 tools/libxc/include/xc_dom.h   |   3 +
 tools/libxc/xc_dom_hvmloader.c |   3 +
 tools/libxc/xc_dom_x86.c   | 152 +
 3 files changed, 115 insertions(+), 43 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index cac4698..de7dca9 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -209,6 +209,9 @@ struct xc_dom_image {
 /* If unset disables the setup of the IOREQ pages. */
 bool device_model;
 
+/* BIOS/Firmware passed to HVMLOADER */
+struct xc_hvm_firmware_module system_firmware_module;
+
 /* Extra ACPI tables passed to HVMLOADER */
 struct xc_hvm_firmware_module acpi_module;
 
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 8150b74..6eb8516 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -169,6 +169,9 @@ static int modules_init(struct xc_dom_image *dom)
 {
 int rc;
 
+rc = module_init_one(dom, >system_firmware_module,
+ "System Firmware module");
+if ( rc ) goto err;
 rc = module_init_one(dom, >acpi_module, "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, >smbios_module, "SMBIOS module");
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index d9747b4..0eab8a7 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -70,6 +70,9 @@
 #define round_up(addr, mask) ((addr) | (mask))
 #define round_pg_up(addr)  (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 
1))
 
+#define HVMLOADER_MODULE_MAX_COUNT 1
+#define HVMLOADER_MODULE_NAME_SIZE 10
+
 struct xc_dom_params {
 unsigned levels;
 xen_vaddr_t vaddr_mask;
@@ -591,6 +594,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 xc_interface *xch = dom->xch;
+size_t start_info_size = sizeof(struct hvm_start_info);
 
 /* Allocate and clear special pages. */
 for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
@@ -625,8 +629,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 
 if ( !dom->device_model )
 {
-size_t start_info_size = sizeof(struct hvm_start_info);
-
 if ( dom->cmdline )
 {
 dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
@@ -636,17 +638,18 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 /* Limited to one module. */
 if ( dom->ramdisk_blob )
 start_info_size += sizeof(struct hvm_modlist_entry);
-
-rc = xc_dom_alloc_segment(dom, >start_info_seg,
-  "HVMlite start info", 0, start_info_size);
-if ( rc != 0 )
-{
-DOMPRINTF("Unable to reserve memory for the start info");
-goto out;
-}
 }
 else
 {
+start_info_size +=
+sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
+/*
+ * Add extra space to write modules name.
+ * The HVMLOADER_MODULE_NAME_SIZE accounts for 

[Xen-devel] [PATCH v8 08/13] hvmloader: Load SeaBIOS from hvm_start_info modules

[Wei Liu]

From: Anthony PERARD 

... and do not include the SeaBIOS ROM into hvmloader anymore.

This also fix the dependency on roms.inc, hvmloader.o does not include it.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Change in V6:
  acked

Change in V5:
- update BUG_ON in seabios_setup_e820().

Change in V4:
- check that seabios_config.bios_address have a probably good value
  instead of checking only if it's set.

Change in V3:
- change makefile to not include seabios roms into roms.inc.
- update the struct bios_config with the location of the bios blob.
---
 tools/firmware/hvmloader/Makefile  | 15 +--
 tools/firmware/hvmloader/seabios.c | 25 +++--
 2 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index f2f4791..ed0bfad 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -45,7 +45,6 @@ CIRRUSVGA_DEBUG ?= n
 
 OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
-SEABIOS_DIR := ../seabios-dir
 
 ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM:= ../vgabios/VGABIOS-lgpl-latest.bin
@@ -80,19 +79,13 @@ endif
 ifeq ($(CONFIG_SEABIOS),y)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
-ifeq ($(SEABIOS_PATH),)
-   SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-else
-   SEABIOS_ROM := $(SEABIOS_PATH)
-endif
-ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -109,12 +102,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(SEABIOS_ROM),)
-   echo "#ifdef ROM_INCLUDE_SEABIOS" >> $@.new
-   sh ./mkhex seabios $(SEABIOS_ROM) >> $@.new
-   echo "#endif" >> $@.new
-endif
-
 ifneq ($(OVMF_ROM),)
echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index 2fbc3af..5c9a351 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -28,9 +28,6 @@
 #include "acpi/acpi2_0.h"
 #include "acpi/libacpi.h"
 
-#define ROM_INCLUDE_SEABIOS
-#include "roms.inc"
-
 extern unsigned char dsdt_anycpu_qemu_xen[];
 extern int dsdt_anycpu_qemu_xen_len;
 
@@ -128,22 +125,30 @@ static void seabios_setup_e820(void)
 struct e820entry *e820 = scratch_alloc(sizeof(struct e820entry)*16, 0);
 info->e820 = (uint32_t)e820;
 
+/* Upper boundary already checked by seabios_load(). */
+BUG_ON(seabios_config.bios_address < 0x000c);
 /* SeaBIOS reserves memory in e820 as necessary so no low reservation. */
-info->e820_nr = build_e820_table(e820, 0, 0x10-sizeof(seabios));
+info->e820_nr = build_e820_table(e820, 0, seabios_config.bios_address);
 dump_e820_table(e820, info->e820_nr);
 }
 
-struct bios_config seabios_config = {
-.name = "SeaBIOS",
+static void seabios_load(const struct bios_config *bios,
+ void *bios_addr, uint32_t bios_length)
+{
+unsigned int bios_dest = 0x10 - bios_length;
 
-.image = seabios,
-.image_size = sizeof(seabios),
+BUG_ON(bios_dest + bios_length > HVMLOADER_PHYSICAL_ADDRESS);
+memcpy((void *)bios_dest, bios_addr, bios_length);
+seabios_config.bios_address = bios_dest;
+seabios_config.image_size = bios_length;
+}
 
-.bios_address = 0x10 - sizeof(seabios),
+struct bios_config seabios_config = {
+.name = "SeaBIOS",
 
 .load_roms = NULL,
 
-.bios_load = NULL,
+.bios_load = seabios_load,
 
 .bios_info_setup = seabios_setup_bios_info,
 .bios_info_finish = seabios_finish_bios_info,
-- 
2.1.4


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

[Xen-devel] [PATCH v8 01/13] libxc: Rework extra module initialisation

[Wei Liu]

From: Anthony PERARD 

This patch use xc_dom_alloc_segment() to allocate the memory space for the
ACPI modules and the SMBIOS modules. This is to replace the arbitrary
placement of 1MB (+ extra for MB alignement) after the hvmloader image.

This patch can help if one add extra ACPI table and hvmloader contain
OVMF (OVMF is a 2MB binary), as in that case the extra ACPI table could
easily be loaded past the address 4MB, but hvmloader use a range of
memory from 4MB to 10MB to perform tests and in the process, clears the
memory, before loading the modules.

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 
---
Changes in V6:
- in module_init_one(), check that the module is to be loaded bellow
  dom->mmio_start instead of UINT32_MAX.

Changes in V5:
- rewrite patch description

Changes in V4:
- check that guest_addr_out have a reasonable value.

New patch in V3.
---
 tools/libxc/xc_dom_hvmloader.c | 133 +
 1 file changed, 40 insertions(+), 93 deletions(-)

diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 330d5e8..8150b74 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -129,98 +129,54 @@ static elf_errorstatus xc_dom_parse_hvm_kernel(struct 
xc_dom_image *dom)
 return rc;
 }
 
-static int modules_init(struct xc_dom_image *dom,
-uint64_t vend, struct elf_binary *elf,
-uint64_t *mstart_out, uint64_t *mend_out)
+static int module_init_one(struct xc_dom_image *dom,
+   struct xc_hvm_firmware_module *module,
+   char *name)
 {
-#define MODULE_ALIGN 1UL << 7
-#define MB_ALIGN 1UL << 20
-#define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
-uint64_t total_len = 0, offset1 = 0;
+struct xc_dom_seg seg;
+void *dest;
 
-if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0 )
-return 0;
-
-/* Find the total length for the firmware modules with a reasonable large
- * alignment size to align each the modules.
- */
-total_len = MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
-offset1 = total_len;
-total_len += MKALIGN(dom->smbios_module.length, MODULE_ALIGN);
-
-/* Want to place the modules 1Mb+change behind the loader image. */
-*mstart_out = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
-*mend_out = *mstart_out + total_len;
-
-if ( *mend_out > vend )
-return -1;
-
-if ( dom->acpi_module.length != 0 )
-dom->acpi_module.guest_addr_out = *mstart_out;
-if ( dom->smbios_module.length != 0 )
-dom->smbios_module.guest_addr_out = *mstart_out + offset1;
+if ( module->length )
+{
+if ( xc_dom_alloc_segment(dom, , name, 0, module->length) )
+goto err;
+dest = xc_dom_seg_to_ptr(dom, );
+if ( dest == NULL )
+{
+DOMPRINTF("%s: xc_dom_seg_to_ptr(dom, ) => NULL",
+  __FUNCTION__);
+goto err;
+}
+memcpy(dest, module->data, module->length);
+module->guest_addr_out = seg.vstart;
+
+assert(dom->mmio_start > 0 && dom->mmio_start < UINT32_MAX);
+if ( module->guest_addr_out > dom->mmio_start ||
+ module->guest_addr_out + module->length > dom->mmio_start )
+{
+DOMPRINTF("%s: Module %s would be loaded abrove 4GB",
+  __FUNCTION__, name);
+goto err;
+}
+}
 
 return 0;
+err:
+return -1;
 }
 
-static int loadmodules(struct xc_dom_image *dom,
-   uint64_t mstart, uint64_t mend,
-   uint32_t domid)
+static int modules_init(struct xc_dom_image *dom)
 {
-privcmd_mmap_entry_t *entries = NULL;
-unsigned long pfn_start;
-unsigned long pfn_end;
-size_t pages;
-uint32_t i;
-uint8_t *dest;
-int rc = -1;
-xc_interface *xch = dom->xch;
-
-if ( mstart == 0 || mend == 0 )
-return 0;
-
-pfn_start = (unsigned long)(mstart >> PAGE_SHIFT);
-pfn_end = (unsigned long)((mend + PAGE_SIZE - 1) >> PAGE_SHIFT);
-pages = pfn_end - pfn_start;
-
-/* Map address space for module list. */
-entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-if ( entries == NULL )
-goto error_out;
-
-for ( i = 0; i < pages; i++ )
-entries[i].mfn = (mstart >> PAGE_SHIFT) + i;
-
-dest = xc_map_foreign_ranges(
-xch, domid, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << 
PAGE_SHIFT,
-entries, pages);
-if ( dest == NULL )
-goto error_out;
-
-/* Zero the range so padding is clear between modules */
-memset(dest, 0, pages << PAGE_SHIFT);
-
-/* Load modules into range */
-if ( dom->acpi_module.length != 0 )
-{
-memcpy(dest,
-   dom->acpi_module.data,
-   

[Xen-devel] [PATCH v8 04/13] firmware/makefile: install BIOS blob ...

[Wei Liu]

From: Anthony PERARD 

... into the firmware directory, along with hvmloader.

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 

---
No change in V6.
- acked

Change in V5:
- remove use of "variable" for SEABIOS_ROM and OVMF_ROM location
  there are static location
- install seabios as bios.bin instead of seabios.bin
Change in V4:
- remove install of acpi dsdt table

Change in V3:
- do not check if ROMs file exist before installing, they should exist
- change rules for dsdt_anycpu_qemu_xen.c in oder to generate both .c and
  .aml files without changing temporarly the other dsdt_*.c rules.
---
 tools/firmware/Makefile | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 6cc86ce..82b1f6b 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -45,6 +45,16 @@ endif
 install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
+ifeq ($(CONFIG_SEABIOS),y)
+ifeq ($(SEABIOS_PATH),)
+   $(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/bios.bin
+endif
+endif
+ifeq ($(CONFIG_OVMF),y)
+ifeq ($(OVMF_PATH),)
+   $(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
+endif
+endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
2.1.4


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

[Xen-devel] [PATCH v8 06/13] hvmloader: Grab the hvm_start_info pointer

[Wei Liu]

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Changes in V6:
- include xen/arch-x86/hvm/start_info.h

Change in V4:
- remove struct hvm_info_start redefinition, as it's moved to
  public/xen.h in a previous patch.

Change in V3:
- remove cmdline parser
- load hvm_start_info pointer earlier, before calling main().
- Add struct hvm_start_info definition to hvmloader.
---
 tools/firmware/hvmloader/hvmloader.c | 6 ++
 tools/firmware/hvmloader/util.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 47290e5..67a18af 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -28,6 +28,9 @@
 #include "vnuma.h"
 #include 
 #include 
+#include 
+
+const struct hvm_start_info *hvm_start_info;
 
 asm (
 ".text   \n"
@@ -46,6 +49,8 @@ asm (
 "ljmp $"STR(SEL_CODE32)",$1f \n"
 "1:  movl $stack_top,%esp\n"
 "movl %esp,%ebp  \n"
+/* store HVM start info ptr */
+"mov  %ebx, hvm_start_info   \n"
 "call main   \n"
 /* Relocate real-mode trampoline to 0x0. */
 "mov  $trampoline_start,%esi \n"
@@ -270,6 +275,7 @@ int main(void)
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
 
 printf("HVM Loader\n");
+BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
 
 init_hypercalls();
 
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index b226df4..0fb266e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -158,6 +158,9 @@ static inline void cpu_relax(void)
 struct hvm_info_table *get_hvm_info_table(void) __attribute__ ((const));
 #define hvm_info (get_hvm_info_table())
 
+/* HVM start info */
+extern const struct hvm_start_info *hvm_start_info;
+
 /* String and memory functions */
 int strcmp(const char *cs, const char *ct);
 int strncmp(const char *s1, const char *s2, uint32_t n);
-- 
2.1.4


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

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

[Dario Faggioli]

On Wed, 2016-08-17 at 13:04 +, osstest service owner wrote:
> flight 100518 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/100518/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-winxpsp3 17 guest-start/win.repeat fail
> REGR. vs. 100488
> 
So, FTR, Jan pointed out to me and George that this has failed like
this:

Aug 17 04:51:03.173959 (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Not 
tainted ]
Aug 17 04:51:23.770049 (XEN) CPU:0
Aug 17 04:51:23.770111 (XEN) RIP:e008:[] 
sched_credit.c#_csched_cpu_pick+0x1be/0x62a
Aug 17 04:51:23.778034 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
(d0v0)
Aug 17 04:51:23.786025 (XEN) rax: 0200200200200200   rbx: 0003   
rcx: 82d08032e280
Aug 17 04:51:23.794013 (XEN) rdx: 0031dd4d8200   rsi: 82d0802ecd20   
rdi: 83009550fca8
Aug 17 04:51:23.801996 (XEN) rbp: 83009550fd18   rsp: 83009550fc28   
r8:  0004
Aug 17 04:51:23.810025 (XEN) r9:     r10:    
r11: 
Aug 17 04:51:23.817966 (XEN) r12: 0003   r13: 8300952f9000   
r14: 83024e88cf50
Aug 17 04:51:23.825975 (XEN) r15: 82d080344ec0   cr0: 80050033   
cr4: 001526e0
Aug 17 04:51:23.833993 (XEN) cr3: 000240f83000   cr2: 7f0d36e51b0d
Aug 17 04:51:23.834030 (XEN) ds:    es:    fs:    gs:    ss: 
e010   cs: e008
Aug 17 04:51:23.841976 (XEN) Xen code around  
(sched_credit.c#_csched_cpu_pick+0x1be/0x62a):
Aug 17 04:51:23.849972 (XEN)  18 48 8b 00 48 8b 40 28 <48> 8b 40 10 66 81 38 ff 
7f 75 0f 44 3b 25 7d 12
Aug 17 04:51:23.857973 (XEN) Xen stack trace from rsp=83009550fc28:
Aug 17 04:51:23.865960 (XEN)83025d853700 0002001f 
82d080344ec8 82d080344ec0
Aug 17 04:51:23.873956 (XEN)82d0802e96c0 830257af5570 
00010001 
Aug 17 04:51:23.881954 (XEN)0297 83009550fc88 
82d080130a3e 
Aug 17 04:51:23.889950 (XEN)0206 83009550fca8 
82d080130a3e 83025d844000
Aug 17 04:51:23.897962 (XEN)0006  
 
Aug 17 04:51:23.906002 (XEN)000f  
 
Aug 17 04:51:23.913973 (XEN)83009550fd38 8300952f9000 
830247c96000 
Aug 17 04:51:23.914015 (XEN)83024e88cf50  
83009550fd28 82d0801251f8
Aug 17 04:51:23.921976 (XEN)83009550fd78 82d080125227 
83009550fd58 82d08013c7a9
Aug 17 04:51:23.929974 (XEN)0003 8300952f9000 
830247c96000 
Aug 17 04:51:23.937961 (XEN)0003  
83009550fd98 82d08012d3ba
Aug 17 04:51:23.945951 (XEN)8300952f9000 830247c96000 
83009550fdd8 82d080105d70
Aug 17 04:51:23.953969 (XEN)830257af5570  
830247c96000 7f0d38354004
Aug 17 04:51:23.961962 (XEN)830257af5570 0002 
83009550fef8 82d0801039df
Aug 17 04:51:23.969963 (XEN)83009550fe18 82d0 
 0003
Aug 17 04:51:23.977950 (XEN) 000242214025 
8301 83009550fea8
Aug 17 04:51:23.985962 (XEN)83009550fea4 82e004818900 
000c000f 7f0d38140013
Aug 17 04:51:23.993958 (XEN)0002  
7ffe23e9a7c0 7f0d36e456c8
Aug 17 04:51:24.001946 (XEN) 7ffe23e9a7f0 
00407f60 7f0d3814b2e5
Aug 17 04:51:24.009952 (XEN)00a399f0 0013 
0002 0013
Aug 17 04:51:24.017959 (XEN) Xen call trace:
Aug 17 04:51:24.017992 (XEN)[] 
sched_credit.c#_csched_cpu_pick+0x1be/0x62a
Aug 17 04:51:24.025957 (XEN)[] 
sched_credit.c#csched_cpu_pick+0x1b/0x1d
Aug 17 04:51:24.033963 (XEN)[] 
sched_credit.c#csched_vcpu_insert+0x2d/0x157
Aug 17 04:51:24.041949 (XEN)[] sched_init_vcpu+0x1b8/0x1fe
Aug 17 04:51:24.041984 (XEN)[] alloc_vcpu+0x1c8/0x2c7
Aug 17 04:51:24.049995 (XEN)[] do_domctl+0x7ea/0x1b24
Aug 17 04:51:24.057972 (XEN)[] lstar_enter+0xdd/0x137
Aug 17 04:51:24.058011 (XEN) 
Aug 17 04:51:24.065961 (XEN) 
Aug 17 04:51:24.065989 (XEN) 
Aug 17 04:51:24.066018 (XEN) Panic on CPU 0:
Aug 17 04:51:24.073936 (XEN) GENERAL PROTECTION FAULT
Aug 17 04:51:24.073967 (XEN) [error_code=]
Aug 17 04:51:24.073994 (XEN) 

This looks to me the same thing reported by Andrew a couple of days
ago, and then covered in the following emails/threads:

https://lists.xen.org/archives/html/xen-devel/2016-08/msg01677.html
https://lists.xen.org/archives/html/xen-devel/2016-08/msg01679.html

[Xen-devel] [xen-unstable test] 100539: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 100537 pass in 
100539
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 100537

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start.2   fail blocked in 100537
 test-amd64-amd64-xl-rtds 9 debian-install fail in 100537 blocked in 100539
 build-amd64-rumpuserxen   6 xen-buildfail  like 100537
 build-i386-rumpuserxen6 xen-buildfail  like 100537
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100537
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100537
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100537
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100537

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

version targeted for testing:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952
baseline version:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952

Last test of basis   100539  2016-08-18 05:15:52 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17031 days0 attempts

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

Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions

[Jan Beulich]

>>> On 18.08.16 at 14:18,  wrote:
> On Thu, Aug 18, 2016 at 03:41:06AM -0600, Jan Beulich wrote:
>> >>> On 18.08.16 at 10:53,  wrote:
>> > On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote:
>> >> >>> On 11.08.16 at 16:12,  wrote:
>> >>  On 06.08.16 at 01:04,  wrote:
>> >> >> --- a/xen/arch/x86/boot/reloc.c
>> >> >> +++ b/xen/arch/x86/boot/reloc.c
>> >> >> @@ -32,60 +32,69 @@ typedef unsigned int u32;
>> >> >>
>> >> >>  static u32 alloc;
>> >> >>
>> >> >> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
>> >> >> +static u32 alloc_mem(u32 bytes)
>> >> >
>> >> > Conversion of alloc to be of pointer type (in the earlier patch), and
>> >> > then making the return type here and ...
>> >> >
>> >> >> +static u32 copy_mem(u32 src, u32 bytes)
>> >> >
>> >> > ... all of the types here follow suit would apparently be quite
>> >> > beneficial to the number of casts needed.
>> >>
>> >> Or maybe, considering patch 8, in a slight variation thereof: Do
>> >> the conversion as suggested, but have a helper wrapper of the
>> >> type above, taking care of all the casting. That way both the
>> >> actual implementation and the callers can stay (mostly) cast free.
>> >
>> > We should take into account patch 9 here too. Looking at code after
>> > it I think that right now it is very well optimized in terms of casts.
>> > I cannot see room for further improvement. Every change you proposed
>> > here and there does not improve final code. It justs move/change casts
>> > to/in different places. So, I think that it does not pay change casts
>> > here and in earlier patches. At least in the way you proposed until now.
>>
>> What I've suggested above at least makes both the actual function
>> and its wrapper consistent, and hence usable (without casts) by
>> callers dealing with either only numbers of only pointers. Are you
>> saying there are no such "clean" callers? That would put the overall
>> code in a pretty bad light imo.
> 
> alloc_mem() is mostly used by callers playing with numbers only. copy_mem()
> is only one user of it which plays with pointers. However, copy_mem() 
> returns
> numbers, so, wrapper does not change a lot. It just moves casts to other 
> places.
> Am I missing something?

I can't easily tell without seeing a tree with everything applied.

Jan


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

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 18.08.16 at 13:41,  wrote:
> On Thu, Aug 18, 2016 at 03:43:54AM -0600, Jan Beulich wrote:
>> >>> On 18.08.16 at 11:23,  wrote:
>> > On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
>> >> >>> On 06.08.16 at 01:04,  wrote:
>> >> > +for ( i = 0; i < mbi_out->mmap_length / 
>> >> > sizeof(memory_map_t); i++
>> > )
>> >> > +{
>> >> > +/* Init size member properly. */
>> >> > +mmap_dst[i].size = sizeof(memory_map_t);
>> >> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
>> >> > +/* Now copy a given region data. */
>> >> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
>> >> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 
>> >> > 32);
>> >> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
>> >> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
>> >>
>> >> ... here you index an array of type multiboot2_memory_map_t.
>> >
>> > All calculations looks correct, so, I am not sure what is wrong here.
>> >
>> >> Also note that in any event you should check that
>> >> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
>> >> to go with the flexible model, ==).
>> >
>> > This make sense to some extent. However, I am not sure what we should do
>> > if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
>> > model). Just do not fill memory map? Probably yes...
>>
>> Perhaps you misunderstood my comment?
>> entry_size < sizeof(*mmap_src) is a case we simply can't deal with,
>> so you should (as you say) not obtain the memory map, which I
>> assume is equivalent to not failing the boot altogether. The point
> 
> Yep.
> 
>> of interest really is entry_size > sizeof(*mmap_src), and that's
>> what mmap_src[i] above doesn't handle correctly.
> 
> Ahhh... I have missed that. So, we can fix it in that way:
>   mmap_src = (void *)mmap_src + i * get_mb2_data(tag, mmap, entry_size);
>   mmap_dst[i].base_addr_low = (u32)mmap_src.addr;
>   ...
> 
> Does it make sense?

Yes, that's what I had in mind.

Jan


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

Re: [Xen-devel] [PATCH] x86: Add a tboot Kconfig option

[Jan Beulich]

>>> On 18.08.16 at 14:06,  wrote:
> On 17/08/16 19:17, Derek Straka wrote:
>> Allows for the conditional inclusion of tboot related functionality via 
>> Kconfig
>>
>> The default configuration for the new CONFIG_TBOOT option is 'y', so the
>> behavior out of the box remains unchanged.  The addition of the option allows
>> advanced users to disable system behaviors associated with tboot at compile
>> time rather than relying on the run-time detection and configuration.

You say "advanced users" here, yet ...

>> +config TBOOT
>> +bool "Xen tboot support"
>> +default y
>> +depends on X86

... there's no dependency on EXPERT here. User selectable options
not depending on EXPERT need extra good reasoning on why they
need to be that way.

>> @@ -127,6 +128,17 @@ int tboot_parse_dmar_table(acpi_table_handler 
>> dmar_handler);
>>  int tboot_s3_resume(void);
>>  void tboot_s3_error(int error);
>>  int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>> +#else
>> +static inline void tboot_probe(void) {}
>> +static inline void tboot_shutdown(uint32_t shutdown_type) {}
>> +static inline int tboot_in_measured_env(void) {return 0;}
>> +static inline int tboot_protect_mem_regions(void) {return 1;}
>> +static inline int tboot_parse_dmar_table(acpi_table_handler dmar_handler) 
>> {return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);}
> 
> Please include spaces immediately inside the braces.

And the last one looks to be an overly long line.

Jan


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

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

[Ed Swierk]

On Tue, Aug 16, 2016 at 3:07 AM, Juergen Gross  wrote:
> On 15/08/16 17:02, Jan Beulich wrote:
>> This should really only be done for XS_TRANSACTION_END messages, or
>> else at least some of the xenstore-* tools don't work anymore.
>>
>> Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
>> Reported-by: Richard Schütz 
>> Cc: 
>> Signed-off-by: Jan Beulich 
>> Tested-by: Richard Schütz 
>
> Reviewed-by: Juergen Gross 

Confirmed that this patch fixes xenstore-read, xenstore-ls et al, on
stable kernel 4.4.17.

It should also go to 4.7, 4.6, 4.1, 3.18.

--Ed

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  361db13b0380a3462f788d44076f42f6f155e719
baseline version:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952

Last test of basis   100535  2016-08-17 14:07:14 Z0 days
Testing same since   100543  2016-08-18 11:01:54 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

On Thu, Aug 18, 2016 at 03:41:06AM -0600, Jan Beulich wrote:
> >>> On 18.08.16 at 10:53,  wrote:
> > On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote:
> >> >>> On 11.08.16 at 16:12,  wrote:
> >>  On 06.08.16 at 01:04,  wrote:
> >> >> --- a/xen/arch/x86/boot/reloc.c
> >> >> +++ b/xen/arch/x86/boot/reloc.c
> >> >> @@ -32,60 +32,69 @@ typedef unsigned int u32;
> >> >>
> >> >>  static u32 alloc;
> >> >>
> >> >> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> >> >> +static u32 alloc_mem(u32 bytes)
> >> >
> >> > Conversion of alloc to be of pointer type (in the earlier patch), and
> >> > then making the return type here and ...
> >> >
> >> >> +static u32 copy_mem(u32 src, u32 bytes)
> >> >
> >> > ... all of the types here follow suit would apparently be quite
> >> > beneficial to the number of casts needed.
> >>
> >> Or maybe, considering patch 8, in a slight variation thereof: Do
> >> the conversion as suggested, but have a helper wrapper of the
> >> type above, taking care of all the casting. That way both the
> >> actual implementation and the callers can stay (mostly) cast free.
> >
> > We should take into account patch 9 here too. Looking at code after
> > it I think that right now it is very well optimized in terms of casts.
> > I cannot see room for further improvement. Every change you proposed
> > here and there does not improve final code. It justs move/change casts
> > to/in different places. So, I think that it does not pay change casts
> > here and in earlier patches. At least in the way you proposed until now.
>
> What I've suggested above at least makes both the actual function
> and its wrapper consistent, and hence usable (without casts) by
> callers dealing with either only numbers of only pointers. Are you
> saying there are no such "clean" callers? That would put the overall
> code in a pretty bad light imo.

alloc_mem() is mostly used by callers playing with numbers only. copy_mem()
is only one user of it which plays with pointers. However, copy_mem() returns
numbers, so, wrapper does not change a lot. It just moves casts to other places.
Am I missing something?

Daniel

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

Re: [Xen-devel] [PATCH] x86: Add a tboot Kconfig option

[Andrew Cooper]

On 17/08/16 19:17, Derek Straka wrote:
> Allows for the conditional inclusion of tboot related functionality via 
> Kconfig
>
> The default configuration for the new CONFIG_TBOOT option is 'y', so the
> behavior out of the box remains unchanged.  The addition of the option allows
> advanced users to disable system behaviors associated with tboot at compile
> time rather than relying on the run-time detection and configuration.
>
> Signed-off-by: Derek Straka 

+1 for the principle.  Some suggestions however.

> ---
>  xen/Rules.mk|  2 +-
>  xen/arch/x86/Makefile   |  2 +-
>  xen/common/Kconfig  | 11 +++
>  xen/include/asm-x86/tboot.h | 12 
>  4 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index ebe1dc0..12d3184 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -44,7 +44,7 @@ ALL_OBJS-y   += $(BASEDIR)/common/built_in.o
>  ALL_OBJS-y   += $(BASEDIR)/drivers/built_in.o
>  ALL_OBJS-y   += $(BASEDIR)/xsm/built_in.o
>  ALL_OBJS-y   += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
> -ALL_OBJS-$(CONFIG_X86)   += $(BASEDIR)/crypto/built_in.o
> +ALL_OBJS-$(CONFIG_TBOOT)   += $(BASEDIR)/crypto/built_in.o

TBOOT is currently the only consumer, but there are a few other
suggestions on the horizons.

I think it might be better to have a CONFIG_CRYPTO (default to n) which
is selected by CONFIG_TBOOT.  When future work (e.g. hypervisor side
signature checks on hotpatches?) gets completed, it can also select
CONFIG_CRYPTO.

>  
>  CFLAGS += -nostdinc -fno-builtin -fno-common
>  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index b18f033..5b9e9da 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -62,7 +62,7 @@ obj-y += trace.o
>  obj-y += traps.o
>  obj-y += usercopy.o
>  obj-y += x86_emulate.o
> -obj-y += tboot.o
> +obj-$(CONFIG_TBOOT) += tboot.o
>  obj-y += hpet.o
>  obj-y += vm_event.o
>  obj-y += xstate.o
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 51afa24..cb9a92a 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -218,6 +218,17 @@ config SCHED_DEFAULT
>  
>  endmenu
>  
> +# Enable/Disable tboot support

This comment isn't very helpful.  I would simply omit it.  (In fact, I
am going to submit a patch stripping all such comments from the existing
Kconfig files)

> +config TBOOT
> + bool "Xen tboot support"
> + default y
> + depends on X86
> + ---help---
> +   Allows support for Trusted Boot using the Intel(R) Trusted Execution
> +   Technology (TXT)
> +
> +   If unsure, say Y.

This should live in xen/arch/x86/Kconfig, rather than common/Kconfig

> +
>  # Enable/Disable live patching support
>  config LIVEPATCH
>   bool "Live patching support (TECH PREVIEW)"
> diff --git a/xen/include/asm-x86/tboot.h b/xen/include/asm-x86/tboot.h
> index d242862..977e509 100644
> --- a/xen/include/asm-x86/tboot.h
> +++ b/xen/include/asm-x86/tboot.h
> @@ -119,6 +119,7 @@ typedef struct __packed {
>  
>  extern tboot_shared_t *g_tboot_shared;
>  
> +#ifdef CONFIG_TBOOT
>  void tboot_probe(void);
>  void tboot_shutdown(uint32_t shutdown_type);
>  int tboot_in_measured_env(void);
> @@ -127,6 +128,17 @@ int tboot_parse_dmar_table(acpi_table_handler 
> dmar_handler);
>  int tboot_s3_resume(void);
>  void tboot_s3_error(int error);
>  int tboot_wake_ap(int apicid, unsigned long sipi_vec);
> +#else
> +static inline void tboot_probe(void) {}
> +static inline void tboot_shutdown(uint32_t shutdown_type) {}
> +static inline int tboot_in_measured_env(void) {return 0;}
> +static inline int tboot_protect_mem_regions(void) {return 1;}
> +static inline int tboot_parse_dmar_table(acpi_table_handler dmar_handler) 
> {return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);}

Please include spaces immediately inside the braces.

~Andrew

> +static inline int tboot_s3_resume(void) { return 0; }
> +
> +static inline void tboot_s3_error(int error) {}
> +static inline int tboot_wake_ap(int apicid, unsigned long sipi_vec) {return 
> 1;}
> +#endif /* CONFIG_TBOOT */
>  
>  #endif /* __TBOOT_H__ */
>  


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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Julien Grall]

On 17/08/16 21:08, Shanker Donthineni wrote:



On 08/17/2016 06:11 AM, Julien Grall wrote:

On 17/08/16 03:19, Shanker Donthineni wrote:

Hi Julien,


Hello Shanker,


On 07/27/2016 12:09 PM, Julien Grall wrote:

Translating a VA to a IPA is expensive. Currently, Xen is assuming that
HPFAR_EL2 is only valid when the stage-2 data/instruction abort
happened
during a translation table walk of a first stage translation (i.e S1PTW
is set).

However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
also valid when the data/instruction abort occured for a translation
fault.

With this change, the VA -> IPA translation will only happen for
permission faults that are not related to a translation table of a
first stage translation.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Use fsc in the switch in do_trap_data_abort_guest
---
  xen/arch/arm/traps.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ea105f2..83a30fa 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2382,13 +2382,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t
gva)
  return ipa;
  }

+static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
+{
+/*
+ * HPFAR is valid if one of the following cases are true:
+ *  1. the stage 2 fault happen during a stage 1 page table walk
+ *  (the bit ESR_EL2.S1PTW is set)
+ *  2. the fault was due to a translation fault
+ *
+ * Note that technically HPFAR is valid for other cases, but they
+ * are currently not supported by Xen.
+ */
+return s1ptw || (fsc == FSC_FLT_TRANS);


Yes, XEN is not supporting the stage 2 access flag but we should handle
a stage 2 address size fault.


The function hpfar_is_valid indicates whether the register HPFAR is
valid. If the function returns false, Xen will use the hardware do the
translation.

It will only lead to a waste of cycle but this is fine as the address
size fault is not a hot path for now.


I think we should do some thing like to below to match ARM ARM.

return s1ptw || (fsc != FSC_FLT_PERM);


This does not match the ARM ARM, with this check you consider that
HPFAR will be valid for all the fault but permission ones which is not
true.

I purposefully choose a white list because it is safer to use the
hardware to do the translation more often than the invert.

So I don't see why we should handle stage 2 access flag with the
current Xen. If you still disagree, please explain why with a concrete
example.



Agree with you, I have suggested the above change because I saw the same
check in Linux KVM.
As per ARM ARM, it should be 'return s1ptw || (fsc == FSC_FLT_TRANS) ||
(fsc == FSC_FLT_ACCESS) || (fsc == 0x00)';


Feel free to send a patch for this explaining why we would need to have 
the full check. But I don't think it is worth to test every case and 
therefore increasing the number of cycles of this function for faults we 
don't care so far.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

[Dario Faggioli]

And finally, Jan,

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote:
>
I think that these three:

> Dario Faggioli (24):
> 
>   xen: credit1: fix mask to be used for tickling in Credit1
>   xen: credit1: return the 'time remaining to the limit' as next 
> timeslice.
>   xen: credit2: properly schedule migration of a running vcpu.
>
Are (in due course, obviously) backport candidates.

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



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

Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

[Daniel Kiper]

On Thu, Aug 18, 2016 at 05:18:01AM -0600, Jan Beulich wrote:
> >>> On 18.08.16 at 12:30,  wrote:
> > On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
> >> >>> On 06.08.16 at 01:04,  wrote:
> >>
> >> Apart from the question of this probably better getting merged with
> >> the previous patch ...
> >>
> >> > --- a/xen/common/efi/boot.c
> >> > +++ b/xen/common/efi/boot.c
> >> > @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> > *SystemTable)
> >> >
> >> >  __set_bit(EFI_BOOT, );
> >> >
> >> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
> >> > +__set_bit(EFI_RS, );
> >> > +#endif
> >>
> >> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
> >> was given (and then efi_rs_enable) should go away. Oh, looks
> >> like that's the next patch, but I'd then again question the split.
> >
> > Do you suggest that patches 11-13 should be merged into one thing?
> > If it is OK for you I can do that.
> >
> >> > --- a/xen/include/xen/efi.h
> >> > +++ b/xen/include/xen/efi.h
> >> > @@ -12,6 +12,7 @@
> >> >  struct efi {
> >> >  unsigned long flags;/* Bit fields representing available EFI
> > features/properties */
> >> >  #define EFI_BOOT0   /* Were we booted from EFI? */
> >> > +#define EFI_RS  2   /* Can we use runtime services? */
> >>
> >> Why is this not the sequentially next number?
> >
> > I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).
>
> That'll then too end up more natural by merging the patches.

Potentially we can do that but patch 14 and 15 use efi_enabled().
So, we should merge patches 11-13 if you wish and leave 14-16 as is.

Daniel

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

Re: [Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

[Dario Faggioli]

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote:
> Hi everyone,
> 
> Here's another rather big scheduler-related series. The most of the
> content (as
> usual, lately) is about Credit2, but there are other things, about
> tracing and
> also about Credit1. In fact, this patch series introduces soft-
> affinity support
> for Credit2.
> 
And here's a git branch with the series applied:

git://xenbits.xen.org/people/dariof/xen.git  
rel/sched/misc-credit1-credit2-plus-credit2-softaff
http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/misc-credit1-credit2-plus-credit2-softaff

https://github.com/fdario/xen/tree/rel/sched/misc-credit1-credit2-plus-credit2-softaff

https://travis-ci.org/fdario/xen/builds/153230352

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



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

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Daniel Kiper]

On Thu, Aug 18, 2016 at 03:43:54AM -0600, Jan Beulich wrote:
> >>> On 18.08.16 at 11:23,  wrote:
> > On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
> >> >>> On 06.08.16 at 01:04,  wrote:
> >
> > [...]
> >
> >> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> >> > +mbi_out->flags |= MBI_MEMMAP;
> >> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> >> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> >> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
> >>
> >> Okay, here you use the entry size as provided by grub, allowing
> >> compatibility even when the boot loader uses a newer layout (with
> >> extra fields added to the end). However ...
> >>
> >> > +mbi_out->mmap_length *= sizeof(memory_map_t);
> >> > +
> >> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> >> > +
> >> > +mmap_src = get_mb2_data(tag, mmap, entries);
> >> > +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> >> > +
> >> > +for ( i = 0; i < mbi_out->mmap_length / 
> >> > sizeof(memory_map_t); i++
> > )
> >> > +{
> >> > +/* Init size member properly. */
> >> > +mmap_dst[i].size = sizeof(memory_map_t);
> >> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> >> > +/* Now copy a given region data. */
> >> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> >> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 
> >> > 32);
> >> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
> >> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
> >>
> >> ... here you index an array of type multiboot2_memory_map_t.
> >
> > All calculations looks correct, so, I am not sure what is wrong here.
> >
> >> Also note that in any event you should check that
> >> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
> >> to go with the flexible model, ==).
> >
> > This make sense to some extent. However, I am not sure what we should do
> > if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
> > model). Just do not fill memory map? Probably yes...
>
> Perhaps you misunderstood my comment?
> entry_size < sizeof(*mmap_src) is a case we simply can't deal with,
> so you should (as you say) not obtain the memory map, which I
> assume is equivalent to not failing the boot altogether. The point

Yep.

> of interest really is entry_size > sizeof(*mmap_src), and that's
> what mmap_src[i] above doesn't handle correctly.

Ahhh... I have missed that. So, we can fix it in that way:
  mmap_src = (void *)mmap_src + i * get_mb2_data(tag, mmap, entry_size);
  mmap_dst[i].base_addr_low = (u32)mmap_src.addr;
  ...

Does it make sense?

Daniel

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

[Xen-devel] [xen-unstable baseline-only test] 67551: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67551 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67551/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 67536

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 67536
 build-amd64-rumpuserxen   6 xen-buildfail   like 67536
 build-i386-rumpuserxen6 xen-buildfail   like 67536
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67536
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67536

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a
baseline version:
 xen  a55ad65d3a30d5b3a026a7481ce05f28065920f0

Last test of basis67536  2016-08-15 17:15:11 Z2 days
Testing same since67551  2016-08-17 22:24:23 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

[Jan Beulich]

>>> On 18.08.16 at 12:30,  wrote:
> On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
>> >>> On 06.08.16 at 01:04,  wrote:
>>
>> Apart from the question of this probably better getting merged with
>> the previous patch ...
>>
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable)
>> >
>> >  __set_bit(EFI_BOOT, );
>> >
>> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
>> > +__set_bit(EFI_RS, );
>> > +#endif
>>
>> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
>> was given (and then efi_rs_enable) should go away. Oh, looks
>> like that's the next patch, but I'd then again question the split.
> 
> Do you suggest that patches 11-13 should be merged into one thing?
> If it is OK for you I can do that.
> 
>> > --- a/xen/include/xen/efi.h
>> > +++ b/xen/include/xen/efi.h
>> > @@ -12,6 +12,7 @@
>> >  struct efi {
>> >  unsigned long flags;/* Bit fields representing available EFI 
> features/properties */
>> >  #define EFI_BOOT  0   /* Were we booted from EFI? */
>> > +#define EFI_RS2   /* Can we use runtime services? */
>>
>> Why is this not the sequentially next number?
> 
> I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).

That'll then too end up more natural by merging the patches.

Jan


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

Re: [Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c

[Jan Beulich]

>>> On 18.08.16 at 12:17,  wrote:
> On Wed, Aug 17, 2016 at 09:56:39AM -0600, Jan Beulich wrote:
>> >>> On 06.08.16 at 01:04,  wrote:
>> > A subsequent patch adds efi struct flags member which is used
>> > during runtime to differentiate between legacy BIOS and EFI
>> > platforms and multiboot2 and EFI native loader. So, efi symbol
>> > have to proper representation in ELF and PE Xen image. Hence,
>> > move efi struct initialization to xen/common/lib.c and remove
>> > efi symbol from ld script.
>> >
>> > Signed-off-by: Daniel Kiper 
>> > ---
>> > v4 - suggestions/fixes:
>> >- move efi struct initialization to xen/common/lib.c
>> >  and drop one from xen/arch/x86/efi/stub.c
>> >  (suggested by Jan Beulich),
>>
>> I recall I didn't like where you placed it last time round. I've just tried
>> to locate the old thread, but going back a whole year in the list archives
>> I was not able to find a mail with the title containing "move efi". Hence I
> 
> Here it is (I list just first email from thread in a given month):
>   https://lists.xen.org/archives/html/xen-devel/2016-04/msg02186.html 
>   https://lists.xen.org/archives/html/xen-devel/2016-05/msg02659.html 
>   https://lists.xen.org/archives/html/xen-devel/2016-06/msg00124.html 
>   https://lists.xen.org/archives/html/xen-devel/2016-07/msg00530.html 
> 
>> can only say what I think now, without reference to earlier remarks:
>> The struct currently isn't overly large, but I still don't see why non-EFI
>> builds need to include it instead of just the flags variable you mean to
>> introduce subsequently. And it's even less obvious what use it is on
>> platforms not even supporting EFI, i.e. ARM32.
> 
> I see two solutions for this issue:
>   - define efi struct members conditionally; this requires also
> some #ifs sprinkled over Xen code (not very nice) or other
> substantial changes,

That won't work, afaict, for the current model of building xen.efi
and xen.gz from mostly the same object files.

>   - replace efi.flags with efi_flags and leave existing code as is.
> 
> What is your choice?

Hence the latter would be my choice, unless you can give good
arguments in favor of another functioning solution.

Jan


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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Jan Beulich]

>>> On 18.08.16 at 12:16,  wrote:
> On 18/08/16 11:06, Jan Beulich wrote:
> On 17.08.16 at 22:32,  wrote:
>>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>>>The comment says:
>>>" /* Low ISA region is always mapped WB in page table. No need to track 
> *"
>> As per above it's not clear to me what this comment is backed by.
> 
> This states what is in the pagetables.  Not the combined result with MTRRs.
> 
> WB in the pagetables and WC/UB in the MTRRs is a legal combination which
> functions correctly.

True, but then again - haven't I been told multiple times that Linux
nowadays prefers to run without using MTRRs?

Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7822a1d91d53e80525f571183a24d54488f5437f
baseline version:
 ovmf a012df5ec643a0c08c2b723a02919a5c9373ca74

Last test of basis   100540  2016-08-18 05:15:52 Z0 days
Testing same since   100541  2016-08-18 09:15:15 Z0 days1 attempts


People who touched revisions under test:
  Eugene Cohen 
  Jiaxin Wu 
  Prince Agyeman 
  Zhang Lubo 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7822a1d91d53e80525f571183a24d54488f5437f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
7822a1d91d53e80525f571183a24d54488f5437f
+ branch=ovmf
+ revision=7822a1d91d53e80525f571183a24d54488f5437f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x7822a1d91d53e80525f571183a24d54488f5437f = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [MINIOS PATCH 3/3] x86: use unified linker script

[Juergen Gross]

On 18/08/16 12:15, Wei Liu wrote:
> There are only a few differences between i386 and x86-64 linker scripts.
> Unify them into one. Re-indent the file at the same time.
> 
> Construct a special rule in top-level directory to cope with the change.
> Ideally the build system should also be made more elegant, but
> overhauling the build system is out of scope of this patch.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Juergen Gross 


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

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Jan Beulich]

>>> On 17.08.16 at 22:08,  wrote:
> On 17/08/2016 20:57, Julien Grall wrote:
>> Hi Konrad,
>>
>> On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
 On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
>>
>> [...]
>>
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 22806b6..fe83653 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -82,6 +82,6 @@ subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>
>  .PHONY: tests
>  tests:
> -ifeq ($(XEN_TARGET_ARCH),x86_64)
> +ifneq ($(XEN_TARGET_ARCH),arm32)
>  $(MAKE) -f $(BASEDIR)/Rules.mk -C test livepatch
>  endif
> diff --git a/xen/common/test/Makefile b/xen/common/test/Makefile
> index 23dff1d..3eed6dd 100644
> --- a/xen/common/test/Makefile
> +++ b/xen/common/test/Makefile
> @@ -1,5 +1,11 @@
>  include $(XEN_ROOT)/Config.mk
>
> +ifeq ($(XEN_TARGET_ARCH),x86_64)
> +OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
> +else

 Is there any reason to fallback on arm64 flags by default? Would not
 it be
 better to have an else if here?

> +OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
>>>
>>> I presume you are referring to this comment. I am not sure how you would
>>> identify whether the elf64-littleaarch64 is not part of the OBJCOPY?
>>>
>>> Oh I guess you can: objcopy --info
>>>
>>> Or are you saying just use 'arm64' instead of 'aarch64' ?
>>
>> I was suggesting to do
>>
>> ifeq ($(XEN_TARGET_ARCH),x86_64))
>> OBJCOPY_MAGIC := ...
>> endif
>> ifeq ($(XEN_TARGET_ARCH),arm64))
>> OBJCOPY_MAGIC := ...
>> endif
> 
> You can chain "else ifeq" together like this in a makefile to avoid most
> of those endif's

Except that iirc that doesn't work with make 3.80, which is what I
think we document as a minimal requirement.

Jan


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

Re: [Xen-devel] [MINIOS PATCH 1/3] Introduce asm_macros.h

[Juergen Gross]

On 18/08/16 12:15, Wei Liu wrote:
> Ported from Xen Test Framework project (BSD license).
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Juergen Gross 


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

Re: [Xen-devel] [PATCH v3 31/38] altp2m: Introduce altp2m_switch_vcpu_altp2m_by_id

[George Dunlap]

On 16/08/16 23:17, Sergej Proskurin wrote:
> This commit adds the function "altp2m_switch_vcpu_altp2m_by_id" that is
> executed after checking whether the vcpu should be switched to a
> different altp2m within the function "altp2m_check".
> 
> Please note that in this commit, the function "p2m_altp2m_check" is
> renamed to "altp2m_check" and moved from p2m.c to altp2m.c for the x86
> architecuture. This change was perfomed in order to move altp2m related
> functions to one spot (which is altp2m.c). The reason for modifying the
> function's name is due the association of the function with the
> associated .c file.
> 
> Signed-off-by: Sergej Proskurin 

x86/p2m bits:

Acked-by: George Dunlap 

> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> ---
> v3: This commit has been moved out of the commit "arm/p2m: Add altp2m
> paging mechanism".
> 
> Moved the function "p2m_altp2m_check" from p2m.c to altp2m.c and
> renamed it to "altp2m_check". This change required the adoption of
> the complementary function in the x86 architecture.
> ---
>  xen/arch/arm/altp2m.c| 32 
>  xen/arch/x86/mm/altp2m.c |  6 ++
>  xen/arch/x86/mm/p2m.c|  6 --
>  xen/common/vm_event.c|  3 ++-
>  xen/include/asm-arm/altp2m.h |  7 ---
>  xen/include/asm-arm/p2m.h|  6 --
>  xen/include/asm-x86/altp2m.h |  3 +++
>  xen/include/asm-x86/p2m.h|  3 ---
>  8 files changed, 47 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
> index b10711e..11272e9 100644
> --- a/xen/arch/arm/altp2m.c
> +++ b/xen/arch/arm/altp2m.c
> @@ -32,6 +32,38 @@ struct p2m_domain *altp2m_get_altp2m(struct vcpu *v)
>  return v->domain->arch.altp2m_p2m[index];
>  }
>  
> +static bool_t altp2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int 
> idx)
> +{
> +struct domain *d = v->domain;
> +bool_t rc = false;
> +
> +if ( idx >= MAX_ALTP2M )
> +return rc;
> +
> +altp2m_lock(d);
> +
> +if ( d->arch.altp2m_p2m[idx] != NULL )
> +{
> +if ( idx != altp2m_vcpu(v).p2midx )
> +{
> +atomic_dec(_get_altp2m(v)->active_vcpus);
> +altp2m_vcpu(v).p2midx = idx;
> +atomic_inc(_get_altp2m(v)->active_vcpus);
> +}
> +rc = true;
> +}
> +
> +altp2m_unlock(d);
> +
> +return rc;
> +}
> +
> +void altp2m_check(struct vcpu *v, uint16_t idx)
> +{
> +if ( altp2m_active(v->domain) )
> +altp2m_switch_vcpu_altp2m_by_id(v, idx);
> +}
> +
>  int altp2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int idx)
>  {
>  struct vcpu *v;
> diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
> index 930bdc2..00abb5a 100644
> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -65,6 +65,12 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +void altp2m_check(struct vcpu *v, uint16_t idx)
> +{
> +if ( altp2m_active(v->domain) )
> +p2m_switch_vcpu_altp2m_by_id(v, idx);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 812dbf6..cb28cc2 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1646,12 +1646,6 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
>  }
>  }
>  
> -void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
> -{
> -if ( altp2m_active(v->domain) )
> -p2m_switch_vcpu_altp2m_by_id(v, idx);
> -}
> -
>  bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>  struct npfec npfec,
>  vm_event_request_t **req_ptr)
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 8398af7..e48d111 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* for public/io/ring.h macros */
>  #define xen_mb()   mb()
> @@ -423,7 +424,7 @@ void vm_event_resume(struct domain *d, struct 
> vm_event_domain *ved)
>  
>  /* Check for altp2m switch */
>  if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
> -p2m_altp2m_check(v, rsp.altp2m_idx);
> +altp2m_check(v, rsp.altp2m_idx);
>  
>  /* Check flags which apply only when the vCPU is paused */
>  if ( atomic_read(>vm_event_pause_count) )
> diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
> index 7f385d9..ef80829 100644
> --- a/xen/include/asm-arm/altp2m.h
> +++ b/xen/include/asm-arm/altp2m.h
> @@ -38,9 +38,7 @@ static inline bool_t altp2m_active(const struct domain *d)
>  

Re: [Xen-devel] [RFC PATCH] tools: remove blktap2 related code and documentation

[George Dunlap]

On 15/08/16 11:50, Wei Liu wrote:
> Blktap2 is effectively dead code for a few years.
> 
> Notable changes in this patch:
> 
> 0. Unhook blktap2 from build system
> 1. Now libxl no longer supports TAP ask backend, appropriate assertions
>are added and some code paths now return ERROR_FAIL
> 2. Tap is no longer a supported backend in doc
> 3. Remove relevant entries in MAINTAINERS
> 
> A patch to actually remove blktap2 directory will come later.
> 
> Signed-off-by: Wei Liu 

Oh right -- I'd actually forgotten that we've had the build disabled for
several releases now.

Acked-by: George Dunlap 

> ---
> Compile-test only at this stage.
> 
> Ross, do you have any objection for this? I haven't seen update from the
> joint blktap2 maintenance for a few months.
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Shriram Rajagopalan 
> Cc: Yang Hongyang 
> Cc: Ross Philipson 
> Cc: Lars Kurth 
> ---
>  .gitignore  | 14 --
>  INSTALL |  4 --
>  MAINTAINERS |  2 -
>  config/Tools.mk.in  |  1 -
>  docs/misc/xl-disk-configuration.txt |  2 +-
>  tools/Makefile  |  1 -
>  tools/Rules.mk  | 17 +--
>  tools/config.h.in   |  6 ---
>  tools/configure | 83 
>  tools/configure.ac  | 22 -
>  tools/libxl/Makefile|  8 +---
>  tools/libxl/check-xl-disk-parse |  2 +-
>  tools/libxl/libxl.c | 25 ++
>  tools/libxl/libxl_blktap2.c | 94 
> -
>  tools/libxl/libxl_device.c  | 32 ++---
>  tools/libxl/libxl_dm.c  | 17 ++-
>  tools/libxl/libxl_internal.h| 19 
>  tools/libxl/libxl_noblktap2.c   | 42 -
>  tools/xenstore/hashtable.c  |  5 --
>  tools/xenstore/hashtable.h  |  5 --
>  tools/xenstore/hashtable_private.h  |  5 --
>  21 files changed, 13 insertions(+), 393 deletions(-)
>  delete mode 100644 tools/libxl/libxl_blktap2.c
>  delete mode 100644 tools/libxl/libxl_noblktap2.c
> 
> diff --git a/.gitignore b/.gitignore
> index d193820..ea2 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -97,19 +97,6 @@ tools/libs/evtchn/headers.chk
>  tools/libs/gnttab/headers.chk
>  tools/libs/call/headers.chk
>  tools/libs/foreignmemory/headers.chk
> -tools/blktap2/daemon/blktapctrl
> -tools/blktap2/drivers/img2qcow
> -tools/blktap2/drivers/lock-util
> -tools/blktap2/drivers/qcow-create
> -tools/blktap2/drivers/qcow2raw
> -tools/blktap2/drivers/tapdisk
> -tools/blktap2/drivers/tapdisk-client
> -tools/blktap2/drivers/tapdisk-diff
> -tools/blktap2/drivers/tapdisk-stream
> -tools/blktap2/drivers/tapdisk2
> -tools/blktap2/drivers/td-util
> -tools/blktap2/vhd/vhd-update
> -tools/blktap2/vhd/vhd-util
>  tools/console/xenconsole
>  tools/console/xenconsoled
>  tools/console/client/_paths.h
> @@ -327,7 +314,6 @@ tools/libxl/*.pyc
>  tools/libxl/libxl-save-helper
>  tools/libxl/test_timedereg
>  tools/libxl/test_fdderegrace
> -tools/blktap2/control/tap-ctl
>  tools/firmware/etherboot/eb-roms.h
>  tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
>  tools/misc/xenwatchdogd
> diff --git a/INSTALL b/INSTALL
> index 9759354..3b255c7 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -144,10 +144,6 @@ this detection and the sysv runlevel scripts have to be 
> used.
>--with-systemd=DIR
>--with-systemd-modules-load=DIR
>  
> -The old backend drivers are disabled because qdisk is now the default.
> -This option can be used to build them anyway.
> -  --enable-blktap2
> -
>  Build various stubom components, some are only example code. Its usually
>  enough to specify just --enable-stubdom and leave these options alone.
>--enable-ioemu-stubdom
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97720a8..d54795b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -322,8 +322,6 @@ M:Shriram Rajagopalan 
>  M:   Yang Hongyang 
>  S:   Maintained
>  F:   docs/README.remus
> -F:   tools/blktap2/drivers/block-remus.c
> -F:   tools/blktap2/drivers/hashtable*
>  F:   tools/libxl/libxl_remus_*
>  F:   tools/libxl/libxl_netbuffer.c
>  F:   tools/libxl/libxl_nonetbuffer.c
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 0f79f4e..511406c 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -56,7 +56,6 @@ CONFIG_ROMBIOS  := @rombios@
>  CONFIG_SEABIOS  := @seabios@
>  CONFIG_QEMU_TRAD:= 

Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

[Daniel Kiper]

On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04,  wrote:
>
> Apart from the question of this probably better getting merged with
> the previous patch ...
>
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable)
> >
> >  __set_bit(EFI_BOOT, );
> >
> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
> > +__set_bit(EFI_RS, );
> > +#endif
>
> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
> was given (and then efi_rs_enable) should go away. Oh, looks
> like that's the next patch, but I'd then again question the split.

Do you suggest that patches 11-13 should be merged into one thing?
If it is OK for you I can do that.

> > --- a/xen/include/xen/efi.h
> > +++ b/xen/include/xen/efi.h
> > @@ -12,6 +12,7 @@
> >  struct efi {
> >  unsigned long flags;/* Bit fields representing available EFI 
> > features/properties */
> >  #define EFI_BOOT   0   /* Were we booted from EFI? */
> > +#define EFI_RS 2   /* Can we use runtime services? */
>
> Why is this not the sequentially next number?

I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).

Daniel

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

Re: [Xen-devel] [Design RFC] Towards work-conserving RTDS scheduler

[Dario Faggioli]

On Tue, 2016-08-09 at 09:57 -0400, Meng Xu wrote:
> On Mon, Aug 8, 2016 at 5:38 AM, Dario Faggioli
>  wrote:
> > 
> > I'm just thinking out loud and
> > wondering:
> >  - could it be useful to have a scheduling analysis in place for
> > the
> >    scheduler in work conserving mode (one, of course, that takes
> > into
> >    account and give guarantees on the otherwise idle bandwidth... I
> >    know that the existing one holds! :-P) ?
> >  - if yes, do you already have one --or do you think it will be
> >    possible to develop one-- for your priority-index based model?
> I think I could potentially develop one such analysis.
> 
Great. Let me know if you need any help writing the paper! :-P

> > Actually, it's quite likely that you either have already noticed
> > this
> > and done the analysis, or that someone else in literature has done
> > something similar --maybe with other schedulers-- before.
> Yes, I noticed this but I don't have analysis yet. ;-) I will do some
> math formulas to model this situation.
> I'm thinking the desired design will be
> 1) Work-conserving scheduler;
> 2) A *tight* schedulability analysis. If we cannot get tight
> analysis,
> we should reduce the abstraction overhead, i.e., num_cores -
> utilization of all VCPUs. (In order to achieve better analysis, we
> may
> need to change the scheduling policy a bit. I'm not very clear about
> how to do it yet, but I will think about it.)
> 
Err... I'm not sure I got what you exactly mean here, but this is your
field, just go ahead with it without bothering explaining everything to
me. :-)

> > Anyway, the idea itself looks fair enough to me. I'd like to hear,
> > if
> > that's fine with you, how you plan to actually implement it, as
> > there
> > of course are multiple different ways to do it, and there are, IMO,
> > a
> > couple of things that should be kept in mind.
> How about letting me think about the analysis first. If we can have
> both the work-conserving algorithm and the analysis, that will be
> better. If we finally decide not to have the analysis, we can fall
> back to the discussion of the current design?
> 
Sure.

> > Finally, about the work-conserving*ness on-off switch, what added
> > difficulty or increase in code complexity prevents us to, instead
> > of
> > this:
> > 
> > "2) Priority index: It indicates the current  priority level of the
> > VCPU. When a VCPU’s budget is depleted in the current period,
> > its
> > priority index will increase by 1 and its budget will be
> > replenished."
> > 
> > do something like this:
> > 
> > "2) Priority index: It indicates the current  priority level of the
> > VCPU. When a VCPU's budget is depleted in the current period:
> >  2a) if the VCPU has the work conserving flag set, its priority
> >  index will be increased by 1, and its budget replenished;
> >  2b) if the VCPU has the work conserving flag cleat, it's
> > blocked
> >  until next period."
> > 
> > ?
> Agree. We can have the per-VCPU working-conserving flag.
> 
Glad you see it useful/doable too.

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



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

Re: [Xen-devel] [MINIOS PATCH 0/3] x86: use ELF notes and unified linker script

[Andrew Cooper]

On 18/08/16 11:15, Wei Liu wrote:
> Wei Liu (3):
>   Introduce asm_macros.h
>   x86: switch to use elfnote
>   x86: use unified linker script

All three Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] xen: Move the hvm_start_info C representation to the public headers

[Wei Liu]

On Thu, Aug 18, 2016 at 12:04:30PM +0200, Juergen Gross wrote:
> Instead of having several representation of hvm_start_info in C, define
> it in public/arch-x86/hvm/start_info.h so both libxc and hvmloader can
> use it.
> 
> Also move the comment describing the binary format to be alongside the
> C struct.
> 
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Andrew Cooper 

On the original patch:

Acked-by: Jan Beulich 

Acked-by: Wei Liu 
> +/*
> + * C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout is abrove, this is just a way to

above

> + * represent the layout described there using C types.
> + *

I will delete this line while committing

(Both changes are required by Jan)

Wei.

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

Re: [Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c

[Daniel Kiper]

On Wed, Aug 17, 2016 at 09:56:39AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04,  wrote:
> > A subsequent patch adds efi struct flags member which is used
> > during runtime to differentiate between legacy BIOS and EFI
> > platforms and multiboot2 and EFI native loader. So, efi symbol
> > have to proper representation in ELF and PE Xen image. Hence,
> > move efi struct initialization to xen/common/lib.c and remove
> > efi symbol from ld script.
> >
> > Signed-off-by: Daniel Kiper 
> > ---
> > v4 - suggestions/fixes:
> >- move efi struct initialization to xen/common/lib.c
> >  and drop one from xen/arch/x86/efi/stub.c
> >  (suggested by Jan Beulich),
>
> I recall I didn't like where you placed it last time round. I've just tried
> to locate the old thread, but going back a whole year in the list archives
> I was not able to find a mail with the title containing "move efi". Hence I

Here it is (I list just first email from thread in a given month):
  https://lists.xen.org/archives/html/xen-devel/2016-04/msg02186.html
  https://lists.xen.org/archives/html/xen-devel/2016-05/msg02659.html
  https://lists.xen.org/archives/html/xen-devel/2016-06/msg00124.html
  https://lists.xen.org/archives/html/xen-devel/2016-07/msg00530.html

> can only say what I think now, without reference to earlier remarks:
> The struct currently isn't overly large, but I still don't see why non-EFI
> builds need to include it instead of just the flags variable you mean to
> introduce subsequently. And it's even less obvious what use it is on
> platforms not even supporting EFI, i.e. ARM32.

I see two solutions for this issue:
  - define efi struct members conditionally; this requires also
some #ifs sprinkled over Xen code (not very nice) or other
substantial changes,
  - replace efi.flags with efi_flags and leave existing code as is.

What is your choice?

Personally I prefer existing patch (maybe with minimal changes
suggested by you).

Daniel

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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Andrew Cooper]

On 18/08/16 11:06, Jan Beulich wrote:
 On 17.08.16 at 22:32,  wrote:
>> One of the interesting things about XSA 154 fix ("x86: enforce consistent
>> cachability of MMIO mappings") is that when certain applications (mcelog)
>> are trying to map /dev/mmap and lurk in ISA regions - we get:
> DYM /dev/mem ? Most accesses to which are bogus in PV guests
> (often including Dom0) anyway.
>
>> [   49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 
>> untrack_pfn+0x93/0xc0()
> What Linux version is this? untrack_pfn() doesn't span line 913 in
> 4.8-rc2. And follow_phys() appears to only check whether the write
> flag is set as expected; I can't see any cachability checks. Plus it
> gets called only when both incoming address and size are zero.
>
>> Anyhow what I am wondering:
>>
>>  a) Should we add a edge case in the hypervisor to allow multiple mappings
>>for this region? I am thinking no.. but it sounds like mapping ISA region
>>as WB is safe even in baremetal?
> We should never allow multiple mappings with different cachability.
> And I don't understand what makes you think the ISA region is safe
> to map WB? There might be ROMs, MMIO regions, or simply nothing
> there, neither of which is safe to map WB. ROMs certainly could be
> WP, but that would require a way to reliably size not only ISA
> extension ROMs, but also main and video BIOS.
>
>>  b) Or would it be better to let Linux do its thing and treat 640KB->1MB
>>as uncached instead of writeback?
> According to what you wrote earlier the two parts of the sentence
> read contradictory to me.
>
>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>>The comment says:
>>" /* Low ISA region is always mapped WB in page table. No need to track *"
> As per above it's not clear to me what this comment is backed by.

This states what is in the pagetables.  Not the combined result with MTRRs.

WB in the pagetables and WC/UB in the MTRRs is a legal combination which
functions correctly.

~Andrew

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

[Xen-devel] [MINIOS PATCH 1/3] Introduce asm_macros.h

[Wei Liu]

Ported from Xen Test Framework project (BSD license).

Signed-off-by: Wei Liu 
---
v2: Provide a stub for ARM
---
 include/arm/asm_macros.h | 14 ++
 include/asm_macros.h | 40 
 include/x86/asm_macros.h | 28 
 3 files changed, 82 insertions(+)
 create mode 100644 include/arm/asm_macros.h
 create mode 100644 include/asm_macros.h
 create mode 100644 include/x86/asm_macros.h

diff --git a/include/arm/asm_macros.h b/include/arm/asm_macros.h
new file mode 100644
index 000..8b8dafe
--- /dev/null
+++ b/include/arm/asm_macros.h
@@ -0,0 +1,14 @@
+#ifndef _ARM_ASM_MACRO_H_
+#define _ARM_ASM_MACRO_H_
+
+#endif /* _ARM_ASM_MACRO_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/asm_macros.h b/include/asm_macros.h
new file mode 100644
index 000..0e34090
--- /dev/null
+++ b/include/asm_macros.h
@@ -0,0 +1,40 @@
+/*
+ * Macros for assembly files.
+ */
+
+#ifndef _ASM_MACRO_H_
+#define _ASM_MACRO_H_
+
+#if defined(__i386__) || defined(__x86_64__)
+#include 
+#elif defined(__arm__) || defined(__aarch64__)
+#include 
+#endif
+
+#ifdef __ASSEMBLY__
+
+#define ELFNOTE(name, type, desc)   \
+.pushsection .note.name   ; \
+.align 4  ; \
+.long 2f - 1f   /* namesz */  ; \
+.long 4f - 3f   /* descsz */  ; \
+.long type  /* type   */  ; \
+1:.asciz #name  /* name   */  ; \
+2:.align 4; \
+3:desc  /* desc   */  ; \
+4:.align 4; \
+.popsection
+
+#endif  /* __ASSEMBLY__ */
+
+#endif  /* _ASM_MACRO_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/x86/asm_macros.h b/include/x86/asm_macros.h
new file mode 100644
index 000..e718e0b
--- /dev/null
+++ b/include/x86/asm_macros.h
@@ -0,0 +1,28 @@
+#ifndef _X86_ASM_MACRO_H_
+#define _X86_ASM_MACRO_H_
+
+#ifdef  __ASSEMBLY__
+# if defined(__x86_64__)
+#  define _WORD .quad
+# elif defined(__i386__)
+#  define _WORD .long
+# endif
+#else
+# if defined(__x86_64__)
+#  define _WORD ".quad"
+# elif defined(__i386__)
+#  define _WORD ".long"
+# endif
+#endif
+
+#endif /* _X86_ASM_MACRO_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.1.4


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

[Xen-devel] [MINIOS PATCH 0/3] x86: use ELF notes and unified linker script

[Wei Liu]

Wei Liu (3):
  Introduce asm_macros.h
  x86: switch to use elfnote
  x86: use unified linker script

 .gitignore |   1 +
 Makefile   |   6 +-
 arch/x86/Makefile  |   1 +
 arch/x86/minios-x86.lds.S  | 133 +
 arch/x86/minios-x86_32.lds |  74 -
 arch/x86/minios-x86_64.lds |  74 -
 arch/x86/x86_32.S  |  17 +++---
 arch/x86/x86_64.S  |  15 ++---
 include/arm/asm_macros.h   |  14 +
 include/asm_macros.h   |  40 ++
 include/x86/asm_macros.h   |  28 ++
 11 files changed, 235 insertions(+), 168 deletions(-)
 create mode 100644 arch/x86/minios-x86.lds.S
 delete mode 100644 arch/x86/minios-x86_32.lds
 delete mode 100644 arch/x86/minios-x86_64.lds
 create mode 100644 include/arm/asm_macros.h
 create mode 100644 include/asm_macros.h
 create mode 100644 include/x86/asm_macros.h

-- 
2.1.4


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

[Xen-devel] [MINIOS PATCH 3/3] x86: use unified linker script

[Wei Liu]

There are only a few differences between i386 and x86-64 linker scripts.
Unify them into one. Re-indent the file at the same time.

Construct a special rule in top-level directory to cope with the change.
Ideally the build system should also be made more elegant, but
overhauling the build system is out of scope of this patch.

Signed-off-by: Wei Liu 
---
v2:
1. fix one typo in code
2. use single-parameter form of OUTPUT_FORMAT
---
 .gitignore |   1 +
 Makefile   |   6 +-
 arch/x86/Makefile  |   1 +
 arch/x86/minios-x86.lds.S  | 133 +
 arch/x86/minios-x86_32.lds |  78 --
 arch/x86/minios-x86_64.lds |  78 --
 6 files changed, 140 insertions(+), 157 deletions(-)
 create mode 100644 arch/x86/minios-x86.lds.S
 delete mode 100644 arch/x86/minios-x86_32.lds
 delete mode 100644 arch/x86/minios-x86_64.lds

diff --git a/.gitignore b/.gitignore
index f21cc46..efc193c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
 *.o
 *.a
 *.swp
+arch/x86/minios-x86*.lds
 include/list.h
 mini-os
 mini-os.gz
diff --git a/Makefile b/Makefile
index 5464e89..779bc91 100644
--- a/Makefile
+++ b/Makefile
@@ -148,7 +148,11 @@ ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
 endif
 
-$(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib
+# Special rule for x86 for now
+arch/x86/minios-x86%.lds:  arch/x86/minios-x86.lds.S
+   $(CPP) $(ASFLAGS) -P $< -o $@
+
+$(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib 
$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds
$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) 
-o $@.o
$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 0052b4c..dbe9ca6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -24,4 +24,5 @@ $(OBJ_DIR)/$(ARCH_LIB): $(ARCH_OBJS) 
$(OBJ_DIR)/$(HEAD_ARCH_OBJ)
 
 clean:
rm -f $(OBJ_DIR)/$(ARCH_LIB) $(ARCH_OBJS) $(OBJ_DIR)/$(HEAD_ARCH_OBJ)
+   rm -f minios-x86_32.lds minios-x86_64.lds
 
diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S
new file mode 100644
index 000..8aae2fd
--- /dev/null
+++ b/arch/x86/minios-x86.lds.S
@@ -0,0 +1,133 @@
+#if defined(__x86_64__)
+
+OUTPUT_FORMAT("elf64-x86-64")
+OUTPUT_ARCH(i386:x86-64)
+
+#elif defined(__i386__)
+#undef i386
+OUTPUT_FORMAT("elf32-i386")
+OUTPUT_ARCH(i386)
+
+#else
+# error Bad architecture to link with
+#endif
+
+ENTRY(_start)
+SECTIONS
+{
+. = 0x0;
+_text = .; /* Text and read-only data */
+.text : {
+*(.text)
+*(.gnu.warning)
+} = 0x9090
+
+_etext = .;/* End of text section */
+
+.rodata : {
+*(.rodata)
+*(.rodata.*)
+}
+. = ALIGN(4096);
+_erodata = .;
+
+.note : {
+*(.note)
+*(.note.*)
+}
+
+/* newlib initialization functions */
+#if defined(__x86_64__)
+. = ALIGN(64 / 8);
+#else /* __i386 __ */
+. = ALIGN(32 / 8);
+#endif
+PROVIDE (__preinit_array_start = .);
+.preinit_array : {
+*(.preinit_array)
+}
+PROVIDE (__preinit_array_end = .);
+PROVIDE (__init_array_start = .);
+.init_array : {
+*(.init_array)
+}
+PROVIDE (__init_array_end = .);
+PROVIDE (__fini_array_start = .);
+.fini_array : {
+*(.fini_array)
+}
+PROVIDE (__fini_array_end = .);
+
+.ctors : {
+__CTOR_LIST__ = .;
+*(.ctors)
+CONSTRUCTORS
+#if defined(__x86_64__)
+QUAD(0)
+#else /* __i386__ */
+LONG(0)
+#endif
+__CTOR_END__ = .;
+}
+
+.dtors : {
+__DTOR_LIST__ = .;
+*(.dtors)
+#if defined(__x86_64__)
+QUAD(0)
+#else /* __i386__ */
+LONG(0)
+#endif
+__DTOR_END__ = .;
+}
+
+.data : {  /* Data */
+*(.data)
+}
+
+_edata = .;/* End of data section */
+
+__bss_start = .;   /* BSS */
+.bss : {
+*(.bss)
+*(.app.bss)
+}
+_end = . ;
+
+/* Sections to be discarded */
+/DISCARD/ : {
+*(.text.exit)
+*(.data.exit)
+*(.exitcall.exit)
+}
+
+/* Stabs debugging sections.  */
+.stab 0 : {
+*(.stab)
+}
+.stabstr 0 : {
+*(.stabstr)
+}
+.stab.excl 0 : {
+*(.stab.excl)
+}
+.stab.exclstr 0 : {
+

[Xen-devel] [MINIOS PATCH 2/3] x86: switch to use elfnote

[Wei Liu]

Use the newer ELF note interface. The generated ELF notes results in
equivalent configuration.

Also need to modify linker script to provide a note section.

Signed-off-by: Wei Liu 
Reviewed-by: Juergen Gross 
---
 arch/x86/minios-x86_32.lds |  4 
 arch/x86/minios-x86_64.lds |  4 
 arch/x86/x86_32.S  | 17 +++--
 arch/x86/x86_64.S  | 15 ++-
 4 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/arch/x86/minios-x86_32.lds b/arch/x86/minios-x86_32.lds
index f5cabb6..e4e18cb 100644
--- a/arch/x86/minios-x86_32.lds
+++ b/arch/x86/minios-x86_32.lds
@@ -15,6 +15,10 @@ SECTIONS
   .rodata : { *(.rodata) *(.rodata.*) }
   . = ALIGN(4096);
   _erodata = .;
+  .note : {
+   *(.note)
+   *(.note.*)
+  }
 
   /* newlib initialization functions */
   . = ALIGN(32 / 8);
diff --git a/arch/x86/minios-x86_64.lds b/arch/x86/minios-x86_64.lds
index 3da0a9f..f6462f3 100644
--- a/arch/x86/minios-x86_64.lds
+++ b/arch/x86/minios-x86_64.lds
@@ -15,6 +15,10 @@ SECTIONS
   .rodata : { *(.rodata) *(.rodata.*) }
   . = ALIGN(4096);
   _erodata = .;
+  .note : {
+   *(.note)
+   *(.note.*)
+  }
 
   /* newlib initialization functions */
   . = ALIGN(64 / 8);
diff --git a/arch/x86/x86_32.S b/arch/x86/x86_32.S
index b9aa392..6dc985a 100644
--- a/arch/x86/x86_32.S
+++ b/arch/x86/x86_32.S
@@ -1,17 +1,14 @@
 #include 
 #include 
+#include 
+#include 
 #include 
 
-.section __xen_guest
-   .ascii  "GUEST_OS=Mini-OS"
-   .ascii  ",XEN_VER=xen-3.0"
-   .ascii  ",VIRT_BASE=0x0" /* &_text from minios_x86_32.lds */
-   .ascii  ",ELF_PADDR_OFFSET=0x0"
-   .ascii  ",HYPERCALL_PAGE=0x2"
-   .ascii  ",PAE=yes[extended-cr3]"
-   .ascii  ",LOADER=generic"
-   .byte   0
-.text
+ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz "Mini-OS")
+ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
+ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _WORD hypercall_page)
+ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION, .asciz "xen-3.0")
+ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes")
 
 .globl _start, shared_info, hypercall_page
 
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 72921b1..8ed452f 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -1,16 +1,13 @@
 #include 
 #include 
+#include 
+#include 
 #include 
 
-.section __xen_guest
-   .ascii  "GUEST_OS=Mini-OS"
-   .ascii  ",XEN_VER=xen-3.0"
-   .ascii  ",VIRT_BASE=0x0" /* &_text from minios_x86_64.lds */
-   .ascii  ",ELF_PADDR_OFFSET=0x0"
-   .ascii  ",HYPERCALL_PAGE=0x2"
-   .ascii  ",LOADER=generic"
-   .byte   0
-.text
+ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz "Mini-OS")
+ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
+ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _WORD hypercall_page)
+ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION, .asciz "xen-3.0")
 
 #define ENTRY(X) .globl X ; X :
 .globl _start, shared_info, hypercall_page
-- 
2.1.4


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

Re: [Xen-devel] [MINIOS PATCH 1/4] gitignore: ignore vim swap file

[Wei Liu]

On Wed, Aug 17, 2016 at 02:51:21PM +0200, Samuel Thibault wrote:
> Wei Liu, on Wed 17 Aug 2016 13:35:11 +0100, wrote:
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Samuel Thibault 
> 

Pushed this patch to reduce path queue length.

Wei.

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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Jan Beulich]

>>> On 17.08.16 at 22:32,  wrote:
> One of the interesting things about XSA 154 fix ("x86: enforce consistent
> cachability of MMIO mappings") is that when certain applications (mcelog)
> are trying to map /dev/mmap and lurk in ISA regions - we get:

DYM /dev/mem ? Most accesses to which are bogus in PV guests
(often including Dom0) anyway.

> [   49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 
> untrack_pfn+0x93/0xc0()

What Linux version is this? untrack_pfn() doesn't span line 913 in
4.8-rc2. And follow_phys() appears to only check whether the write
flag is set as expected; I can't see any cachability checks. Plus it
gets called only when both incoming address and size are zero.

> Anyhow what I am wondering:
> 
>  a) Should we add a edge case in the hypervisor to allow multiple mappings
>for this region? I am thinking no.. but it sounds like mapping ISA region
>as WB is safe even in baremetal?

We should never allow multiple mappings with different cachability.
And I don't understand what makes you think the ISA region is safe
to map WB? There might be ROMs, MMIO regions, or simply nothing
there, neither of which is safe to map WB. ROMs certainly could be
WP, but that would require a way to reliably size not only ISA
extension ROMs, but also main and video BIOS.

>  b) Or would it be better to let Linux do its thing and treat 640KB->1MB
>as uncached instead of writeback?

According to what you wrote earlier the two parts of the sentence
read contradictory to me.

>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>The comment says:
>" /* Low ISA region is always mapped WB in page table. No need to track *"

As per above it's not clear to me what this comment is backed by.

Jan


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

[Xen-devel] [PATCH] xen: Move the hvm_start_info C representation to the public headers

[Juergen Gross]

Instead of having several representation of hvm_start_info in C, define
it in public/arch-x86/hvm/start_info.h so both libxc and hvmloader can
use it.

Also move the comment describing the binary format to be alongside the
C struct.

Signed-off-by: Anthony PERARD 
Reviewed-by: Andrew Cooper 
---
This is a resend of Anthony's patch "[PATCH v7 06/15] xen: Move the
hvm_start_info C representation to the public headers" in order to make
the structure usable for mini-os.
---
 tools/libxc/include/xc_dom.h | 31 -
 tools/libxc/xc_dom_x86.c |  1 +
 xen/include/public/arch-x86/hvm/start_info.h | 99 
 xen/include/public/xen.h | 46 -
 4 files changed, 100 insertions(+), 77 deletions(-)
 create mode 100644 xen/include/public/arch-x86/hvm/start_info.h

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..cac4698 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -216,37 +216,6 @@ struct xc_dom_image {
 struct xc_hvm_firmware_module smbios_module;
 };
 
-#if defined(__i386__) || defined(__x86_64__)
-/* C representation of the x86/HVM start info layout.
- *
- * The canonical definition of this layout resides in public/xen.h, this
- * is just a way to represent the layout described there using C types.
- *
- * NB: the packed attribute is not really needed, but it helps us enforce
- * the fact this this is just a representation, and it might indeed
- * be required in the future if there are alignment changes.
- */
-struct hvm_start_info {
-uint32_t magic; /* Contains the magic value 0x336ec578   */
-/* ("xEn3" with the 0x80 bit of the "E" set).*/
-uint32_t version;   /* Version of this structure.*/
-uint32_t flags; /* SIF_xxx flags.*/
-uint32_t nr_modules;/* Number of modules passed to the kernel.   */
-uint64_t modlist_paddr; /* Physical address of an array of   */
-/* hvm_modlist_entry.*/
-uint64_t cmdline_paddr; /* Physical address of the command line. */
-uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
-/* structure.*/
-} __attribute__((packed));
-
-struct hvm_modlist_entry {
-uint64_t paddr; /* Physical address of the module.   */
-uint64_t size;  /* Size of the module in bytes.  */
-uint64_t cmdline_paddr; /* Physical address of the command line. */
-uint64_t reserved;
-} __attribute__((packed));
-#endif /* x86 */
-
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 021f8a8..d9747b4 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "xg_private.h"
diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
new file mode 100644
index 000..002e3b7
--- /dev/null
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -0,0 +1,99 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value 

[Xen-devel] [PATCH v2 2/2] xen: credit1: no need to check for is_idle_vcpu() in csched_vcpu_acct()

[Dario Faggioli]

In fact, csched_vcpu_acct() is called by csched_tick()
_only_ on non idle vcpus already.

There's even an ASSERT() already in place at the top
of it which, by checking that svc->sdom is not NULL,
guarantees that the function is not being called on
the idle domain.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 xen/common/sched_credit.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index daace81..71a8b1d 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -966,11 +966,8 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int 
cpu)
  svc->vcpu->vcpu_id);
 }
 
-/*
- * Update credits
- */
-if ( !is_idle_vcpu(svc->vcpu) )
-burn_credits(svc, NOW());
+/* Update credits. */
+burn_credits(svc, NOW());
 
 /*
  * Put this VCPU and domain back on the active list if it was


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

[Xen-devel] [PATCH v2 1/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

In the Credit1 hunk of 9f358ddd69463 ("xen: Have
schedulers revise initial placement") csched_cpu_pick()
is called without taking the runqueue lock of the
(temporary) pCPU that the vCPU has been assigned to
(e.g., in XEN_DOMCTL_max_vcpus).

However, although 'hidden' in the IS_RUNQ_IDLE() macro,
that function does access the runq (for doing load
balancing calculations). Two scenarios are possible:
 1) we are on cpu X, and IS_RUNQ_IDLE() peeks at cpu's
X own runq;
 2) we are on cpu X, but IS_RUNQ_IDLE() peeks at some
other cpu's runq.

Scenario 2) absolutely requies that the appropriate
runq lock is taken. Scenario 1) works even without
taking the cpu's own runq lock, and this is important
for the case when _csched_pick_cpu() is called from
csched_vcpu_acct() which in turn is called by
csched_tick().

Races have been observed and reported (by both XenServer
own testing and OSSTest [1]), in the form of
IS_RUNQ_IDLE() falling over LIST_POISON, because we're
not currently holding the proper lock, in
csched_vcpu_insert(), when scenario 1) occurs.

Since this is all very tricky, in addition to fix things,
add both an ASSERT() and a comment in IS_RUNQ_IDLE() (which
is also becoming static inline instead of macro).

[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02144.html

Reported-by: Andrew Cooper 
Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
Changes from v1:
 - macro IS_RUNQ_IDLE() to static inline is_runq_idle(), as suggested
   during review;
 - add an ASSERT() and a comment, as suggested during review;
 - take into account what's described in the changelog as "scenario 1)",
   which wasn't being considered in v1.
---
 xen/common/sched_credit.c |   38 +-
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 220ff0d..daace81 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -84,9 +84,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)  (&(CSCHED_PCPU(_cpu)->runq))
-/* Is the first element of _cpu's runq its idle vcpu? */
-#define IS_RUNQ_IDLE(_cpu)  (list_empty(RUNQ(_cpu)) || \
- is_idle_vcpu(__runq_elem(RUNQ(_cpu)->next)->vcpu))
 
 
 /*
@@ -248,6 +245,33 @@ __runq_elem(struct list_head *elem)
 return list_entry(elem, struct csched_vcpu, runq_elem);
 }
 
+/* Is the first element of cpu's runq (if any) cpu's idle vcpu? */
+static inline bool_t is_runq_idle(unsigned int cpu)
+{
+/*
+ * If we are on cpu, and we are peeking at our own runq while cpu itself
+ * is not idle, that's fine even if we don't hold the runq lock. In fact,
+ * the fact that there is a (non idle!) vcpu running means that at least
+ * the idle vcpu is in the runq. And since only cpu itself (via work
+ * stealing) can add stuff to the runq, and no other cpu will ever steal
+ * our idle vcpu, that maks the runq manipulations done below safe, even
+ * without locks.
+ *
+ * On the other hand, if we're peeking at another cpu's runq, we must hold
+ * its the proper runq lock.
+ *
+ * As a matter of fact, the former scenario describes what happens when
+ * _cshced_cpu_pick() (which then calls us) is called from csched_tick(),
+ * the latter one describes what actually happen when it is called from
+ * csched_vcpu_insert().
+ */
+ASSERT((!is_idle_vcpu(curr_on_cpu(cpu)) && cpu == smp_processor_id()) ||
+   spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
+
+return list_empty(RUNQ(cpu)) ||
+   is_idle_vcpu(__runq_elem(RUNQ(cpu)->next)->vcpu);
+}
+
 static inline void
 __runq_insert(struct csched_vcpu *svc)
 {
@@ -771,7 +795,7 @@ _csched_cpu_pick(const struct scheduler *ops, struct vcpu 
*vc, bool_t commit)
  * runnable vcpu on cpu, we add cpu to the idlers.
  */
 cpumask_and(, _online_map, CSCHED_PRIV(ops)->idlers);
-if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
+if ( vc->processor == cpu && is_runq_idle(cpu) )
 __cpumask_set_cpu(cpu, );
 cpumask_and(, , );
 
@@ -998,9 +1022,13 @@ csched_vcpu_insert(const struct scheduler *ops, struct 
vcpu *vc)
 
 BUG_ON( is_idle_vcpu(vc) );
 
-/* This is safe because vc isn't yet being scheduled */
+/* csched_cpu_pick() looks in vc->processor's runq, so we need the lock. */
+lock = vcpu_schedule_lock_irq(vc);
+
 vc->processor = csched_cpu_pick(ops, vc);
 
+spin_unlock_irq(lock);
+
 lock = vcpu_schedule_lock_irq(vc);
 
 if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )


___

[Xen-devel] [PATCH v2 0/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

Hey,

This is v2 of this
https://lists.xen.org/archives/html/xen-devel/2016-08/msg01679.html although it
became a small series, as I noticed in the process room for a small improvement
to the code and added a patch for that (that's patch 2).

Also, while adding the ASSERT() George asked for here
https://lists.xen.org/archives/html/xen-devel/2016-08/msg01694.html , I
discovered that things where a bit worse than they looked at the beginning
(I described such finding here:
https://lists.xen.org/archives/html/xen-devel/2016-08/msg01752.html).

Patch 1 of this series is my idea of a fix for the reported issue, that does
not explode in any other way and is also respectful of the code of
csched_tick(). In fact, while the most obvious) solution would be to just
always take the appropriate lock, doing that in csched_tick() is particularly
tricky (because of Credit1's lock nesting rule), and would result in a dance of
taking and releasing locks which I don't think is what we want.

I've tested this by repeatedly creating and destroying a VM, on both an idle
and a loaded system, as that seems to be what makes the system crash in both
Andrew's XenServer testing, and OSSTest flight 100518 (it's failing at the
guest-start/win.repeat step).

If people (George, mainly, I guess) agree this is the proper fix, I think this
(I mean, patch 1) needs to be backported to all the branches to which we
backported 9f358ddd69463 ("xen: Have schedulers revise initial placement").

Regards,
Dario
---
Dario Faggioli (2):
  xen: credit1: fix a race when picking initial pCPU for a vCPU
  xen: credit1: no need to check for is_idle_vcpu() in csched_vcpu_acct()

 xen/common/sched_credit.c |   45 +++--
 1 file changed, 35 insertions(+), 10 deletions(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH] tools/xenalyze: append argp LD flags if needed

[Wei Liu]

On Thu, Aug 18, 2016 at 11:10:44AM +0200, Roger Pau Monne wrote:
> This is a side-effect of commit c36e1c, which currently prevents compiling
> xenalyze with libcs that don't have argp built-in.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

> ---
> Cc: George Dunlap 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> ---
>  tools/xentrace/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
> index a85ed33..c8c36a8 100644
> --- a/tools/xentrace/Makefile
> +++ b/tools/xentrace/Makefile
> @@ -50,7 +50,7 @@ xentrace_setsize: setsize.o
>   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) $(APPEND_LDFLAGS)
>  
>  xenalyze: xenalyze.o mread.o
> - $(CC) $(LDFLAGS) -o $@ $^ $(APPEND_LDFLAGS)
> + $(CC) $(LDFLAGS) -o $@ $^ $(ARGP_LDFLAGS) $(APPEND_LDFLAGS)
>  
>  -include $(DEPS)
>  
> -- 
> 2.7.4 (Apple Git-66)
> 

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

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 18.08.16 at 11:23,  wrote:
> On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
>> >>> On 06.08.16 at 01:04,  wrote:
> 
> [...]
> 
>> > +case MULTIBOOT2_TAG_TYPE_MMAP:
>> > +mbi_out->flags |= MBI_MEMMAP;
>> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
>> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
>> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
>>
>> Okay, here you use the entry size as provided by grub, allowing
>> compatibility even when the boot loader uses a newer layout (with
>> extra fields added to the end). However ...
>>
>> > +mbi_out->mmap_length *= sizeof(memory_map_t);
>> > +
>> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
>> > +
>> > +mmap_src = get_mb2_data(tag, mmap, entries);
>> > +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
>> > +
>> > +for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); 
>> > i++ 
> )
>> > +{
>> > +/* Init size member properly. */
>> > +mmap_dst[i].size = sizeof(memory_map_t);
>> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
>> > +/* Now copy a given region data. */
>> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
>> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 
>> > 32);
>> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
>> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
>>
>> ... here you index an array of type multiboot2_memory_map_t.
> 
> All calculations looks correct, so, I am not sure what is wrong here.
> 
>> Also note that in any event you should check that
>> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
>> to go with the flexible model, ==).
> 
> This make sense to some extent. However, I am not sure what we should do
> if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
> model). Just do not fill memory map? Probably yes...

Perhaps you misunderstood my comment?
entry_size < sizeof(*mmap_src) is a case we simply can't deal with,
so you should (as you say) not obtain the memory map, which I
assume is equivalent to not failing the boot altogether. The point
of interest really is entry_size > sizeof(*mmap_src), and that's
what mmap_src[i] above doesn't handle correctly.

Jan


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

Re: [Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

[Dario Faggioli]

On Wed, 2016-08-17 at 20:57 -0400, Meng Xu wrote:
> On Wed, Aug 17, 2016 at 1:18 PM, Dario Faggioli
>  wrote:
> > 
> > diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> > index 41c61a7..903dbd8 100644
> > --- a/xen/common/sched_rt.c
> > +++ b/xen/common/sched_rt.c
> > 
> > @@ -1035,6 +1036,20 @@ rt_schedule(const struct scheduler *ops,
> > s_time_t now, bool_t tasklet_work_sched
> >  struct rt_vcpu *snext = NULL;
> >  struct task_slice ret = { .migrated = 0 };
> > 
> > +/* TRACE */
> > +{
> > +struct __packed {
> > +unsigned cpu:17, tasklet:8, tickled:4, idle:4;
> > +} d;
> > +d.cpu = cpu;
> > +d.tasklet = tasklet_work_scheduled;
> > +d.tickled = cpumask_test_cpu(cpu, >tickled);
> > +d.idle = is_idle_vcpu(current);
> > +__trace_var(TRC_RTDS_SCHEDULE, 1,
> > +sizeof(d),
> > +(unsigned char *));
> > +}
>

> 1) IMHO, the trace should be wrapped by the if (
> unlikely(tb_init_done) ) {} statement as done in sched_credit2.c.
> Otherwise, we always enable the tracing which may hurt the
> performance, I think.
> 
You're right. Actually, in order to follow suite from sched_rt.c, I
think using trace_var() instead of __trace_var() is what we want.

Then, I think it will be a good thing, at some point, to convert all
these /*TRACE*/ blocks to extrapolate the tb_init_done check and make
it guard the trace record marshalling, like I did a few patches ago for
Credit2 but that's another patch.

This is a cut-&-paste mistake, good job noticing it. :-)

> 2) Why does the cpu field here use 17 bits instead of 16 bits as used
> in credit2?
> This may be a typo I guess (since you are trying to align the
> structure to 32 bits I guess ;-) )?
>
Wow... 17.. I must have been drunk when writing that! :-O

> In addition, I'm wondering if uint16 is better than unsigned? I'm not
> that confident if unsigned type will always have 16 bits on all types
> of machines?
> 
Yeah, well, TBH, all this bitfields and packing, etc., is something I
truly hate. But I think in this case unsigned is fine.

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



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

Re: [Xen-devel] [PATCH] tools/xenalyze: append argp LD flags if needed

[George Dunlap]

On 18/08/16 10:10, Roger Pau Monne wrote:
> This is a side-effect of commit c36e1c, which currently prevents compiling
> xenalyze with libcs that don't have argp built-in.
> 
> Signed-off-by: Roger Pau Monné 

I don't have the expertise to know if this is the Right Way to solve
this problem; but regarding the principle:

Acked-by: George Dunlap 

> ---
> Cc: George Dunlap 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> ---
>  tools/xentrace/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
> index a85ed33..c8c36a8 100644
> --- a/tools/xentrace/Makefile
> +++ b/tools/xentrace/Makefile
> @@ -50,7 +50,7 @@ xentrace_setsize: setsize.o
>   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) $(APPEND_LDFLAGS)
>  
>  xenalyze: xenalyze.o mread.o
> - $(CC) $(LDFLAGS) -o $@ $^ $(APPEND_LDFLAGS)
> + $(CC) $(LDFLAGS) -o $@ $^ $(ARGP_LDFLAGS) $(APPEND_LDFLAGS)
>  
>  -include $(DEPS)
>  
> 


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

Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions

[Jan Beulich]

>>> On 18.08.16 at 10:53,  wrote:
> On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote:
>> >>> On 11.08.16 at 16:12,  wrote:
>>  On 06.08.16 at 01:04,  wrote:
>> >> --- a/xen/arch/x86/boot/reloc.c
>> >> +++ b/xen/arch/x86/boot/reloc.c
>> >> @@ -32,60 +32,69 @@ typedef unsigned int u32;
>> >>
>> >>  static u32 alloc;
>> >>
>> >> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
>> >> +static u32 alloc_mem(u32 bytes)
>> >
>> > Conversion of alloc to be of pointer type (in the earlier patch), and
>> > then making the return type here and ...
>> >
>> >> +static u32 copy_mem(u32 src, u32 bytes)
>> >
>> > ... all of the types here follow suit would apparently be quite
>> > beneficial to the number of casts needed.
>>
>> Or maybe, considering patch 8, in a slight variation thereof: Do
>> the conversion as suggested, but have a helper wrapper of the
>> type above, taking care of all the casting. That way both the
>> actual implementation and the callers can stay (mostly) cast free.
> 
> We should take into account patch 9 here too. Looking at code after
> it I think that right now it is very well optimized in terms of casts.
> I cannot see room for further improvement. Every change you proposed
> here and there does not improve final code. It justs move/change casts
> to/in different places. So, I think that it does not pay change casts
> here and in earlier patches. At least in the way you proposed until now.

What I've suggested above at least makes both the actual function
and its wrapper consistent, and hence usable (without casts) by
callers dealing with either only numbers of only pointers. Are you
saying there are no such "clean" callers? That would put the overall
code in a pretty bad light imo.

Jan


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

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

[Andrew Cooper]

On 18/08/16 02:59, Doug Goldstein wrote:
> On 8/17/16 7:49 AM, Jan Beulich wrote:
> On 17.08.16 at 01:28,  wrote:
>>> There can only ever be one mtrr_if now and that is the generic
>>> implementation
>> This is only true when taking into consideration that cpu_has_mtrr
>> is #define-d to 1 right now. I'm not sure that's actually a good
>> assumption (especially when think about running Xen itself
>> virtualized, or possibly adding a mode of operation where no MTRRs
>> are to be used). But if we want to keep it that way, then I'd suggest
>> this patch should include removing cpu_has_mtrr (which will then
>> show to the reviewers that the checks of mtrr_if against NULL
>> indeed are dead code.
> Sure I can remove cpu_has_mtrr that would certainly make it cleaner. Is
> it ok with you and Andrew to make the assumption that we'll always have
> MTRRs (until the day we don't like you described)?

Please don't remove cpu_has_mtrr.  I plan to make better use of it with
the future plan to move PV guests into a PVH container.

In such a case, the PVH container won't want/need MTRRs, and we will get
better performance by not having them available.

~Andrew

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

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

[Jan Beulich]

>>> On 18.08.16 at 03:59,  wrote:
> On 8/17/16 7:49 AM, Jan Beulich wrote:
> On 17.08.16 at 01:28,  wrote:
>>> There can only ever be one mtrr_if now and that is the generic
>>> implementation
>> 
>> This is only true when taking into consideration that cpu_has_mtrr
>> is #define-d to 1 right now. I'm not sure that's actually a good
>> assumption (especially when think about running Xen itself
>> virtualized, or possibly adding a mode of operation where no MTRRs
>> are to be used). But if we want to keep it that way, then I'd suggest
>> this patch should include removing cpu_has_mtrr (which will then
>> show to the reviewers that the checks of mtrr_if against NULL
>> indeed are dead code.
> 
> Sure I can remove cpu_has_mtrr that would certainly make it cleaner. Is
> it ok with you and Andrew to make the assumption that we'll always have
> MTRRs (until the day we don't like you described)?

Well, that's what I've basically put up for discussion. My personal
preference would be to drop the hard coding of cpu_has_mtrr (and
hence keep it as well as mtrr_if).

>>> --- a/xen/arch/x86/cpu/mtrr/mtrr.h
>>> +++ b/xen/arch/x86/cpu/mtrr/mtrr.h
>>> @@ -63,8 +63,8 @@ extern void set_mtrr_ops(const struct mtrr_ops *);
>>>  extern u64 size_or_mask, size_and_mask;
>>>  extern const struct mtrr_ops *mtrr_if;
>>>  
>>> -#define is_cpu(vnd)(mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
>>> -#define use_intel()(mtrr_if && mtrr_if->use_intel_if == 1)
>>> +#define is_cpu(vnd)(X86_VENDOR_INTEL == X86_VENDOR_##vnd)
>>> +#define use_intel()(1)
>> 
>> Is the latter really useful to keep then?
> 
> Would you like me to squash patch 4 into this or make a note in the
> commit message that further clean ups are coming?

Either way is fine with me, all I wish is for it to be clear that you
don't stop half ways with the cleanup (which I'm glad you took a
stab on, btw).

Jan


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

Re: [Xen-devel] [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static

[Jan Beulich]

>>> On 18.08.16 at 03:38,  wrote:
> On 8/17/16 7:36 AM, Jan Beulich wrote:
> On 17.08.16 at 01:28,  wrote:
>>> For the functions that make up the interface to the MTRR code, drop the
>>> static keyword and prefix them all with mtrr for improved clarity when
>>> they're called outside this file. This also required adjusting or
>>> providing function prototypes to make them callable.
>> 
>> I can see why you want to do this for non-static functions, but I can't
>> see why static ones would need to get altered (unless you mean to call
>> them directly in subsequent patches, in which case the rationale above
>> should be adjusted). Nor can I see why the two functions previously
>> having been non-static can't simply be made static, without changing
>> their names, as the patch demonstrates that they don't have callers
>> in other CUs.
> 
> I've added:
> 
> Future changes will directly call these functions instead of using the
> indirect call through the ops structure.
> 
> Does that work?

Sure, having seen the further parts of the series.

Jan


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

Re: [Xen-devel] [PATCH 0/2] tools/libs: don't use alloca(3)

[Wei Liu]

On Thu, Aug 18, 2016 at 01:39:08AM +0200, Dario Faggioli wrote:
> On Wed, 2016-08-17 at 15:33 +0100, Wei Liu wrote:
> > Wei Liu (2):
> >   libs/gnttab: do not use alloca(3)
> >   libs/foreignmemory: do not use alloca(3)
> > 
> FWIW, both patches:
> 
> Reviewed-by: Dario Faggioli 
> 

Thanks for reviewing.

Wei.

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

Re: [Xen-devel] hvm_start_info in public header

[Wei Liu]

On Thu, Aug 18, 2016 at 10:27:56AM +0100, Andrew Cooper wrote:
> On 18/08/16 06:59, Juergen Gross wrote:
> > Anthony has sent out a patch to move struct hvm_start_info from
> > tools/libxc/include/xc_dom.h to a public header:
> >
> > [PATCH v7 06/15] xen: Move the hvm_start_info C representation to the
> > public headers
> >
> > Would it be possible to take that patch? I'd need it for switching
> > Mini-OS to be started as HVMlite guest.
> 
> Unfortunately it is still pending a toolstack ack, but I see no problem
> in principle with fast tracking it.
> 

I can commit that now.

Wei.

> ~Andrew

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

Re: [Xen-devel] hvm_start_info in public header

[Andrew Cooper]

On 18/08/16 06:59, Juergen Gross wrote:
> Anthony has sent out a patch to move struct hvm_start_info from
> tools/libxc/include/xc_dom.h to a public header:
>
> [PATCH v7 06/15] xen: Move the hvm_start_info C representation to the
> public headers
>
> Would it be possible to take that patch? I'd need it for switching
> Mini-OS to be started as HVMlite guest.

Unfortunately it is still pending a toolstack ack, but I see no problem
in principle with fast tracking it.

~Andrew

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

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Daniel Kiper]

On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04,  wrote:

[...]

> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> > +mbi_out->flags |= MBI_MEMMAP;
> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
>
> Okay, here you use the entry size as provided by grub, allowing
> compatibility even when the boot loader uses a newer layout (with
> extra fields added to the end). However ...
>
> > +mbi_out->mmap_length *= sizeof(memory_map_t);
> > +
> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> > +
> > +mmap_src = get_mb2_data(tag, mmap, entries);
> > +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> > +
> > +for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); 
> > i++ )
> > +{
> > +/* Init size member properly. */
> > +mmap_dst[i].size = sizeof(memory_map_t);
> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> > +/* Now copy a given region data. */
> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
>
> ... here you index an array of type multiboot2_memory_map_t.

All calculations looks correct, so, I am not sure what is wrong here.

> Also note that in any event you should check that
> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
> to go with the flexible model, ==).

This make sense to some extent. However, I am not sure what we should do
if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
model). Just do not fill memory map? Probably yes...

> > +typedef struct {
> > +u32 type;
> > +u32 size;
> > +char string[0];
>
> This is not a public header - please omit the 0 here and in a similar
> place further down, as we're using all sorts of gcc extensions anyway.

OK.

Daniel

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

[Xen-devel] [PATCH] tools/xenalyze: append argp LD flags if needed

[Roger Pau Monne]

This is a side-effect of commit c36e1c, which currently prevents compiling
xenalyze with libcs that don't have argp built-in.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Wei Liu 
Cc: Ian Jackson 
---
 tools/xentrace/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
index a85ed33..c8c36a8 100644
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -50,7 +50,7 @@ xentrace_setsize: setsize.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) $(APPEND_LDFLAGS)
 
 xenalyze: xenalyze.o mread.o
-   $(CC) $(LDFLAGS) -o $@ $^ $(APPEND_LDFLAGS)
+   $(CC) $(LDFLAGS) -o $@ $^ $(ARGP_LDFLAGS) $(APPEND_LDFLAGS)
 
 -include $(DEPS)
 
-- 
2.7.4 (Apple Git-66)


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a012df5ec643a0c08c2b723a02919a5c9373ca74
baseline version:
 ovmf 7503cd70fb864a5663edb121c9b2488b4c69e7f5

Last test of basis   100534  2016-08-17 13:44:54 Z0 days
Testing same since   100540  2016-08-18 05:15:52 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=a012df5ec643a0c08c2b723a02919a5c9373ca74
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
a012df5ec643a0c08c2b723a02919a5c9373ca74
+ branch=ovmf
+ revision=a012df5ec643a0c08c2b723a02919a5c9373ca74
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xa012df5ec643a0c08c2b723a02919a5c9373ca74 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'

Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote:
> >>> On 11.08.16 at 16:12,  wrote:
>  On 06.08.16 at 01:04,  wrote:
> >> --- a/xen/arch/x86/boot/reloc.c
> >> +++ b/xen/arch/x86/boot/reloc.c
> >> @@ -32,60 +32,69 @@ typedef unsigned int u32;
> >>
> >>  static u32 alloc;
> >>
> >> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> >> +static u32 alloc_mem(u32 bytes)
> >
> > Conversion of alloc to be of pointer type (in the earlier patch), and
> > then making the return type here and ...
> >
> >> +static u32 copy_mem(u32 src, u32 bytes)
> >
> > ... all of the types here follow suit would apparently be quite
> > beneficial to the number of casts needed.
>
> Or maybe, considering patch 8, in a slight variation thereof: Do
> the conversion as suggested, but have a helper wrapper of the
> type above, taking care of all the casting. That way both the
> actual implementation and the callers can stay (mostly) cast free.

We should take into account patch 9 here too. Looking at code after
it I think that right now it is very well optimized in terms of casts.
I cannot see room for further improvement. Every change you proposed
here and there does not improve final code. It justs move/change casts
to/in different places. So, I think that it does not pay change casts
here and in earlier patches. At least in the way you proposed until now.

Daniel

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 
67537

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67537
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67537

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

version targeted for testing:
 qemuuf3b9e787aee6ef7d216b616675db0f1c124da5e4
baseline version:
 qemuu60ac136102098a70b97ab0c07bc7bf53131c

Last test of basis67537  2016-08-15 17:14:39 Z2 days
Testing same since67549  2016-08-17 08:17:05 Z1 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Bharata B Rao 
  Cao jin 
  Cédric Le Goater 
  David Gibson 
  Greg Kurz 
  Laurent Vivier 
  Michael S. Tsirkin 
  Paul Durrant 
  Peter Maydell 
  Pranith Kumar 
  Stefan Hajnoczi 
  Stefano Stabellini 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  41f5c2ca27762770a40187fe63459c10a74c79f9
baseline version:
 libvirt  3edcf83433c25ff871ba2be9504128449722fb11

Last test of basis   100525  2016-08-17 04:21:22 Z1 days
Testing same since   100538  2016-08-18 04:19:40 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  John Ferlan 
  Ján Tomko 
  Pavel Hrdina 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=41f5c2ca27762770a40187fe63459c10a74c79f9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec 

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

[Juergen Gross]

On 02/08/16 09:22, Juergen Gross wrote:
> The default for the Xen hypervisor is to not enable VPMU in order to
> avoid security issues. In this case the Linux kernel will issue the
> message "Could not initialize VPMU for cpu 0, error -95" which looks
> more like an error than a normal state.
> 
> Change the message to something less scary in case the hypervisor
> returns EOPNOTSUPP or ENOSYS when trying to activate VPMU.
> 
> Signed-off-by: Juergen Gross 

David, could you take this patch, please?


Juergen

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

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

[Juergen Gross]

On 02/08/16 08:53, Juergen Gross wrote:
> There are two functions with name xen_pmu_init() in the kernel. Rename
> the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in
> arch/x86/xen/pmu.c
> 
> To avoid the same problem in future rename some more functions.
> 
> Signed-off-by: Juergen Gross 

David, could you take this patch, please?


Juergen

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