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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 619e6cf19fa1ab98878972e109d0c579f37388cd
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  129 days
Failing since 65593  2015-12-08 23:44:51 Z  129 days  146 attempts
Testing same since91514  2016-04-15 14:53:46 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 86454
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86454

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

version targeted for testing:
 qemuubc8995cafa0c36b9e4be682e9a60d59484b33500
baseline version:
 qemuud1f8764099022bc1173f2413331b26d4ff609a0c

Last test of basis86454  2016-03-17 06:01:30 Z   29 days
Failing since 86547  2016-03-18 07:12:41 Z   28 days   28 attempts
Testing same since91477  2016-04-15 05:10:51 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexey Kardashevskiy 
  Andrew Baumann 
  Andrey Smetanin 
  Anthony Perard 
  Aurelien Jarno 
  Bandan Das 
  Bastian Koppelmann 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Bill Paul 
  Bruce Rogers 
  Cao jin 
  Changlong Xie 
  Christophe Fergeau 
  Corey Minyard 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Ed Maste 
  Edgar E. Iglesias 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Emilio G. Cota 
  Eric Blake 
  Eugene 

Re: [Xen-devel] Bug in x86 instruction emulator?

[wogiz]

On 2016-04-15 19:44, Andrew Cooper wrote:

On 15/04/16 18:33, wo...@openmailbox.org wrote:

On 2016-04-07 04:04, Jan Beulich wrote:

We'd need to know which exact exception (including error code and,
in the case of #PF, CR2 value) gets raised to the guest by what
specific piece of code in the hypervisor. That'll likely mean some
instrumentation of the hypervisor code.

Jan


I want to give it a try, but I'm not sure how the hypervisor code
should be modified.

Can anyone point me to some documentation or anything else that can
help me get started?


Very sorry - I have been busy with patches intended for the 4.7 code 
freeze.


What domU are you using?  Is the issue reproducible from a LiveCD by 
any

chance?

~Andrew


No problem. I appreciate your help.

I'm using Alpine Linux 3.3.3 domU, but I have also tested various 
versions

of Ubuntu.

The issue is reproducible from LiveCD, both Alpine and Ubuntu.

The only requriements to reproduce the fault is a Linux HVM domU with 
vga="qxl"
and qxl driver installed in domU. Xorg will segfault instantly when 
started, no

matter what Linux distro or other configuration.

William Z.


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  14 guest-saverestorefail blocked in 59254
 test-amd64-amd64-libvirt-xsm 14 guest-saverestorefail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore   

[Xen-devel] [linux-3.18 test] 91420: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 20 leak-check/check   fail REGR. vs. 86513
 test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check fail in 90979 REGR. 
vs. 86513

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 90979 pass in 91420
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 90979 
pass in 91420
 test-armhf-armhf-xl-vhd   9 debian-di-install  fail in 90979 pass in 91420
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 91272 pass in 
90979
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 91272 
pass in 91420
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail in 91272 pass in 91420
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 90979
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 91272

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 86513
 build-i386-rumpuserxen6 xen-buildfail   like 86513
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86513
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86513

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

version targeted for testing:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis86513  2016-03-17 21:21:40 Z   29 days
Testing same since89247  2016-04-06 22:15:59 Z9 days7 attempts


People who touched revisions under test:
  Alex Deucher 
  Avery Pennarun 
  Catalin Marinas 
  Chris Bainbridge 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b
baseline version:
 libvirt  fb6ec0ed3dd292670db523896e9dac45f6106fd4

Last test of basis91380  2016-04-14 09:48:59 Z1 days
Testing same since91479  2016-04-15 05:33:51 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Eli Qiao 
  Ján Tomko 
  Laine Stump 
  Nikolay Shirokovskiy 
  ShaoHe Feng 

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=8b62c65d24bdb20121d3147b4f4dc98bac4f024b
+ . ./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 ']'
++ 

[Xen-devel] [PATCH] xen/x86: don't lose event interrupts

[Stefano Stabellini]

On slow platforms with unreliable TSC, such as QEMU emulated machines,
it is possible for the kernel to request the next event in the past. In
that case, in the current implementation of xen_vcpuop_clockevent, we
simply return -ETIME. To be precise the Xen returns -ETIME and we pass
it on. However the result of this is a missed event, which simply causes
the kernel to hang.

Instead it is better to always ask the hypervisor for a timer event,
even if the timeout is in the past. That way there are no lost
interrupts and the kernel survives. To do that, remove the
VCPU_SSHOTTMR_future flag.

Signed-off-by: Stefano Stabellini 

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6deba5b 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -290,11 +290,11 @@ static int xen_vcpuop_set_next_event(unsigned long delta,
WARN_ON(!clockevent_state_oneshot(evt));
 
single.timeout_abs_ns = get_abs_timeout(delta);
-   single.flags = VCPU_SSHOTTMR_future;
+   /* Get an event anyway, even if the timeout is already expired */
+   single.flags = 0;
 
ret = HYPERVISOR_vcpu_op(VCPUOP_set_singleshot_timer, cpu, );
-
-   BUG_ON(ret != 0 && ret != -ETIME);
+   BUG_ON(ret != 0);
 
return ret;
 }

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Matt Fleming]

(Sorry, just realised I never replied to this)

On Wed, 13 Apr, at 01:59:10PM, Roger Pau Monné wrote:
> 
> Is this header compatible with the ELF header? Con both co-exist in the 
> same binary without issues?
 
Nope, they cannot. We get away with mixing bzImage headers and PE/COFF
headers for the EFI stub because bzImage has no magic string and
contains historical code at the start of the file. The code is never
executed in practice nowadays (it tells the user to use a boot loader
instead of direct execution) so we just stamp a PE/COFF header over it
when CONFIG_EFI_STUB is enabled.

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

[Xen-devel] [linux-3.16 test] 91397: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  3 host-install(3)   broken pass in 91249
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 91249 
pass in 91397
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 91249 
pass in 91397
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail in 91249 
pass in 91397

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 20 leak-check/check  fail blocked in 85048
 test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check fail blocked in 85048
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 85048
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 91249 like 85048
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 91249 like 85048
 build-i386-rumpuserxen6 xen-buildfail   like 85048
 build-amd64-rumpuserxen   6 xen-buildfail   like 85048
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 85048
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85048
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85048

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 91249 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 91249 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail  never pass
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10   fail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-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-libvirt-xsm 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux3a96c6601b6fc47baa6d296f9111ba7be4dad6fc
baseline version:
 linux7f2a8840d127c8d5c59a5d79235e1205aba2e102

Last test of basis85048  2016-03-02 10:56:10 Z   44 days
Testing same since87897  2016-03-29 14:28:05 Z   17 days   15 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 

Re: [Xen-devel] [PATCH libvirt v2 2/2] libxl: support vscsi

[Jim Fehlig]

On 04/13/2016 03:15 AM, Olaf Hering wrote:
> This uses the API version of the proposed vscsi support in libxl (v12):
> http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01772.html

We'll need to wait for that to land in xen.git before committing libxl scsi
support to libvirt.git, but thanks for putting the current work up for review.

> Is there anything else that needs to be done in libvirt?

We'll need code in src/xenconfig/xen_xl.* to convert xl vscis cfg <-> libvirt
domXML, along with tests in tests/xlconfigtest.

>  Right now libvirt scsi
> support is very simple minded, no support at all to describe host devices with
> persistant names.

Yes, I think you are correct, but I'm not aware of any reason that support
couldn't be added.

>  Example used during testing:
>
>   rawio='yes'>

IIRC, the 'managed' attribute only applies to PCI hostdevs.

>   
>
>
>   
>   
>   
>  
>
> Signed-off-by: Olaf Hering 
> Cc: Jim Fehlig 
> ---
>  src/libxl/libxl_conf.c   |  59 +++
>  src/libxl/libxl_conf.h   |   1 +
>  src/libxl/libxl_domain.c |   2 +-
>  src/libxl/libxl_driver.c | 187 
> +++
>  4 files changed, 248 insertions(+), 1 deletion(-)

Needs rebased against current libvirt.git master.

>
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index f5ef50f..1e3615e 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -1915,6 +1915,61 @@ libxlMakePCIList(virDomainDefPtr def, 
> libxl_domain_config *d_config)
>  }
>  
>  static int
> +libxlMakeVscsiList(libxl_ctx *ctx,
> +   XLU_Config *xlu,
> +   virDomainDefPtr def,
> +   libxl_domain_config *d_config)
> +{
> +virDomainHostdevDefPtr *l_hostdevs = def->hostdevs;
> +size_t i, nhostdevs = def->nhostdevs;
> +virDomainHostdevDefPtr hostdev;
> +virDomainHostdevSubsysSCSIPtr scsisrc;
> +char *str;
> +int rc = 0;
> +
> +if (nhostdevs == 0)
> +return 0;
> +
> +for (i = 0; i < nhostdevs; i++) {
> +hostdev = l_hostdevs[i];
> +if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS)
> +continue;
> +if (hostdev->source.subsys.type != 
> VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI)
> +continue;
> +scsisrc = >source.subsys.u.scsi;
> +if (scsisrc->protocol == VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_ISCSI)
> +continue;
> +#if defined(LIBXL_HAVE_VSCSI)
> +if (virAsprintf(, "%s:%u:%u:%u,%u:%u:%u:%llu%s",
> + scsisrc->u.host.adapter + strlen("scsi_host"),
> + scsisrc->u.host.bus,
> + scsisrc->u.host.target,
> + scsisrc->u.host.unit,
> + hostdev->info->addr.drive.controller,
> + hostdev->info->addr.drive.bus,
> + hostdev->info->addr.drive.target,
> + hostdev->info->addr.drive.unit,
> + scsisrc->rawio == VIR_TRISTATE_BOOL_YES ? 
> ",feature-host" : "") < 0) {
> +goto error;
> +};
> +rc = xlu_vscsi_config_add(xlu, ctx, str, _config->num_vscsictrls, 
> _config->vscsictrls);
> +VIR_FREE(str);
> +if (rc)
> +goto error;
> +#else
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> +   _("This version of libxenlight does not support 
> vscsi"));
> +goto error;
> +#endif
> +}
> +
> +return 0;
> +
> + error:
> +return -1;
> +}
> +
> +static int
>  libxlMakeVideo(virDomainDefPtr def, libxl_domain_config *d_config)
>  
>  {
> @@ -2059,6 +2114,7 @@ int
>  libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
> virDomainDefPtr def,
> libxl_ctx *ctx,
> +   XLU_Config *xlu,
> libxl_domain_config *d_config)
>  {
>  libxl_domain_config_init(d_config);
> @@ -2084,6 +2140,9 @@ libxlBuildDomainConfig(virPortAllocatorPtr 
> graphicsports,
>  if (libxlMakePCIList(def, d_config) < 0)
>  return -1;
>  
> +if (libxlMakeVscsiList(ctx, xlu, def, d_config) < 0)
> +return -1;
> +
>  /*
>   * Now that any potential VFBs are defined, update the build info with
>   * the data of the primary display. Some day libxl might implicitely do
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index b069e45..422c1d6 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -218,6 +218,7 @@ int
>  libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
> virDomainDefPtr def,
> libxl_ctx *ctx,
> +   XLU_Config *xlu,
> libxl_domain_config *d_config);
>  
>  static inline void
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index aed904b..02379c9 100644
> --- 

Re: [Xen-devel] [PATCH libvirt v2 1/2] libxl: include a XLU_Config in _libxlDriverConfig

[Jim Fehlig]

On 04/13/2016 03:15 AM, Olaf Hering wrote:
> Upcoming changes for vscsi will use libxlutil.so to prepare the
> configuration for libxl. The helpers needs a xlu struct for logging.
> Provide one and reuse the existing output as log target.
>
> Signed-off-by: Olaf Hering 
> Cc: Jim Fehlig 
> ---
>  src/libxl/libxl_conf.c | 7 +++
>  src/libxl/libxl_conf.h | 7 +++
>  2 files changed, 14 insertions(+)
>
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index d16280d..f5ef50f 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -93,6 +93,7 @@ libxlDriverConfigDispose(void *obj)
>  virObjectUnref(cfg->caps);
>  libxl_ctx_free(cfg->ctx);
>  xtl_logger_destroy(cfg->logger);
> +xlu_cfg_destroy(cfg->xlu);

This fails to compile if HAVE_LIBXLUTIL_H is not defined.

>  if (cfg->logger_file)
>  VIR_FORCE_FCLOSE(cfg->logger_file);
>  
> @@ -1738,6 +1739,12 @@ libxlDriverConfigNew(void)
>  goto error;
>  }
>  
> +cfg->xlu = xlu_cfg_init(cfg->logger_file, "libvirt");
> +if (!cfg->xlu) {
> +VIR_ERROR(_("cannot create xlu for libxenlight, disabling driver"));
> +goto error;
> +}
> +
>  if (libxl_ctx_alloc(>ctx, LIBXL_VERSION, 0, cfg->logger)) {
>  VIR_ERROR(_("cannot initialize libxenlight context, probably not "
>  "running in a Xen Dom0, disabling driver"));
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 3c0eafb..b069e45 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -27,6 +27,12 @@
>  # define LIBXL_CONF_H
>  
>  # include 
> +# ifdef HAVE_LIBXLUTIL_H
> +#  include 
> +# else
> +typedef struct XLU_Config XLU_Config;
> +XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);

You'll need to add xlu_cfg_destroy here.

Regards,
Jim

> +# endif
>  
>  # include "internal.h"
>  # include "libvirt_internal.h"
> @@ -96,6 +102,7 @@ struct _libxlDriverConfig {
>  /* log stream for driver-wide libxl ctx */
>  FILE *logger_file;
>  xentoollog_logger *logger;
> +XLU_Config *xlu;
>  /* libxl ctx for driver wide ops; getVersion, getNodeInfo, ... */
>  libxl_ctx *ctx;
>  
>
>
>


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

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

[Stefano Stabellini]

On Fri, 15 Apr 2016, Guenter Roeck wrote:
> On Fri, Apr 15, 2016 at 11:22:36AM -0700, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2016, Guenter Roeck wrote:
> > > Register with kernel restart handler instead of setting arm_pm_restart
> > > directly.
> > > 
> > > Select a high priority of 192 to ensure that default restart handlers
> > > are replaced if Xen is running.
> > > 
> > > Acked-by: Arnd Bergmann 
> > > Reviewed-by: Wolfram Sang 
> > > Reviewed-by: Stefano Stabellini 
> > > Signed-off-by: Guenter Roeck 
> > 
> > Thanks. I assume this is going to go in via Russell or Catalin's tree
> > with the rest of your series?
> > 
> I would suggest Russell, if he is willing to pick it up, since it mostly
> affects arm.

I am happy with that. In that case I'll remove this patch from my queue
not to have duplicates.


> 
> > 
> > > v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags
> > > 
> > >  arch/arm/xen/enlighten.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > > index 75cd7345c654..76a1d12fd27e 100644
> > > --- a/arch/arm/xen/enlighten.c
> > > +++ b/arch/arm/xen/enlighten.c
> > > @@ -27,6 +27,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -193,14 +194,22 @@ after_register_vcpu_info:
> > >   put_cpu();
> > >  }
> > >  
> > > -static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> > > +static int xen_restart(struct notifier_block *nb, unsigned long action,
> > > +void *data)
> > >  {
> > >   struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
> > >   int rc;
> > >   rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, );
> > >   BUG_ON(rc);
> > > +
> > > + return NOTIFY_DONE;
> > >  }
> > >  
> > > +static struct notifier_block xen_restart_nb = {
> > > + .notifier_call = xen_restart,
> > > + .priority = 192,
> > > +};
> > > +
> > >  static void xen_power_off(void)
> > >  {
> > >   struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
> > > @@ -370,7 +379,7 @@ static int __init xen_pm_init(void)
> > >   return -ENODEV;
> > >  
> > >   pm_power_off = xen_power_off;
> > > - arm_pm_restart = xen_restart;
> > > + register_restart_handler(_restart_nb);
> > >   if (!xen_initial_domain()) {
> > >   struct timespec64 ts;
> > >   xen_read_wallclock();
> > > -- 
> > > 2.5.0
> > > 
> 

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

[Xen-devel] [xen-unstable test] 91384: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 86491
 build-amd64-rumpuserxen   6 xen-buildfail   like 86491
 build-i386-rumpuserxen6 xen-buildfail   like 86491
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86491
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 86491
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86491
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86491

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

version targeted for testing:
 xen  ac703c285a4fbfcb85c19364ea0c67780bf16c2d
baseline version:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f

Last test of basis86491  2016-03-17 15:24:59 Z   29 days
Failing since 86560  2016-03-18 10:56:34 Z   28 days   29 attempts
Testing same since91226  2016-04-13 04:54:56 Z2 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper  [for the Ocaml stubs]
  Anthony PERARD 
  Boris Ostrovsky 
  Changlong Xie 
  Chong Li 
  Chong Li 
  Chunyan Liu 
  Dagaen Golomb 
  Daniel De Graaf 
  Daniel De Graaf  [XSM bits]
  Dario Fagggioli 
  Dario 

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

[Guenter Roeck]

On Fri, Apr 15, 2016 at 11:22:36AM -0700, Stefano Stabellini wrote:
> On Thu, 14 Apr 2016, Guenter Roeck wrote:
> > Register with kernel restart handler instead of setting arm_pm_restart
> > directly.
> > 
> > Select a high priority of 192 to ensure that default restart handlers
> > are replaced if Xen is running.
> > 
> > Acked-by: Arnd Bergmann 
> > Reviewed-by: Wolfram Sang 
> > Reviewed-by: Stefano Stabellini 
> > Signed-off-by: Guenter Roeck 
> 
> Thanks. I assume this is going to go in via Russell or Catalin's tree
> with the rest of your series?
> 
I would suggest Russell, if he is willing to pick it up, since it mostly
affects arm.

Guenter

> 
> > v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags
> > 
> >  arch/arm/xen/enlighten.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 75cd7345c654..76a1d12fd27e 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -193,14 +194,22 @@ after_register_vcpu_info:
> > put_cpu();
> >  }
> >  
> > -static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> > +static int xen_restart(struct notifier_block *nb, unsigned long action,
> > +  void *data)
> >  {
> > struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
> > int rc;
> > rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, );
> > BUG_ON(rc);
> > +
> > +   return NOTIFY_DONE;
> >  }
> >  
> > +static struct notifier_block xen_restart_nb = {
> > +   .notifier_call = xen_restart,
> > +   .priority = 192,
> > +};
> > +
> >  static void xen_power_off(void)
> >  {
> > struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
> > @@ -370,7 +379,7 @@ static int __init xen_pm_init(void)
> > return -ENODEV;
> >  
> > pm_power_off = xen_power_off;
> > -   arm_pm_restart = xen_restart;
> > +   register_restart_handler(_restart_nb);
> > if (!xen_initial_domain()) {
> > struct timespec64 ts;
> > xen_read_wallclock();
> > -- 
> > 2.5.0
> > 

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Stefano Stabellini]

On Fri, 15 Apr 2016, Luis R. Rodriguez wrote:
> On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall  wrote:
> > On 14/04/16 21:56, Luis R. Rodriguez wrote:
> >> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> But to make that work you have to emulate EFI firmware in the
> >>> hypervisor. Is that work you are signing up for?
> >>
> >> I'll do what is needed, as I have done before. If EFI is on the long
> >> term roadmap for ARM perhaps there are a few birds to knock with one
> >> stone here. If there is also interest to support other OSes through
> >> EFI standard means this also should help make that easier.
> >
> > We already have a working solution for EFI on ARM which does not require to
> > emulate the firmware in the hypervisor.
> 
> I get that.
> 
> > On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> > Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> > normally and it won't be possible to use BootServices anymore.
> >
> > For the guest, we provide a full support of EFI using OVMF.
> 
> I get that as well, is this the long term solution ?

Yes, it is for Xen on ARM.


> That still requires OVMF, will relying on OVMF always be what is used
> on Xen ARM ?

Not always, the native boot path is still supported. It is possible to
boot a VM using "kernel=/path/to/linux" in your VM config file and that
is not going to boot via EFI but via the native boot path.

To summarize, on ARM:

# DomUs options:
1) xl create "kernel=/path/to/ovfm.bin" -> OVMF -> EFI stub -> Linux (regular 
entry point)
2) xl create "kernel=/path/to/Linux" -> Linux (regular entry point)

# Dom0 options:
1) native UEFI firmare -> Xen (ExitBootServices) -> Linux (regular entry point)
2) uBoot -> Xen -> Linux (regular entry point)


> Was it too much of a burden to require OVMF?

No, it wasn't. Especially because Anthony had already introduced Xen
support in it.


> Is the upstream OVMF code pulled by Xen at build time on ARM, or just
> wget a binary ?

At the moment the build is not integrated, so you need to go and build
it yourself or use Raisin to do it.


> > For DOM0, Xen will craft the UEFI system table and the UEFI memory
> > map. The locations of those tables will be passed to DOM0 using a
> > tiny device-tree [1] and the kernel will boot using the native path.
> > The runtime services for DOM0 will be provided via hypercall.
> 
> Thanks this helps!
> 
> > The DOM0 approach has been discussed for a long time (see [3]) and I believe
> > this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> > ARM tiny. Adding any sort of emulation will increase the attack surface and
> > require more maintenance from our side.
> 
> OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
> x86 for the rest though) be a reasonable solution on x86 as an option
> then?

Reusing OVMF for HVMLite DomUs should be easy and something to look at
in the future. Reusing OVMF for HVMLite Dom0 is another story. I think
is a bad idea.

If we wanted to do something like we did on ARM, we need to understand
how the Linux internal API on x86 between the EFI stub and the regular
entry point look like. Is there even one? Could we elevate that to an
external interface and use it to boot Linux from Xen? If so, that would
be an option.

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

Re: [Xen-devel] [libvirt] [PATCH V2] libxl: use LIBXL_API_VERSION 0x040200

[Jim Fehlig]

On 04/15/2016 03:48 AM, Martin Kletzander wrote:
> On Thu, Apr 14, 2016 at 04:35:12PM -0600, Jim Fehlig wrote:
>> To ensure the libvirt libxl driver will build with future versions
>> of Xen where the libxl API may change in incompatible ways,
>> explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
>> does use new libxl APIs that have been added since Xen 4.2, but
>> currently it does not make use of any changes made to existing
>> APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
>> The version can be bumped if/when the libxl driver consumes the
>> changed APIs.
>>
>> Further details can be found in the following discussion thread
>>
>> https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html
>> Signed-off-by: Jim Fehlig 
>> ---
>> configure.ac |  2 ++
>> src/libxl/libxl_conf.h   | 12 
>> src/libxl/libxl_domain.c | 15 ---
>> 3 files changed, 2 insertions(+), 27 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index b1500f6..446f2a2 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -894,6 +894,7 @@ if test "$with_libxl" != "no" ; then
>> PKG_CHECK_MODULES([LIBXL], [xenlight], [
>>  LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight`
>>  LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight`
>> + LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200"
>>  with_libxl=yes
>> ], [LIBXL_FOUND=no])
>> if test "$LIBXL_FOUND" = "no"; then
>> @@ -906,6 +907,7 @@ if test "$with_libxl" != "no" ; then
>> LIBS="$LIBS $LIBXL_LIBS"
>> AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
>> with_libxl=yes
>> +LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200"
>> LIBXL_LIBS="$LIBXL_LIBS -lxenlight"
>> ],[
>> if test "$with_libxl" = "yes"; then
>
>
> Looks good, I'd just adjust these two hunks so that it's added in one
> place (and can be changed in one place later on so we don't fall into
> trouble accidentally.  ACK with that changed.

Thanks. I used one LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200"
after the test for libxenlight, and added a comment for good measure. Pushed 
now.

Regards,
Jim


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

[Xen-devel] [PATCH for-4.7 0/5] build: fixes for building Xen with clang

[Roger Pau Monne]

This series contain small bug-fixes for building the Xen microkernel with
clang. I think they are suitable for 4.7, but that's just my opinion.

I've also noticed that Xen always sets "-no-integrated-as" when using clang,
because previous versions (<3.8.0) didn't support .code16/.code32/.code64
in inline asm. This is solved at least in version 3.8.0 (haven't tested
older versions). The problem now to switch to the integrated clang assembler
is the usage of the rept instructions in some files in conjunction with
labels:

entry.S:403:15: error: unexpected token in '.rept' directive
.rept 48 -((.-compat_hypercall_table)/8)
  ^
entry.S:405:14: error: unmatched '.endr' directive
.endr
 ^
entry.S:408:15: error: unexpected token in '.rept' directive
.rept 64 -((.-compat_hypercall_table)/8)
  ^
entry.S:410:14: error: unmatched '.endr' directive
.endr
 ^
entry.S:455:15: error: unexpected token in '.rept' directive
.rept 48 -(.-compat_hypercall_args_table)
  ^
entry.S:457:14: error: unmatched '.endr' directive
.endr
 ^
entry.S:460:15: error: unexpected token in '.rept' directive
.rept 64 -(.-compat_hypercall_args_table)
  ^
entry.S:462:14: error: unmatched '.endr' directive
.endr
 ^

The entry.S file this errors come from is xen/arch/x86/x86_64/compat/entry.S

If anyone has any clever ideas about how to replace those instructions with
compatible ones, I'm more than willing to listen. AFAICT, this is the last
issue that prevents Xen from switch to the integrated clang assembler on
newer clang versions.

Thanks, Roger.

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

[Xen-devel] [PATCH for-4.7 5/5] travis: add an alias for gcc when using clang

[Roger Pau Monne]

In order to prevent it's usage. Since the tests are run on a Linux system
gcc is always present, so it's hard to detect if gcc is used in the clang
build.

Signed-off-by: Roger Pau Monné 
---
Cc: Doug Goldstein 
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index 741a8ab..a6688cc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -80,6 +80,7 @@ addons:
 before_script:
 - export CXX=${CC/cc/++}
 - export CXX=${CXX/clang/clang++}
+- [ "x${clang}" = "xy" ] && alias gcc=false
 script:
 - ( [ "x${RANDCONFIG}" = "xy" ] && ( make -C xen randconfig )
   || exit 0 )
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 4/5] build: remove Kconfig forced gcc selection

[Roger Pau Monne]

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

diff --git a/xen/tools/kconfig/Makefile.kconfig 
b/xen/tools/kconfig/Makefile.kconfig
index 815f306..dbd8912 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -36,8 +36,8 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
 CONFIG_SHELL := $(SHELL)
 
 # provide the host compiler
-HOSTCC := gcc
-HOSTCXX := g++
+HOSTCC ?= gcc
+HOSTCXX ?= g++
 
 # force target
 PHONY += FORCE
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value down to Kconfig

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index c908544..b483823 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -242,14 +242,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
randconfig
 .PHONY: $(kconfig)
 $(kconfig):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) $@
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) silentoldconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) defconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) defconfig
 
 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 2/5] build: set HOSTCXX based on clang value for Kconfig xconfig target

[Roger Pau Monne]

The xconfig Kconfig target requires a C++ compiler because it uses Qt.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 Config.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Config.mk b/Config.mk
index deaa768..5a31e2e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -50,9 +50,11 @@ clang ?= n
 ifeq ($(clang),n)
 gcc := y
 HOSTCC = gcc
+HOSTCXX = g++
 else
 gcc := n
 HOSTCC = clang
+HOSTCXX = clang++
 endif
 
 
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Roger Pau Monne]

Previously HOSTCC was always hardcoded to gcc

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 Config.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index bfab893..deaa768 100644
--- a/Config.mk
+++ b/Config.mk
@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS) := y
 SHELL ?= /bin/sh
 
 # Tools to run on system hosting the build
-HOSTCC  = gcc
 HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
 HOSTCFLAGS += -fno-strict-aliasing
 
@@ -50,8 +49,10 @@ DESTDIR ?= /
 clang ?= n
 ifeq ($(clang),n)
 gcc := y
+HOSTCC = gcc
 else
 gcc := n
+HOSTCC = clang
 endif
 
 
-- 
2.6.4 (Apple Git-63)


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

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

[Stefano Stabellini]

On Thu, 14 Apr 2016, Guenter Roeck wrote:
> Register with kernel restart handler instead of setting arm_pm_restart
> directly.
> 
> Select a high priority of 192 to ensure that default restart handlers
> are replaced if Xen is running.
> 
> Acked-by: Arnd Bergmann 
> Reviewed-by: Wolfram Sang 
> Reviewed-by: Stefano Stabellini 
> Signed-off-by: Guenter Roeck 

Thanks. I assume this is going to go in via Russell or Catalin's tree
with the rest of your series?


> v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags
> 
>  arch/arm/xen/enlighten.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd7345c654..76a1d12fd27e 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -193,14 +194,22 @@ after_register_vcpu_info:
>   put_cpu();
>  }
>  
> -static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> +static int xen_restart(struct notifier_block *nb, unsigned long action,
> +void *data)
>  {
>   struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
>   int rc;
>   rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, );
>   BUG_ON(rc);
> +
> + return NOTIFY_DONE;
>  }
>  
> +static struct notifier_block xen_restart_nb = {
> + .notifier_call = xen_restart,
> + .priority = 192,
> +};
> +
>  static void xen_power_off(void)
>  {
>   struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
> @@ -370,7 +379,7 @@ static int __init xen_pm_init(void)
>   return -ENODEV;
>  
>   pm_power_off = xen_power_off;
> - arm_pm_restart = xen_restart;
> + register_restart_handler(_restart_nb);
>   if (!xen_initial_domain()) {
>   struct timespec64 ts;
>   xen_read_wallclock();
> -- 
> 2.5.0
> 

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 04/15/16 20:38, Tamas K Lengyel wrote:
> 
> 
> On Fri, Apr 15, 2016 at 11:19 AM, Razvan Cojocaru
> > wrote:
> 
> On 04/15/16 20:12, Tamas K Lengyel wrote:
> >
> >
> > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru
> > 
>  >> wrote:
> >
> > Previously, subscribing to MSR write events was an all-or-none
> > approach, with special cases for introspection MSR-s. This patch
> > allows the vm_event consumer to specify exactly what MSR-s it is
> > interested in, and as a side-effect gets rid of the
> > vmx_introspection_force_enabled_msrs[] special case.
> > This replaces the previously posted "xen: Filter out MSR write
> > events" patch.
> >
> > Signed-off-by: Razvan Cojocaru  
> >  >>
> >
> > ---
> > Changes since V2:
> >  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
> >  - Introduced struct monitor_msr_bitmap as recommended by Andrew
> >Cooper, which allowed removing some pointer arithmetic magic.
> >  - Removed arch_ prefix from monitor functions, as recommended
> >by Tamas Lengyel.
> >  - Replaced the page allocation code with xzalloc() / xfree() for
> >struct monitor_msr_bitmap.
> >  - Now returning -ENXIO instead of -EINVAL from the monitor
> >functions, as recommended by Konrad Rzeszutek Wilk.
> > ---
> >  tools/libxc/include/xenctrl.h  |  4 +-
> >  tools/libxc/xc_monitor.c   |  6 +--
> >  xen/arch/x86/hvm/event.c   |  3 +-
> >  xen/arch/x86/hvm/hvm.c |  3 +-
> >  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
> >  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
> >  xen/arch/x86/monitor.c | 95
> > +-
> >  xen/arch/x86/vm_event.c|  9 
> >  xen/include/asm-x86/domain.h   |  4 +-
> >  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
> >  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
> >  xen/include/asm-x86/monitor.h  |  8 
> >  xen/include/public/domctl.h|  5 +-
> >  13 files changed, 121 insertions(+), 67 deletions(-)
> >
> > diff --git a/tools/libxc/include/xenctrl.h
> > b/tools/libxc/include/xenctrl.h
> > index f5a034a..9698d46 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface
> > *xch, domid_t domain_id,
> >  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t
> domain_id,
> >   uint16_t index, bool enable,
> bool sync,
> >   bool onchangeonly);
> > -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> > bool enable,
> > -  bool extended_capture);
> > +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> > uint32_t msr,
> > +  bool enable);
> >
> >
> > So my only concern with this approach here is that the MSR index
> > definitions that are supposed to be passed are never exported via a
> > public header, are only defined in asm-x86/msr-index.h. Should
> that also
> > be moved to be a public header as part of this patch?
> 
> There's usually an OS header defining those constants, at least with
> Linux. I've just checked on my Arch Linux now and I have
> /usr/include/asm/msr-index.h, so I would say that's not necessary.
> 
> Having said that, if you'd prefer that the Xen header file be made
> public I'm happy to do that.
> 
> 
> I just checked on Debian and got the same header so I'm OK with that.
> Adding a comment might then be enough specifying that the most common
> MSR indices can usually be found there (with a note saying
> non-architectural MSRs should be gathered from the manuals).

That sounds fair, I'll add the comment.


Thanks,
Razvan


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

Re: [Xen-devel] Bug in x86 instruction emulator?

[Andrew Cooper]

On 15/04/16 18:33, wo...@openmailbox.org wrote:
> On 2016-04-07 04:04, Jan Beulich wrote:
>> We'd need to know which exact exception (including error code and,
>> in the case of #PF, CR2 value) gets raised to the guest by what
>> specific piece of code in the hypervisor. That'll likely mean some
>> instrumentation of the hypervisor code.
>>
>> Jan
>
> I want to give it a try, but I'm not sure how the hypervisor code
> should be modified.
>
> Can anyone point me to some documentation or anything else that can
> help me get started?

Very sorry - I have been busy with patches intended for the 4.7 code freeze.

What domU are you using?  Is the issue reproducible from a LiveCD by any
chance?

~Andrew

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

On Fri, Apr 15, 2016 at 11:19 AM, Razvan Cojocaru  wrote:

> On 04/15/16 20:12, Tamas K Lengyel wrote:
> >
> >
> > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru
> > > wrote:
> >
> > Previously, subscribing to MSR write events was an all-or-none
> > approach, with special cases for introspection MSR-s. This patch
> > allows the vm_event consumer to specify exactly what MSR-s it is
> > interested in, and as a side-effect gets rid of the
> > vmx_introspection_force_enabled_msrs[] special case.
> > This replaces the previously posted "xen: Filter out MSR write
> > events" patch.
> >
> > Signed-off-by: Razvan Cojocaru  > >
> >
> > ---
> > Changes since V2:
> >  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
> >  - Introduced struct monitor_msr_bitmap as recommended by Andrew
> >Cooper, which allowed removing some pointer arithmetic magic.
> >  - Removed arch_ prefix from monitor functions, as recommended
> >by Tamas Lengyel.
> >  - Replaced the page allocation code with xzalloc() / xfree() for
> >struct monitor_msr_bitmap.
> >  - Now returning -ENXIO instead of -EINVAL from the monitor
> >functions, as recommended by Konrad Rzeszutek Wilk.
> > ---
> >  tools/libxc/include/xenctrl.h  |  4 +-
> >  tools/libxc/xc_monitor.c   |  6 +--
> >  xen/arch/x86/hvm/event.c   |  3 +-
> >  xen/arch/x86/hvm/hvm.c |  3 +-
> >  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
> >  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
> >  xen/arch/x86/monitor.c | 95
> > +-
> >  xen/arch/x86/vm_event.c|  9 
> >  xen/include/asm-x86/domain.h   |  4 +-
> >  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
> >  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
> >  xen/include/asm-x86/monitor.h  |  8 
> >  xen/include/public/domctl.h|  5 +-
> >  13 files changed, 121 insertions(+), 67 deletions(-)
> >
> > diff --git a/tools/libxc/include/xenctrl.h
> > b/tools/libxc/include/xenctrl.h
> > index f5a034a..9698d46 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface
> > *xch, domid_t domain_id,
> >  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
> >   uint16_t index, bool enable, bool sync,
> >   bool onchangeonly);
> > -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> > bool enable,
> > -  bool extended_capture);
> > +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> > uint32_t msr,
> > +  bool enable);
> >
> >
> > So my only concern with this approach here is that the MSR index
> > definitions that are supposed to be passed are never exported via a
> > public header, are only defined in asm-x86/msr-index.h. Should that also
> > be moved to be a public header as part of this patch?
>
> There's usually an OS header defining those constants, at least with
> Linux. I've just checked on my Arch Linux now and I have
> /usr/include/asm/msr-index.h, so I would say that's not necessary.
>
> Having said that, if you'd prefer that the Xen header file be made
> public I'm happy to do that.
>

I just checked on Debian and got the same header so I'm OK with that.
Adding a comment might then be enough specifying that the most common MSR
indices can usually be found there (with a note saying non-architectural
MSRs should be gathered from the manuals).

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

Re: [Xen-devel] Bug in x86 instruction emulator?

[wogiz]

On 2016-04-07 04:04, Jan Beulich wrote:

We'd need to know which exact exception (including error code and,
in the case of #PF, CR2 value) gets raised to the guest by what
specific piece of code in the hypervisor. That'll likely mean some
instrumentation of the hypervisor code.

Jan


I want to give it a try, but I'm not sure how the hypervisor code
should be modified.

Can anyone point me to some documentation or anything else that can
help me get started?

William Z.

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

On Fri, Apr 15, 2016 at 11:18 AM, Andrew Cooper 
wrote:

> On 15/04/16 18:12, Tamas K Lengyel wrote:
>
>
>
> On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru <
> rcojoc...@bitdefender.com> wrote:
>
>> Previously, subscribing to MSR write events was an all-or-none
>> approach, with special cases for introspection MSR-s. This patch
>> allows the vm_event consumer to specify exactly what MSR-s it is
>> interested in, and as a side-effect gets rid of the
>> vmx_introspection_force_enabled_msrs[] special case.
>> This replaces the previously posted "xen: Filter out MSR write
>> events" patch.
>>
>> Signed-off-by: Razvan Cojocaru < 
>> rcojoc...@bitdefender.com>
>>
>> ---
>> Changes since V2:
>>  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
>>  - Introduced struct monitor_msr_bitmap as recommended by Andrew
>>Cooper, which allowed removing some pointer arithmetic magic.
>>  - Removed arch_ prefix from monitor functions, as recommended
>>by Tamas Lengyel.
>>  - Replaced the page allocation code with xzalloc() / xfree() for
>>struct monitor_msr_bitmap.
>>  - Now returning -ENXIO instead of -EINVAL from the monitor
>>functions, as recommended by Konrad Rzeszutek Wilk.
>> ---
>>  tools/libxc/include/xenctrl.h  |  4 +-
>>  tools/libxc/xc_monitor.c   |  6 +--
>>  xen/arch/x86/hvm/event.c   |  3 +-
>>  xen/arch/x86/hvm/hvm.c |  3 +-
>>  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
>>  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
>>  xen/arch/x86/monitor.c | 95
>> +-
>>  xen/arch/x86/vm_event.c|  9 
>>  xen/include/asm-x86/domain.h   |  4 +-
>>  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
>>  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
>>  xen/include/asm-x86/monitor.h  |  8 
>>  xen/include/public/domctl.h|  5 +-
>>  13 files changed, 121 insertions(+), 67 deletions(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index f5a034a..9698d46 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface *xch,
>> domid_t domain_id,
>>  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
>>   uint16_t index, bool enable, bool sync,
>>   bool onchangeonly);
>> -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool
>> enable,
>> -  bool extended_capture);
>> +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t
>> msr,
>> +  bool enable);
>>
>
> So my only concern with this approach here is that the MSR index
> definitions that are supposed to be passed are never exported via a public
> header, are only defined in asm-x86/msr-index.h. Should that also be moved
> to be a public header as part of this patch?
>
>
> The MSRs are specified by the Intel/AMD manuals.  Furthermore, for the
> non-architectural ones, it is quite possible that the same index maps to
> different MSRs on different hardware.  It is definitely the case that
> different hadware has the same MSR at different indices.  (The Intel cpuid
> masking MSRs have this propery across different CPU generations).
>
> I expect the monitoring application to know the current hardware, and
> which MSRs are applicable.
>
> ~Andrew
>

Fair enough.

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Fri, Apr 15, 2016 at 05:03:07PM +0100, George Dunlap wrote:
> On 15/04/16 16:30, Luis R. Rodriguez wrote:
> > On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
> >> On 14/04/16 20:44, Luis R. Rodriguez wrote:
> >>> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> >>> be optional ? That way if you already support EFI that can be used on
> >>> your entires with some small modifications.
> >>
> >> I wasn't talking about actual non-Linux unikernels; I was talking about 
> >> using
> >> Linux in the way that unikernels are used ("unikernel-style").  That is, 
> >> you
> >> boot a minimal Linux image with a small ramdisk and have a single process
> >> running as init.  For this use case, even an extra megabyte of guest RAM 
> >> and
> >> an extra second of boot time is a significant cost.  "Use OVMF for domUs" 
> >> is
> >> an excellent solution for traditional VMs where you boot a full distro, but
> >> would impose a significant cost on using Linux in unikernel-style VMs.
> > 
> > Understood.
> > 
> >> Whether a stripped-down EFI support would be sufficiently low memory /
> >> latency for such workloads is an open question that would take time and
> >> engineering effort to discover.  And in any case, it would certainly
> >> require the maintenance of Yet Another Bootloader in the Xen source tree.
> > 
> > OVMF is used by ARM, so using it should be a matter of adaptation, and
> > some changes other than perhaps DT use. Question still stands though,
> > would it be possible to have HVMLite be using EFI as an option so that
> > some users could opt-in if they so wish ?
> 
> Well we definitely intend go have a mode of PVH* which boots OVMF to
> EFI-enabled guests, if that's what you mean.  For one thing, that should
> in theory allow us to boot Windows guests without needing to spin up
> qemu to emulate any devices (since OVMF will be able to access the PV
> devices until the Windows PV drivers come up).

OK so for Windows x86 HVMLite will need to go the EFI boot route for sure,
only it will use OVMF ?

> Booting to EFI-enabled
> distros is certainly something we want as well.
> 
> But we need an option for dom0, and ideally we'd like an option for
> lightweight Linux guests.  It's using EFI for those purposes that we're
> pushing back on.
> 
>  -George
> 
> * I'm saying PVH because I hope when everything is sorted out we can
> just call HVMLite PVH again.

OK sure, so so long as:

 * Other OSes don't have to use EFI
 * We keep a Linux non-EFI lightweight boot mechanism

Then the OVMF / EFI route (perhaps alternatives might be minimal EFI
emulation) is still a prospect on the table long term.

  Luis

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 04/15/16 20:12, Tamas K Lengyel wrote:
> 
> 
> On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru
> > wrote:
> 
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
> 
> Signed-off-by: Razvan Cojocaru  >
> 
> ---
> Changes since V2:
>  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
>  - Introduced struct monitor_msr_bitmap as recommended by Andrew
>Cooper, which allowed removing some pointer arithmetic magic.
>  - Removed arch_ prefix from monitor functions, as recommended
>by Tamas Lengyel.
>  - Replaced the page allocation code with xzalloc() / xfree() for
>struct monitor_msr_bitmap.
>  - Now returning -ENXIO instead of -EINVAL from the monitor
>functions, as recommended by Konrad Rzeszutek Wilk.
> ---
>  tools/libxc/include/xenctrl.h  |  4 +-
>  tools/libxc/xc_monitor.c   |  6 +--
>  xen/arch/x86/hvm/event.c   |  3 +-
>  xen/arch/x86/hvm/hvm.c |  3 +-
>  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
>  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
>  xen/arch/x86/monitor.c | 95
> +-
>  xen/arch/x86/vm_event.c|  9 
>  xen/include/asm-x86/domain.h   |  4 +-
>  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
>  xen/include/asm-x86/monitor.h  |  8 
>  xen/include/public/domctl.h|  5 +-
>  13 files changed, 121 insertions(+), 67 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> index f5a034a..9698d46 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface
> *xch, domid_t domain_id,
>  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
>   uint16_t index, bool enable, bool sync,
>   bool onchangeonly);
> -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> bool enable,
> -  bool extended_capture);
> +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> uint32_t msr,
> +  bool enable);
> 
>  
> So my only concern with this approach here is that the MSR index
> definitions that are supposed to be passed are never exported via a
> public header, are only defined in asm-x86/msr-index.h. Should that also
> be moved to be a public header as part of this patch?

There's usually an OS header defining those constants, at least with
Linux. I've just checked on my Arch Linux now and I have
/usr/include/asm/msr-index.h, so I would say that's not necessary.

Having said that, if you'd prefer that the Xen header file be made
public I'm happy to do that.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru 
wrote:

> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
>
> Signed-off-by: Razvan Cojocaru 
>
> ---
> Changes since V2:
>  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
>  - Introduced struct monitor_msr_bitmap as recommended by Andrew
>Cooper, which allowed removing some pointer arithmetic magic.
>  - Removed arch_ prefix from monitor functions, as recommended
>by Tamas Lengyel.
>  - Replaced the page allocation code with xzalloc() / xfree() for
>struct monitor_msr_bitmap.
>  - Now returning -ENXIO instead of -EINVAL from the monitor
>functions, as recommended by Konrad Rzeszutek Wilk.
> ---
>  tools/libxc/include/xenctrl.h  |  4 +-
>  tools/libxc/xc_monitor.c   |  6 +--
>  xen/arch/x86/hvm/event.c   |  3 +-
>  xen/arch/x86/hvm/hvm.c |  3 +-
>  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
>  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
>  xen/arch/x86/monitor.c | 95
> +-
>  xen/arch/x86/vm_event.c|  9 
>  xen/include/asm-x86/domain.h   |  4 +-
>  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
>  xen/include/asm-x86/monitor.h  |  8 
>  xen/include/public/domctl.h|  5 +-
>  13 files changed, 121 insertions(+), 67 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index f5a034a..9698d46 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface *xch,
> domid_t domain_id,
>  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
>   uint16_t index, bool enable, bool sync,
>   bool onchangeonly);
> -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool
> enable,
> -  bool extended_capture);
> +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t
> msr,
> +  bool enable);
>

So my only concern with this approach here is that the MSR index
definitions that are supposed to be passed are never exported via a public
header, are only defined in asm-x86/msr-index.h. Should that also be moved
to be a public header as part of this patch?

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

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

[Andrew Cooper]

On 15/04/16 18:12, Tamas K Lengyel wrote:
>
>
> On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru
> > wrote:
>
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
>
> Signed-off-by: Razvan Cojocaru  >
>
> ---
> Changes since V2:
>  - Bumped XEN_DOMCTL_INTERFACE_VERSION.
>  - Introduced struct monitor_msr_bitmap as recommended by Andrew
>Cooper, which allowed removing some pointer arithmetic magic.
>  - Removed arch_ prefix from monitor functions, as recommended
>by Tamas Lengyel.
>  - Replaced the page allocation code with xzalloc() / xfree() for
>struct monitor_msr_bitmap.
>  - Now returning -ENXIO instead of -EINVAL from the monitor
>functions, as recommended by Konrad Rzeszutek Wilk.
> ---
>  tools/libxc/include/xenctrl.h  |  4 +-
>  tools/libxc/xc_monitor.c   |  6 +--
>  xen/arch/x86/hvm/event.c   |  3 +-
>  xen/arch/x86/hvm/hvm.c |  3 +-
>  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
>  xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
>  xen/arch/x86/monitor.c | 95
> +-
>  xen/arch/x86/vm_event.c|  9 
>  xen/include/asm-x86/domain.h   |  4 +-
>  xen/include/asm-x86/hvm/hvm.h  |  8 ++--
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
>  xen/include/asm-x86/monitor.h  |  8 
>  xen/include/public/domctl.h|  5 +-
>  13 files changed, 121 insertions(+), 67 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> index f5a034a..9698d46 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface
> *xch, domid_t domain_id,
>  int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
>   uint16_t index, bool enable, bool sync,
>   bool onchangeonly);
> -int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> bool enable,
> -  bool extended_capture);
> +int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
> uint32_t msr,
> +  bool enable);
>
>  
> So my only concern with this approach here is that the MSR index
> definitions that are supposed to be passed are never exported via a
> public header, are only defined in asm-x86/msr-index.h. Should that
> also be moved to be a public header as part of this patch?

The MSRs are specified by the Intel/AMD manuals.  Furthermore, for the
non-architectural ones, it is quite possible that the same index maps to
different MSRs on different hardware.  It is definitely the case that
different hadware has the same MSR at different indices.  (The Intel
cpuid masking MSRs have this propery across different CPU generations).

I expect the monitoring application to know the current hardware, and
which MSRs are applicable.

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

Re: [Xen-devel] x86 patch ping

[Andrew Cooper]

On 08/04/16 13:10, Jan Beulich wrote:
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html
> (with the 1st patch having gone in already)

Apologies for the delay on this.  I now have results in.

The 64bit performance hit is within the noise (as expected) but sadly,
the performance impact of v3 on 32bit guests is even worse than previous
rounds.

From lmbench:

mmap() has an 85% latency hit.
pagefaults (on /local/scratch) gets a 78% hit.
pipe latency gets a 58% hit.
process fork()/exit() gets a 47% hit.

In each of these cases, that is about 20% worse that previous measurements.

As it currently stands, we really can't justify taking the fix in its
current form.

~Andrew

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Thu, Apr 14, 2016 at 10:02:47PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote:
> > Are you telling me that HVMLite has no dead code issues ?
> 
> You said earlier that baremetal has dead code issue. Then by extensions
> _any_ execution path has dead code issues.

;)

> > Are you *sure* we have no dead code concerns with HVMLite ?
> > If there are dead code concerns are you sure there might not
> > be differences between KVM and HVMLite ? Should cpuid be used to
> > address differences ? Will that enable to distinguish between
> > hybrid versions of HVMLite ? Are we sure ?
> 
> HVMLite CPU semantics will be the same as what a baremetal CPU
> semantics are.
> 
> Platform wise it will be different - as in, instead of say
> having a speaker (to emulated it) or RTC clock (again, another
> thing to emulate), or say IDE controller (again, another
> thing to emulate), or Realtek network card (again, another
> thing to emulate) - it has none of those.
> 
> [Keep in mind 'another thing to emulate', means 'another
> @$@() thing in QEMU that could be a security bug']
> 
> So it differs from an consumer x86 platform in that it has
> none of the 'legacy' stuff. And it requires PV drivers to
> function. And since it requires PV drivers to function
> only OSes that have those can use this mode.

OK that was a long winded way to suggest dead code differences may really lie
in the implications of using some PV drivers.  That seems sensible to me and is
a good starting point to consider in the future. This is helpful thanks.

For KVM, it shall be pretty similar, however instead of PV drivers we'd be
dealing with emulated hardware and drivers using / being able to detect
emulation.

For both, the size of the dead code that is possible would grow depending on
the dependencies / libraries that these things use in comparison to bare metal.

Likewise other than this both will rely on hardware virtualization extensions
and this may implicate some dead code impact, it will depend on what run time
differences this causes on code and the dependencies on those components.

> > > > We cannot use cpuid early in asm code, I'm looking for something we
> > > 
> > > ?! Why!?
> > 
> > What existing code uses it? If there is nothing you are still certain
> > it should work ? Would that work for old PV guest as well BTW ?
> 
> Yeah. For HVM/HVMLite it traps to the hypervisor.
> 
> For old PV guests it is unwise to use it as it goes straight to
> the hardware (as PV guests run in ring3 - they are considered
> 'userspace' and the Intel nor AMD do not trap on 'cpuid' in ring3
> -unless  you run in an VMX container).

OK one heuristic we may need then for both KVM and HVMLite could be 'Are we
using hardware virtualization extensions', as that seems to implicate we can
then trust cpuid to zero-in on any further low level virtualization semantics
we may need and from what you are saying this should even work on asm code as
early as the sun rises.

> > > > Right, but I'm saying that its rather silly to be adding entry points if
> > > > all we want the code to do is copy the boot params for us. The design
> > > > doc requires a new entry, and likewise you'd need yet-another-entry if
> > > > HVMLite is thrown out the window and come back 5 years later after new
> > > > hardware solutions are in place and need to redesign HVMLite. Kind of
> > > 
> > > Why would you need to redesign HVMLite based on hardware solutions?
> > 
> > That's what happened to Xen PV, right ? Are we sure 5 years from now we 
> > won't
> > have any new hardware virtualization features that will just obsolete 
> > HVMLite?
> 
> There were no hardware virtualization when Xen PV came about.
> 
> If there is hardware virtualization that obsoletes HVMLite that means
> it would also obsolete KVM and HVM mode

Indeed.

> > > The entrace point and the CPU state are pretty well known - it is akin
> > > to what GRUB2 bootloader path is (protected mode).
> > > > where we are with PVH today. Likewise if other paravirtualization
> > > > developers want to support Linux and want to copy your strategy they'd
> > > > add yet-another-entry-point as well.
> > > > 
> > > > This is dumb.
> > > 
> > > You saying the EFI entry point is dumb? That instead the EFI
> > > firmware should understand Linux bootparams and booted that?
> > 
> > EFI is a standard. Xen is not. And since we are not talking about legacy
> 
> And is a standard something that has to come out of a committee?
> 
> If so, then Linux bootparams is not a standard. Nor is LILO bootup
> path.

My point was that it is very likely that OSes will implement booting
EFI, so if they were going to do that, and if this was going to be
streamlined on different architectures EFI as an entry point makes
sense to consider for future code as an entry point.

> > hardware in the future, EFI seems like a sensible option to consider for an
> > entry point. Specially given that it may mean that 

Re: [Xen-devel] Code Review Dashboard (nearly-complete)

[Lars Kurth]

> On 14 Apr 2016, at 16:43, Wei Liu  wrote:
> 
> The way the documentation is arranged is not very
> structural and the glossary is missing at the moment. I think that can
> be improved.

See http://wiki.xenproject.org/wiki/Code_Review_Dashboard
Lars

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

Re: [Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released

[George Dunlap]

On Tue, Apr 12, 2016 at 5:19 PM, David Vrabel  wrote:
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does an on_selected_cpus() call.  IPIs on many socket
> machines can be very slow and on_selected_cpus() is serialized.
>
> It is safe to defer the invalidate until the p2m lock is released
> except for two cases:
>
> 1. When freeing a page table page (since partial translations may be
>cached).
> 2. When reclaiming a zero page as part of PoD.
>
> For these cases, add p2m_tlb_flush_sync() calls which will immediately
> perform the invalidate before the page is freed or reclaimed.
>
> Signed-off-by: David Vrabel 

Looks good, thanks:

Reviewed-by: George Dunlap 

 -George

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[George Dunlap]

On 15/04/16 16:30, Luis R. Rodriguez wrote:
> On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
>> On 14/04/16 20:44, Luis R. Rodriguez wrote:
>>> No, I meant to ask, would it be possible to make booting HVMLite using EFI
>>> be optional ? That way if you already support EFI that can be used on
>>> your entires with some small modifications.
>>
>> I wasn't talking about actual non-Linux unikernels; I was talking about using
>> Linux in the way that unikernels are used ("unikernel-style").  That is, you
>> boot a minimal Linux image with a small ramdisk and have a single process
>> running as init.  For this use case, even an extra megabyte of guest RAM and
>> an extra second of boot time is a significant cost.  "Use OVMF for domUs" is
>> an excellent solution for traditional VMs where you boot a full distro, but
>> would impose a significant cost on using Linux in unikernel-style VMs.
> 
> Understood.
> 
>> Whether a stripped-down EFI support would be sufficiently low memory /
>> latency for such workloads is an open question that would take time and
>> engineering effort to discover.  And in any case, it would certainly
>> require the maintenance of Yet Another Bootloader in the Xen source tree.
> 
> OVMF is used by ARM, so using it should be a matter of adaptation, and
> some changes other than perhaps DT use. Question still stands though,
> would it be possible to have HVMLite be using EFI as an option so that
> some users could opt-in if they so wish ?

Well we definitely intend go have a mode of PVH* which boots OVMF to
EFI-enabled guests, if that's what you mean.  For one thing, that should
in theory allow us to boot Windows guests without needing to spin up
qemu to emulate any devices (since OVMF will be able to access the PV
devices until the Windows PV drivers come up).  Booting to EFI-enabled
distros is certainly something we want as well.

But we need an option for dom0, and ideally we'd like an option for
lightweight Linux guests.  It's using EFI for those purposes that we're
pushing back on.

 -George

* I'm saying PVH because I hope when everything is sorted out we can
just call HVMLite PVH again.

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

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

[Alan Robinson]

On Fri, Apr 15, 2016 at 04:54:16PM +0200, Juergen Gross wrote:
> Subject: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in
>   xc_cpupool_removecpu()
> List-Id: Xen developer discussion 
> 
> Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu()
> for EBUSY case") added a retry loop in xc_cpupool_removecpu() for the
> EBUSY case. As EBUSY was returned in multiple error situations the
> loop would have been executed in situations where a retry would not
> be successful. Additionally calling sleep(1) between the rerires is a

s/rerires/retries/

Reviewed-by: Alan Robinson 

Alan


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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

[Juergen Gross]

On 15/04/16 17:25, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* 
> error codes"):
>> Requested-by: Ian Jackson 
>> Signed-off-by: Juergen Gross 
> 
> Acked-by: Ian Jackson 
> 
> Thanks this is very helpful.  I think it should go in as soon as the
> actual hypervisor code side has the appropriate ack.
> 
> But I have some suggestions for enhancement:
> 
>> +/*
>> + * Error return values of cpupool operations:
>> + *
>> + * -EADDRINUSE:
>> + *  XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu
>> + *which is to be removed from a cpupool.
> 
> I think this ought to mention the anomalous state the pcpu is left in,
> and advise what should be done about it.  I think it would be helpful
> to crib from my earlier xxx-ful text.  How about:
> 
>   In this case RMCPU may have been partially carried out and the pcpu
>   is left in an anomalous state.  In this state the pcpu may be used
>   by some not readily predictable subset of the vcpus (domains) whose
>   vcpus are in the old cpupool.
>  
>> The anomalous situation can be recovered by adding the pcpu back to
>> the cpupool it came from, and then retrying the RMCPU.
> 
> But I notice that the code you propose for libxc doesn't do the
> re-add: it just retries the remove.  So either the text above (which
> you and Dario seemed to agree with) is wrong, or the libxc code is
> wrong.

Re-adding it not necessary. A retry is all that is needed. In case
retries don't succeed for a long time either re-adding the cpu to
it's original pool or doing a "xl vcpu-pin -f ..." and a retry should
clean up the situation.

> And, perhaps we ought to mention here that this temporary pinning can
> only be done by the hardware domain ?  Or at least refer to the
> temporary pin operation.

Yes, together with the vcpu-pin -f hint.

I think this can wait until next week.


Juergen

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

Re: [Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

[Andrew Cooper]

On 15/04/16 13:33, Daniel Kiper wrote:
> reloc() is not called according to cdecl calling convention.
> This makes confusion and does not scale well for more arguments.
> And patch adding multiboot2 protocol support have to pass 3
> arguments instead of 2. Hence, move reloc() call to cdecl
> calling convention.
>
> I add push %ebp/mov %esp,%ebp/leave instructions here. Though they
> are not strictly needed in this patch. However, then assembly code
> in patch adding multiboot2 protocol support is easier to read.
>
> Suggested-by: Jan Beulich 
> Signed-off-by: Daniel Kiper 
> ---
> v3 - suggestions/fixes:
>- simplify assembly in xen/arch/x86/boot/reloc.c file
>  (suggested by Jan Beulich),
>- reorder arguments for reloc() call from xen/arch/x86/boot/head.S
>  (suggested by Jan Beulich),
>- improve commit message
>  (suggested by Jan Beulich).
> ---
>  xen/arch/x86/boot/head.S  |4 +++-
>  xen/arch/x86/boot/reloc.c |   18 ++
>  2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 32a54a0..28ac721 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -119,8 +119,10 @@ __start:
>  
>  /* Save the Multiboot info struct (after relocation) for later use. 
> */
>  mov $sym_phys(cpu0_stack)+1024,%esp
> -push%ebx
> +push%eax/* Boot trampoline address. */
> +push%ebx/* Multiboot information address. */
>  callreloc
> +add $8,%esp /* Remove reloc() args from stack. */
>  mov %eax,sym_phys(multiboot_ptr)
>  
>  /* Initialize BSS (no nasty surprises!). */
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index 63045c0..006f41d 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -10,15 +10,25 @@
>   *Keir Fraser 
>   */
>  
> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from xen/arch/x86/boot/head.S with:
> + *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
> + *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
> + */
>  asm (
>  ".text \n"
>  ".globl _start \n"
>  "_start:   \n"
> +"push %ebp \n"
> +"mov  %esp,%ebp\n"
>  "call 1f   \n"
> -"1:  pop  %ebx \n"
> -"mov  %eax,alloc-1b(%ebx)  \n"
> -"jmp  reloc\n"
> +"1:  pop  %ecx \n"
> +"mov  0xc(%ebp),%eax   \n"
> +"mov  %eax,alloc-1b(%ecx)  \n"
> +"push 0x8(%ebp)\n"
> +"call reloc\n"
> +"leave \n"
> +"ret   \n"
>  );
>  
>  /*

Come to think of this, why are we playing asm games like this at all?

This object file gets linked with head.o anyway, and the reloc()
function is safe to live anywhere in .init.text.  It might be worth
giving it a more descriptive name, as it would become a global symbol. 
How about relocate_trampoline_32bit() ?

~Andrew

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

Re: [Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

[Andrew Cooper]

On 15/04/16 13:33, Daniel Kiper wrote:
> Speedup BSS initialization by using stosl instead of stosb.
>
> Some may argue that Intel Ivy Bridge and later provide ERMSB feature.
> This means that "rep stosb" gives better throughput than "rep stosl" on
> above mentioned CPUs. However, this feature is only available on newer
> Intel processors and e.g. AMD does not provide it at all. So, stosb will
> just give real benefits and even beat stosl only on limited number of
> machines. On the other hand stosl will speedup BSS initialization on
> all x86 platforms. Hence, use stosl instead of stosb.
>
> Additionally, align relevant comment to coding style.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Daniel Kiper 
> ---
> v3 - suggestions/fixes:
>- improve comments
>  (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
>  (suggested by Jan Beulich).
> ---
>  xen/arch/x86/boot/head.S |5 +++--
>  xen/arch/x86/xen.lds.S   |3 +++
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index f3501fd..32a54a0 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -123,12 +123,13 @@ __start:
>  callreloc
>  mov %eax,sym_phys(multiboot_ptr)
>  
> -/* Initialize BSS (no nasty surprises!) */
> +/* Initialize BSS (no nasty surprises!). */
>  mov $sym_phys(__bss_start),%edi
>  mov $sym_phys(__bss_end),%ecx
>  sub %edi,%ecx
> +shr $2,%ecx
>  xor %eax,%eax
> -rep stosb
> +rep stosl
>  
>  /* Interrogate CPU extended features via CPUID. */
>  mov $0x8000,%eax
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 961f48f..6802da1 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -191,6 +191,8 @@ SECTIONS
> CONSTRUCTORS
>} :text
>  
> +  /* Align BSS to speedup its initialization. */
> +  . = ALIGN(4);

This is not needed.  There is already appropriate alignment before
__bss_start.

Also, you need to rebase this series onto staging - there are a lot of
changes you are missing.

~Andrew

>.bss : { /* BSS */
> . = ALIGN(STACK_SIZE);
> __bss_start = .;
> @@ -205,6 +207,7 @@ SECTIONS
> *(.bss.percpu.read_mostly)
> . = ALIGN(SMP_CACHE_BYTES);
> __per_cpu_data_end = .;
> +   . = ALIGN(4);
> __bss_end = .;
>} :text
>_end = . ;


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

Re: [Xen-devel] [PATCH v3 01/16] x86/boot: do not create unwind tables

[Andrew Cooper]

On 15/04/16 13:33, Daniel Kiper wrote:
> This way .eh_frame section is not included in *.lnk and *.bin files.
> Hence, final e.g. reloc.bin file size is reduced from 408 bytes to
> 272 bytes and it contains only used code and data.
>
> Suggested-by: Jan Beulich 
> Signed-off-by: Daniel Kiper 

Reviewed-by: Andrew Cooper 

(Although this entire series is 4.8 material now)

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

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

[Dario Faggioli]

On Fri, 2016-04-15 at 16:19 +0100, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 2/3] libxc: adjust retry loop in
> xc_cpupool_removecpu()"):
> > 
> > Commit 1ef6beea187b ("libxc: do some retries in
> > xc_cpupool_removecpu()
> > for EBUSY case") added a retry loop in xc_cpupool_removecpu() for
> > the
> > EBUSY case. As EBUSY was returned in multiple error situations the
> > loop would have been executed in situations where a retry would not
> > be successful. Additionally calling sleep(1) between the rerires is
> > a
> > bad idea when being called in a daemon.
> > 
> > The hypervisor has been changed to return different error values
> > now.
> > The retry added in above mentioned commit should be done in the
> > EADDRINUSE case now. As the error condition should last only for a
> > very short time, the sleep(1) call can be removed.
> > 
> > Requested-by: Ian Jackson 
> > Signed-off-by: Juergen Gross 
> Thanks.
> 
> Acked-by: Ian Jackson 
> 
Reviewed-by: Dario Faggioli 

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

[Ian Jackson]

Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error 
codes"):
> Requested-by: Ian Jackson 
> Signed-off-by: Juergen Gross 

Acked-by: Ian Jackson 

Thanks this is very helpful.  I think it should go in as soon as the
actual hypervisor code side has the appropriate ack.

But I have some suggestions for enhancement:

> +/*
> + * Error return values of cpupool operations:
> + *
> + * -EADDRINUSE:
> + *  XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu
> + *which is to be removed from a cpupool.

I think this ought to mention the anomalous state the pcpu is left in,
and advise what should be done about it.  I think it would be helpful
to crib from my earlier xxx-ful text.  How about:

  In this case RMCPU may have been partially carried out and the pcpu
  is left in an anomalous state.  In this state the pcpu may be used
  by some not readily predictable subset of the vcpus (domains) whose
  vcpus are in the old cpupool.
 
> The anomalous situation can be recovered by adding the pcpu back to
> the cpupool it came from, and then retrying the RMCPU.

But I notice that the code you propose for libxc doesn't do the
re-add: it just retries the remove.  So either the text above (which
you and Dario seemed to agree with) is wrong, or the libxc code is
wrong.


And, perhaps we ought to mention here that this temporary pinning can
only be done by the hardware domain ?  Or at least refer to the
temporary pin operation.

Ian.

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
> On 14/04/16 20:44, Luis R. Rodriguez wrote:
> > No, I meant to ask, would it be possible to make booting HVMLite using EFI
> > be optional ? That way if you already support EFI that can be used on
> > your entires with some small modifications.
> 
> I wasn't talking about actual non-Linux unikernels; I was talking about using
> Linux in the way that unikernels are used ("unikernel-style").  That is, you
> boot a minimal Linux image with a small ramdisk and have a single process
> running as init.  For this use case, even an extra megabyte of guest RAM and
> an extra second of boot time is a significant cost.  "Use OVMF for domUs" is
> an excellent solution for traditional VMs where you boot a full distro, but
> would impose a significant cost on using Linux in unikernel-style VMs.

Understood.

> Whether a stripped-down EFI support would be sufficiently low memory /
> latency for such workloads is an open question that would take time and
> engineering effort to discover.  And in any case, it would certainly
> require the maintenance of Yet Another Bootloader in the Xen source tree.

OVMF is used by ARM, so using it should be a matter of adaptation, and
some changes other than perhaps DT use. Question still stands though,
would it be possible to have HVMLite be using EFI as an option so that
some users could opt-in if they so wish ?

To be clear, at this point I am not suggesting this be done, just evaluating
the options available.

  Luis

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

Re: [Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

[Dario Faggioli]

On Fri, 2016-04-15 at 16:18 +0100, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 1/3] xen: return different error values
> for cpupool operations"):
> > 
> > Today there are several different situations in which moving a cpu
> > from or to a cpupool will return -EBUSY. This makes it hard for the
> > user to know what he did wrong, as the Xen tools are not capable to
> > print a detailed error message.
> > 
> > Depending on the situation return different error codes in order to
> > enable the tools to print useful messages.
> For what it's worth
> 
> Acked-by: Ian Jackson 
> 
Acked-by: Dario Faggioli 

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Fri, Apr 15, 2016 at 07:50:25AM +0200, Juergen Gross wrote:
> On 14/04/16 21:44, Luis R. Rodriguez wrote:
> > No, I meant to ask, would it be possible to make booting HVMLite using EFI
> > be optional ? That way if you already support EFI that can be used on
> > your entires with some small modifications.
> 
> So you suggest to add two HVMlite modes regarding boot interface
> instead of one?

Not suggest, I'm evaluating what options we have available. That's very
different from suggesting. That's the point to this whole topic, pure and
simple evaluation of options.

> Given how long the EFI standard is available now and how buggy many
> vendor's implementations are I don't expect all computers sold in 5
> years will have a usable EFI. This will be true especially for
> consumer devices where no EFI is available today.

Thanks this really helps.

  Luis

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

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

[Ian Jackson]

Juergen Gross writes ("[PATCH 2/3] libxc: adjust retry loop in 
xc_cpupool_removecpu()"):
> Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu()
> for EBUSY case") added a retry loop in xc_cpupool_removecpu() for the
> EBUSY case. As EBUSY was returned in multiple error situations the
> loop would have been executed in situations where a retry would not
> be successful. Additionally calling sleep(1) between the rerires is a
> bad idea when being called in a daemon.
> 
> The hypervisor has been changed to return different error values now.
> The retry added in above mentioned commit should be done in the
> EADDRINUSE case now. As the error condition should last only for a
> very short time, the sleep(1) call can be removed.
> 
> Requested-by: Ian Jackson 
> Signed-off-by: Juergen Gross 

Thanks.

Acked-by: Ian Jackson 

I will follow up with further patches to improve the behaviour of xl.

Ian.

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

Re: [Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

[Ian Jackson]

Juergen Gross writes ("[PATCH 1/3] xen: return different error values for 
cpupool operations"):
> Today there are several different situations in which moving a cpu
> from or to a cpupool will return -EBUSY. This makes it hard for the
> user to know what he did wrong, as the Xen tools are not capable to
> print a detailed error message.
> 
> Depending on the situation return different error codes in order to
> enable the tools to print useful messages.

For what it's worth

Acked-by: Ian Jackson 

although I have no real ability to review this code for correctness.

Ian.

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

[Xen-devel] [linux-4.1 baseline-only test] 44333: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44333 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44333/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-midway   15 guest-start/debian.repeat fail REGR. vs. 44328

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 44328
 build-i386-rumpuserxen6 xen-buildfail   like 44328

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 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 14 guest-saverestorefail  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-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-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-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-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-amd64-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-i386-xl-qemuu-win7-amd64 20 leak-check/checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux206f91a12c5f69c9b4dfd4e0029043794a046933
baseline version:
 linux7f30737678023b5becaf0e2e012665f71b886a7d

Last test of basis44328  2016-04-13 11:24:00 Z2 days
Testing same since44333  2016-04-15 04:27:20 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alex Deucher 
  Alexander Shishkin 
  Anand Moon 
  Avery Pennarun 
  Catalin Marinas 
  Charles Keepax 
  Chris Bainbridge 
  Dave Gerlach 
  David Engraf 
  Emmanuel Grumbach 
  Felipe Balbi 
  Felix Fietkau 
  Greg Kroah-Hartman 
  Grygorii Strashko 
  Hauke Mehrtens 
  He Kuang 
  Ingo Molnar 
  James Hogan 
  Jan Kara 
  Johannes Berg 
  Jouni Malinen 
  Ken Moffat 

Re: [Xen-devel] [PATCH 0/3] adjust error return values for cpupool operations

[Wei Liu]

On Fri, Apr 15, 2016 at 04:54:14PM +0200, Juergen Gross wrote:
> Some cpupool operations return the same error value for multiple
> situations. This makes it hard for the tools to react accordingly e.g.
> by issuing a suitable error message.
> 
> Return appropriate error values and document them.
> 
> Juergen Gross (3):
>   xen: return different error values for cpupool operations
>   libxc: adjust retry loop in xc_cpupool_removecpu()
>   xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes
> 
>  tools/libxc/xc_cpupool.c|  6 ++
>  xen/common/cpupool.c| 10 +-
>  xen/common/schedule.c   |  2 +-
>  xen/include/public/sysctl.h | 36 
>  4 files changed, 44 insertions(+), 10 deletions(-)
> 

In principle I agree we need better semantics and documentation of this
hypercall, and because this is new code so it's risk free, so:

  Release-acked-by: Wei Liu 

I will leave this series for Ian to review.

> -- 
> 2.6.6
> 

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall  wrote:
> On 14/04/16 21:56, Luis R. Rodriguez wrote:
>> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>>> But to make that work you have to emulate EFI firmware in the
>>> hypervisor. Is that work you are signing up for?
>>
>> I'll do what is needed, as I have done before. If EFI is on the long
>> term roadmap for ARM perhaps there are a few birds to knock with one
>> stone here. If there is also interest to support other OSes through
>> EFI standard means this also should help make that easier.
>
> We already have a working solution for EFI on ARM which does not require to
> emulate the firmware in the hypervisor.

I get that.

> On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> normally and it won't be possible to use BootServices anymore.
>
> For the guest, we provide a full support of EFI using OVMF.

I get that as well, is this the long term solution ? That still
requires OVMF, will relying on OVMF always be what is used on Xen ARM
? Was it too much of a burden to require OVMF? Is the upstream OVMF
code pulled by Xen at build time on ARM, or just wget a binary ?

> For DOM0, Xen
> will craft the UEFI system table and the UEFI memory map. The locations of
> those tables will be passed to DOM0 using a tiny device-tree [1] and the
> kernel will boot using the native path. The runtime services for DOM0 will
> be provided via hypercall.

Thanks this helps!

> The DOM0 approach has been discussed for a long time (see [3]) and I believe
> this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> ARM tiny. Adding any sort of emulation will increase the attack surface and
> require more maintenance from our side.

OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
x86 for the rest though) be a reasonable solution on x86 as an option
then?

  Luis

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

[Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

[Juergen Gross]

Today there are several different situations in which moving a cpu
from or to a cpupool will return -EBUSY. This makes it hard for the
user to know what he did wrong, as the Xen tools are not capable to
print a detailed error message.

Depending on the situation return different error codes in order to
enable the tools to print useful messages.

Requested-by: Ian Jackson 
Signed-off-by: Juergen Gross 
---
 xen/common/cpupool.c  | 10 +-
 xen/common/schedule.c |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index d0189f8..5dacc61 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -264,7 +264,7 @@ static int cpupool_assign_cpu_locked(struct cpupool *c, 
unsigned int cpu)
 struct domain *d;
 
 if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
-return -EBUSY;
+return -EADDRNOTAVAIL;
 ret = schedule_cpu_switch(cpu, c);
 if ( ret )
 return ret;
@@ -301,7 +301,7 @@ static long cpupool_unassign_cpu_helper(void *info)
 spin_lock(_lock);
 if ( c != cpupool_cpu_moving )
 {
-ret = -EBUSY;
+ret = -EADDRNOTAVAIL;
 goto out;
 }
 
@@ -366,7 +366,7 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned 
int cpu)
 c->cpupool_id, cpu);
 
 spin_lock(_lock);
-ret = -EBUSY;
+ret = -EADDRNOTAVAIL;
 if ( (cpupool_moving_cpu != -1) && (cpu != cpupool_moving_cpu) )
 goto out;
 if ( cpumask_test_cpu(cpu, _locked_cpus) )
@@ -537,7 +537,7 @@ static int cpupool_cpu_add(unsigned int cpu)
  */
 static int cpupool_cpu_remove(unsigned int cpu)
 {
-int ret = -EBUSY;
+int ret = -ENODEV;
 
 spin_lock(_lock);
 if ( system_state == SYS_STATE_suspend )
@@ -647,7 +647,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 ret = -EINVAL;
 if ( cpu >= nr_cpu_ids )
 goto addcpu_out;
-ret = -EBUSY;
+ret = -ENODEV;
 if ( !cpumask_test_cpu(cpu, _free_cpus) )
 goto addcpu_out;
 c = cpupool_find_by_id(op->cpupool_id);
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 013e5f1..5546999 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -688,7 +688,7 @@ int cpu_disable_scheduler(unsigned int cpu)
 {
 /* The vcpu is temporarily pinned, can't move it. */
 vcpu_schedule_unlock_irqrestore(lock, flags, v);
-ret = -EBUSY;
+ret = -EADDRINUSE;
 break;
 }
 
-- 
2.6.6


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

[Xen-devel] [PATCH 0/3] adjust error return values for cpupool operations

[Juergen Gross]

Some cpupool operations return the same error value for multiple
situations. This makes it hard for the tools to react accordingly e.g.
by issuing a suitable error message.

Return appropriate error values and document them.

Juergen Gross (3):
  xen: return different error values for cpupool operations
  libxc: adjust retry loop in xc_cpupool_removecpu()
  xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

 tools/libxc/xc_cpupool.c|  6 ++
 xen/common/cpupool.c| 10 +-
 xen/common/schedule.c   |  2 +-
 xen/include/public/sysctl.h | 36 
 4 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.6.6


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

[Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

[Juergen Gross]

Requested-by: Ian Jackson 
Signed-off-by: Juergen Gross 
---
 xen/include/public/sysctl.h | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 4596d20..82a2a3e 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -559,6 +559,42 @@ struct xen_sysctl_cpupool_op {
 typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
 
+/*
+ * Error return values of cpupool operations:
+ *
+ * -EADDRINUSE:
+ *  XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu
+ *which is to be removed from a cpupool.
+ * -EADDRNOTAVAIL:
+ *  XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: A previous
+ *request to remove a cpu from a cpupool was terminated with -EAGAIN
+ *and has not been retried using the same parameters.
+ * -EAGAIN:
+ *  XEN_SYSCTL_CPUPOOL_OP_RMCPU: The cpu can't be removed from the cpupool
+ *as it is active in the hypervisor. A retry will succeed soon.
+ * -EBUSY:
+ *  XEN_SYSCTL_CPUPOOL_OP_DESTROY, XEN_SYSCTL_CPUPOOL_OP_RMCPU: A cpupool
+ *can't be destroyed or the last cpu can't be removed as there is still
+ *a running domain in that cpupool.
+ * -EEXIST:
+ *  XEN_SYSCTL_CPUPOOL_OP_CREATE: A cpupool_id was specified and is already
+ *existing.
+ * -EINVAL:
+ *  XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: An illegal
+ *cpu was specified (cpu does not exist).
+ *  XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN: An illegal domain was specified
+ *(domain id illegal or not suitable for operation).
+ * -ENODEV:
+ *  XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: The specified
+ *cpu is either not free (add) or not member of the specified cpupool
+ *(remove).
+ * -ENOENT:
+ *  all: The cpupool with the specified cpupool_id doesn't exist.
+ *
+ * Some common error return values like -ENOMEM and -EFAULT are possible for
+ * all the operations.
+ */
+
 #define ARINC653_MAX_DOMAINS_PER_SCHEDULE   64
 /*
  * This structure is used to pass a new ARINC653 schedule from a
-- 
2.6.6


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

[Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

[Juergen Gross]

Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu()
for EBUSY case") added a retry loop in xc_cpupool_removecpu() for the
EBUSY case. As EBUSY was returned in multiple error situations the
loop would have been executed in situations where a retry would not
be successful. Additionally calling sleep(1) between the rerires is a
bad idea when being called in a daemon.

The hypervisor has been changed to return different error values now.
The retry added in above mentioned commit should be done in the
EADDRINUSE case now. As the error condition should last only for a
very short time, the sleep(1) call can be removed.

Requested-by: Ian Jackson 
Signed-off-by: Juergen Gross 
---
 tools/libxc/xc_cpupool.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
index 261b9c9..bb99e3b 100644
--- a/tools/libxc/xc_cpupool.c
+++ b/tools/libxc/xc_cpupool.c
@@ -139,7 +139,7 @@ int xc_cpupool_addcpu(xc_interface *xch,
 }
 
 /*
- * The hypervisor might return EBUSY when trying to remove a cpu from a
+ * The hypervisor might return EADDRINUSE when trying to remove a cpu from a
  * cpupool when a domain running in this cpupool has pinned a vcpu
  * temporarily. Do some retries in this case, perhaps the situation
  * cleans up.
@@ -160,9 +160,7 @@ int xc_cpupool_removecpu(xc_interface *xch,
 sysctl.u.cpupool_op.cpu = (cpu < 0) ? XEN_SYSCTL_CPUPOOL_PAR_ANY : cpu;
 for ( retries = 0; retries < NUM_RMCPU_BUSY_RETRIES; retries++ ) {
 err = do_sysctl_save(xch, );
-if ( err < 0 && errno == EBUSY )
-sleep(1);
-else
+if ( err == 0 || errno != EADDRINUSE )
 break;
 }
 return err;
-- 
2.6.6


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

Re: [Xen-devel] domain crashed when using VMFUNC

[liuweijie]

> On 15 Apr 2016, at 10:15 PM, Tamas K Lengyel  
> wrote:
> 
> 
> On Apr 15, 2016 07:46, "liuweijie"  > wrote:
> >
> > Dear list,
> >
> > When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes.
> >
> > My serial console shows like this:
> >
> > domain_crash called from p2m.c:2204
> > Domain 1 (vcpu#0) crashed on cpu#7
> > ……
> >
> > My testbed runs on Xen-4.6.0, and my CPU is Intel i7-4790. I can provide 
> > more logs if needed.
> >
> > I know you guys have implemented helpful interfaces to manage alternative 
> > P2Ms in version 4.6. Those ‘hvm_altp2m_op’ hypercalls are invoked before 
> > VMFUNC instructions are executed. And ten alternative P2Ms can be built 
> > successfully.
> >
> > The pseudo-code of my experiment is as follows:
> >
> > for (i = 0; i < 10; i++)
> > switch the current eptp to eptp[i];
> >
> >
> > However, once switching to eptp[4], namely when doing "mov eax 0; mov ecx 
> > 4; vmfunc.”, my Ubuntu HVM crashes. And as soon as I switched to more than 
> > 4 EPTPs, it crashed too. In other words, when I executed VMFUNC to switch 
> > to the fifth different altp2m, the domain would crash.
> >
> > Then when I just created 4 altp2ms, that weird phenomenon never happened 
> > again. Four altp2ms seems tolerable, but I still would like to use more. In 
> > addition, the Intel manual says we can switch between 512 altp2ms, right?
> >
> > FYI, I know the bug lies in the function ‘p2m_altp2m_lazy_copy’, and it is 
> > caused by the wrong return number of function ‘p2m_set_entry’.
> >
> > Can you guys fix the bug? Or is there something wrong with my test?
> >
> > Any help is appreciated! Thanks so much!
> >
> > Cheers,
> > Weijie.
> 
> Hi Weijie,
> While the hardware could handle 512 EPTs Xen only implements support for up 
> to 10. The crash you are seeing is likely caused by the domain running out 
> hap pool space when trying to copy the EPT to the new table. Try adding 
> 'shadow_memory=16' to your domain config, it should fix the crash.
> 
> Cheers,
> 
> Tamas

Thanks so much, Tamas!! Now it is working! 

I knew DRAKVUF! Big fan! So excited!

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH 3/3] xen: Document 
XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
> On 15/04/16 16:12, Ian Jackson wrote:
> > Does the hypervisor currently use EAGAIN for anything ?
> 
> Yes. Especially XEN_SYSCTL_CPUPOOL_OP_RMCPU can return it already.

That is a good reason not to use it.

> Before you are asking: Jan didn't want it to return EAGAIN in the
> temporary pinning case as the hypervisor couldn't guarantee that
> the situation will be resolved (opposed to the other usage of
> EAGAIN).

Hrm.  I note that ENOLCK is in the list in errno.h but not used
anywhere.  EISCONN is another possibility...

Ian.

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross]

On 15/04/16 16:11, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document 
> XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
>> Just saw there are still two cases left where EBUSY will be returned:
>>
>> - when trying to remove the last cpu from a cpupool with active domains
>>   (EBUSY seems appropriate)
> 
> The problem is that EBUSY here might mean "this operation can't be
> done because it amounts to a request for a configuration which
> violates an invariant" or "this operation can't be done for temporary
> reasons and you should retry it".

I'm not sure I understand your comment correctly: do you see a problem
with EBUSY being returned in the two cases I mentioned or just in the
one case you cited?


Juergen


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 61b02ba1f2a3f80fa06f5006f0aea1572093a067
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  129 days
Failing since 65593  2015-12-08 23:44:51 Z  128 days  145 attempts
Testing same since91423  2016-04-14 19:27:00 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin Haeuser 
  Marvin Häuser 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross]

On 15/04/16 16:12, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document 
> XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
>> However, a different return value for the super special case of
>> temporary pinning override could maybe be selected. I'm having a look,
>> and although I don't find one that could be seen as a perfect fit (that
>> would be EBUSY, which is taken!), what about one of these:
>>
>>   EEXIST17  /* File exists */
>>   ENOTEMPTY 39  /* Directory not empty */
>>   EROFS 30  /* Read-only file system */
>>   ENOSPC28  /* No space left on device */
> 
> Does the hypervisor currently use EAGAIN for anything ?

Yes. Especially XEN_SYSCTL_CPUPOOL_OP_RMCPU can return it already.
Before you are asking: Jan didn't want it to return EAGAIN in the
temporary pinning case as the hypervisor couldn't guarantee that
the situation will be resolved (opposed to the other usage of
EAGAIN).


Juergen


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

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

[osstest service owner]

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

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  f3a7ca02400d1c416e97451b4aebfaf608fc8192
baseline version:
 xen  ac703c285a4fbfcb85c19364ea0c67780bf16c2d

Last test of basis91132  2016-04-12 14:03:43 Z3 days
Testing same since91497  2016-04-15 12:05:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Roger Pau Monne 
  Roger Pau Monné 
  Vitaly Kuznetsov 
  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=f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ . ./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 
f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ branch=xen-unstable-smoke
+ revision=f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ . ./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.6-testing
+ '[' xf3a7ca02400d1c416e97451b4aebfaf608fc8192 = 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 

Re: [Xen-devel] block-iscsi with Xen 4.5 / 4.6

[Steven Haigh]

On 16/04/2016 12:30 AM, George Dunlap wrote:
> On Fri, Apr 15, 2016 at 7:59 AM, Steven Haigh  wrote:
>> Hi all,
>>
>> I'm wading through the somewhat confusing world of documentation regarding
>> storing DomU disk images on an iSCSI target.
>>
>> I'm getting an error when using pygrub of:
>> OSError: [Errno 2] No such file or directory:
>> 'iqn=iqn.1986-03.com.sun:02:ff2d12c0-b709-4ec0-999d-976506c666f5,portal=192.168.133.250'
>>
>> After much hunting, I came across this post:
>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02796.html
>>
>> As such, I'm wondering if it is still required to *NOT* use pygrub for
>> booting iSCSI DomUs?
>>
>> If so, what are the alternatives? Using pv-grub / pv-grub2? Something else?
>>
>> As I'm running EL7.2, I figure if I have to use a pv-grub based solution, it
>> would have to be pv-grub2?
> 
> I see you've got a fix already.  But even so, if using pv-grub2 is a
> possibility for you, it might be worth pursuing anyway:
> - it will be much more secure than pygrub
> - it will probably more reliable, since it's actually a native grub
> binary ported to Xen, while pygrub is just a python script that
> attempts to duplicate some of grub's functionality.

Hi George,

I kind of agree - its on my todo list, but I haven't managed to see much
about including it in a .spec build yet.

If you've done any work on this so far, I'd be happy to discuss off-list.

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



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

Re: [Xen-devel] block-iscsi with Xen 4.5 / 4.6

[George Dunlap]

On Fri, Apr 15, 2016 at 7:59 AM, Steven Haigh  wrote:
> Hi all,
>
> I'm wading through the somewhat confusing world of documentation regarding
> storing DomU disk images on an iSCSI target.
>
> I'm getting an error when using pygrub of:
> OSError: [Errno 2] No such file or directory:
> 'iqn=iqn.1986-03.com.sun:02:ff2d12c0-b709-4ec0-999d-976506c666f5,portal=192.168.133.250'
>
> After much hunting, I came across this post:
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02796.html
>
> As such, I'm wondering if it is still required to *NOT* use pygrub for
> booting iSCSI DomUs?
>
> If so, what are the alternatives? Using pv-grub / pv-grub2? Something else?
>
> As I'm running EL7.2, I figure if I have to use a pv-grub based solution, it
> would have to be pv-grub2?

I see you've got a fix already.  But even so, if using pv-grub2 is a
possibility for you, it might be worth pursuing anyway:
- it will be much more secure than pygrub
- it will probably more reliable, since it's actually a native grub
binary ported to Xen, while pygrub is just a python script that
attempts to duplicate some of grub's functionality.

 -George

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Konrad Rzeszutek Wilk]

On Fri, Apr 15, 2016 at 03:12:56PM +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document 
> XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
> > However, a different return value for the super special case of
> > temporary pinning override could maybe be selected. I'm having a look,
> > and although I don't find one that could be seen as a perfect fit (that
> > would be EBUSY, which is taken!), what about one of these:
> > 
> >   EEXIST        17  /* File exists */
> >   ENOTEMPTY     39      /* Directory not empty */
> >   EROFS         30  /* Read-only file system */
> >   ENOSPC        28      /* No space left on device */
> 
> Does the hypervisor currently use EAGAIN for anything ?

Yes. XEN_SYSCTL_pm_op, XSM, HVMOP_get_mem_type, MAP_PIRQ_TYPE_MULTI_MSI (ah
scratch that, it makes it -EINVAL).
> 
> Ian.

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

Re: [Xen-devel] domain crashed when using VMFUNC

[Tamas K Lengyel]

On Apr 15, 2016 07:46, "liuweijie"  wrote:
>
> Dear list,
>
> When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes.
>
> My serial console shows like this:
>
> domain_crash called from p2m.c:2204
> Domain 1 (vcpu#0) crashed on cpu#7
> ……
>
> My testbed runs on Xen-4.6.0, and my CPU is Intel i7-4790. I can provide
more logs if needed.
>
> I know you guys have implemented helpful interfaces to manage alternative
P2Ms in version 4.6. Those ‘hvm_altp2m_op’ hypercalls are invoked before
VMFUNC instructions are executed. And ten alternative P2Ms can be built
successfully.
>
> The pseudo-code of my experiment is as follows:
>
> for (i = 0; i < 10; i++)
> switch the current eptp to eptp[i];
>
>
> However, once switching to eptp[4], namely when doing "mov eax 0; mov ecx
4; vmfunc.”, my Ubuntu HVM crashes. And as soon as I switched to more than
4 EPTPs, it crashed too. In other words, when I executed VMFUNC to switch
to the fifth different altp2m, the domain would crash.
>
> Then when I just created 4 altp2ms, that weird phenomenon never happened
again. Four altp2ms seems tolerable, but I still would like to use more. In
addition, the Intel manual says we can switch between 512 altp2ms, right?
>
> FYI, I know the bug lies in the function ‘p2m_altp2m_lazy_copy’, and it
is caused by the wrong return number of function ‘p2m_set_entry’.
>
> Can you guys fix the bug? Or is there something wrong with my test?
>
> Any help is appreciated! Thanks so much!
>
> Cheers,
> Weijie.

Hi Weijie,
While the hardware could handle 512 EPTs Xen only implements support for up
to 10. The crash you are seeing is likely caused by the domain running out
hap pool space when trying to copy the EPT to the new table. Try adding
'shadow_memory=16' to your domain config, it should fix the crash.

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Ian Jackson]

Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document 
XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
> However, a different return value for the super special case of
> temporary pinning override could maybe be selected. I'm having a look,
> and although I don't find one that could be seen as a perfect fit (that
> would be EBUSY, which is taken!), what about one of these:
> 
>   EEXIST        17  /* File exists */
>   ENOTEMPTY     39      /* Directory not empty */
>   EROFS         30  /* Read-only file system */
>   ENOSPC        28      /* No space left on device */

Does the hypervisor currently use EAGAIN for anything ?

Ian.

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document 
XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
> Just saw there are still two cases left where EBUSY will be returned:
> 
> - when trying to remove the last cpu from a cpupool with active domains
>   (EBUSY seems appropriate)

The problem is that EBUSY here might mean "this operation can't be
done because it amounts to a request for a configuration which
violates an invariant" or "this operation can't be done for temporary
reasons and you should retry it".

Ian.

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

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
> new file mode 100644
> index 000..47db9c4
> --- /dev/null
> +++ b/xen/arch/x86/boot/build32.lds
> @@ -0,0 +1,49 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *  Daniel Kiper 

Drop the 'Daniel Kiper' part. Just Copyright (c) 2016 Oracle.

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

Re: [Xen-devel] abstract model of IOMMU unmaping/mapping failures

[George Dunlap]

On 31/03/16 10:06, Xu, Quan wrote:
> All,
> 
> Here is a summary of my investigation of the abstract model:
> 
> Below policies are adopted when deciding whether to rollback a callchain:
> 
> 1. Domain will be crashed immediately within iommu_{,un}map_page, treated as 
> a fatal error (with the exception of the hardware one). Whether to rollback 
> depends on the need of hardware domain;
> 
> 2. For hardware domain, roll back on a best effort basis. When rollback is 
> not feasible (in early initialization phase or trade-off of complexity), at 
> least unmap upon maps error and then throw out error message;
> 
> Below are a detail analysis of all existing callers on IOMMU interfaces (8-11 
> needs more discussions):

Hey Quan,

I only reviewed the p2m-related ones (5-10), but I agree with your and
Jan's conclusions.  Thanks for doing this legwork.

 -George


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

Re: [Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

[Konrad Rzeszutek Wilk]

On Fri, Apr 15, 2016 at 02:33:02PM +0200, Daniel Kiper wrote:
> Speedup BSS initialization by using stosl instead of stosb.
> 
> Some may argue that Intel Ivy Bridge and later provide ERMSB feature.
> This means that "rep stosb" gives better throughput than "rep stosl" on
> above mentioned CPUs. However, this feature is only available on newer
> Intel processors and e.g. AMD does not provide it at all. So, stosb will
> just give real benefits and even beat stosl only on limited number of
> machines. On the other hand stosl will speedup BSS initialization on
> all x86 platforms. Hence, use stosl instead of stosb.
> 
> Additionally, align relevant comment to coding style.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Daniel Kiper 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> v3 - suggestions/fixes:
>- improve comments
>  (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
>  (suggested by Jan Beulich).
> ---
>  xen/arch/x86/boot/head.S |5 +++--
>  xen/arch/x86/xen.lds.S   |3 +++
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index f3501fd..32a54a0 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -123,12 +123,13 @@ __start:
>  callreloc
>  mov %eax,sym_phys(multiboot_ptr)
>  
> -/* Initialize BSS (no nasty surprises!) */
> +/* Initialize BSS (no nasty surprises!). */
>  mov $sym_phys(__bss_start),%edi
>  mov $sym_phys(__bss_end),%ecx
>  sub %edi,%ecx
> +shr $2,%ecx
>  xor %eax,%eax
> -rep stosb
> +rep stosl
>  
>  /* Interrogate CPU extended features via CPUID. */
>  mov $0x8000,%eax
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 961f48f..6802da1 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -191,6 +191,8 @@ SECTIONS
> CONSTRUCTORS
>} :text
>  
> +  /* Align BSS to speedup its initialization. */
> +  . = ALIGN(4);
>.bss : { /* BSS */
> . = ALIGN(STACK_SIZE);
> __bss_start = .;
> @@ -205,6 +207,7 @@ SECTIONS
> *(.bss.percpu.read_mostly)
> . = ALIGN(SMP_CACHE_BYTES);
> __per_cpu_data_end = .;
> +   . = ALIGN(4);
> __bss_end = .;
>} :text
>_end = . ;
> -- 
> 1.7.10.4
> 

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

[Xen-devel] domain crashed when using VMFUNC

[liuweijie]

Dear list,

When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes. 

My serial console shows like this:

domain_crash called from p2m.c:2204
Domain 1 (vcpu#0) crashed on cpu#7
……

My testbed runs on Xen-4.6.0, and my CPU is Intel i7-4790. I can provide more 
logs if needed.

I know you guys have implemented helpful interfaces to manage alternative P2Ms 
in version 4.6. Those ‘hvm_altp2m_op’ hypercalls are invoked before VMFUNC 
instructions are executed. And ten alternative P2Ms can be built successfully.

The pseudo-code of my experiment is as follows:

for (i = 0; i < 10; i++)
switch the current eptp to eptp[i];


However, once switching to eptp[4], namely when doing "mov eax 0; mov ecx 4; 
vmfunc.”, my Ubuntu HVM crashes. And as soon as I switched to more than 4 
EPTPs, it crashed too. In other words, when I executed VMFUNC to switch to the 
fifth different altp2m, the domain would crash.

Then when I just created 4 altp2ms, that weird phenomenon never happened again. 
Four altp2ms seems tolerable, but I still would like to use more. In addition, 
the Intel manual says we can switch between 512 altp2ms, right?

FYI, I know the bug lies in the function ‘p2m_altp2m_lazy_copy’, and it is 
caused by the wrong return number of function ‘p2m_set_entry’.

Can you guys fix the bug? Or is there something wrong with my test?

Any help is appreciated! Thanks so much!

Cheers,
Weijie.

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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Dario Faggioli]

On Fri, 2016-04-15 at 15:20 +0200, Juergen Gross wrote:
> On 15/04/16 12:58, Dario Faggioli wrote:
> > 
> > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
> > > 
> > > The EBUSY returns of not successful repair attempts (trying to
> > > assign
> > > a
> > > cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?
> > > 
> > I'd go for EADDRINUSE and EADDRNOTAVAIL so the two error values are
> > similarly *wrong* hinting an addressing issue, which is more
> > consistent
> > (and would come handy when documenting) than having one pointing at
> > the
> > filesystem and the other at the address space.
> Just saw there are still two cases left where EBUSY will be returned:
> 
I know...

> - when trying to remove the last cpu from a cpupool with active
> domains
>   (EBUSY seems appropriate)
>
Indeed.

> - when trying to move a cpu which is not available in the source
> cpupool
>   or free cpus (I'd suggest ENODEV in this case)
> 
Well, in practice, I don't actually think this is too big of a deal. In
fact, I don't think that tools can or need to differentiate their
behavior too much between this and, for instance, the above mentioned
failure.

_However_, if while you're there you're up for making this case
returning ENODEV, it would indeed look like it's more descriptive of
the actual problem, and hence better.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] abstract model of IOMMU unmaping/mapping failures

[George Dunlap]

On 12/04/16 04:30, Xu, Quan wrote:
> George,
> 
> In this discussion, most of them are memory-related problems. Your comments 
> are valuable.
> If you have read this thread, could you give me some feedback? I really 
> appreciate your precious advice.

Sorry -- I was trying to get all the stuff for the hard freeze out of
the way last week.  I'm taking a look at this now.

 -George


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

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross]

On 15/04/16 12:58, Dario Faggioli wrote:
> On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
>> On 15/04/16 12:20, Ian Jackson wrote:
>>>
>>> Would either of you care to provide a version of my documentation
>>> patch
>>> which answers the questions that my text answers ?  Or shall we
>>> commit
>>> my version and you can edit it in-tree :-).
>> I can provide an updated patch.
>>
> Great.
> 
>>> All I need now is a recipe for the tools to tell what has happened
>>> and
>>> then I can make xl or libxl at least print comprehensible and
>>> correct
>>> error messages...
>> So this boils down to finding an appropriate ESOMETHING replacement
>> for the EBUSY case introduced by the temporary pinning.
>>
> Exactly.
> 
>> I think ENOTEMPTY or EADDRINUSE would fit best.
>>
> I like the latter better.
>>
>> The EBUSY returns of not successful repair attempts (trying to assign
>> a
>> cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?
>>
> I'd go for EADDRINUSE and EADDRNOTAVAIL so the two error values are
> similarly *wrong* hinting an addressing issue, which is more consistent
> (and would come handy when documenting) than having one pointing at the
> filesystem and the other at the address space.

Just saw there are still two cases left where EBUSY will be returned:

- when trying to remove the last cpu from a cpupool with active domains
  (EBUSY seems appropriate)
- when trying to move a cpu which is not available in the source cpupool
  or free cpus (I'd suggest ENODEV in this case)


Juergen

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

Re: [Xen-devel] Side channel attack

[Mihai Donțu]

On Fri, 15 Apr 2016 15:49:20 +0800 Zakirasafi wrote:
> The following code is for side channel attack on xen hypevisor. In this
> code I am having problem in understanding the highlighted red line. In the
> line what ".byte 15, byte 49" do???

You can use this trick in the future:

$ printf "\xf\x31" | ndisasm -b 64 -
  0F31  rdtsc

-- 
Mihai Donțu

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

Re: [Xen-devel] Side channel attack

[liuweijie]

Hi Zakirasafi,

> unsigned int timestamp(void)
> {
> unsigned int bottom;
> unsigned int top;
> *asm volatile(".byte 15;.byte 49" : "=a"(bottom),"=d"(top)); return bottom;*
> }

It is ‘RDTSC’ instruction.

Besides, I am happy that someone is also working on side channel attack on Xen. 
Maybe we can contact in private.

Weijie.



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

[Xen-devel] [PATCH v3 15/16 - RFC] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1 MiB and ends at 17 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with
that problem we must make Xen early boot code relocatable. This patch does
that. However, it does not add multiboot2 protocol interface which is done
in "x86: add multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - default load address is changed from 1 MiB to 2 MiB; I did that because
initial page tables are using 2 MiB huge pages and this way required
updates for them are quite easy; it means that e.g. we avoid spacial
cases for start and end of required memory region if it live at address
not aligned to 2 MiB,
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls,
  - %esi is used as base for Xen data relative addressing in 32-bit code.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v3 - not fixed yet:
   - small issue with remapping code in xen/arch/x86/setup.c,
   -  mkelf32 argument should
 be calculated dynamically; this issue has
 minimal impact on other parts of this patch.
---
 xen/arch/x86/Makefile  |6 +-
 xen/arch/x86/Rules.mk  |4 +
 xen/arch/x86/boot/head.S   |  162 ++--
 xen/arch/x86/boot/trampoline.S |6 +-
 xen/arch/x86/boot/wakeup.S |6 +-
 xen/arch/x86/boot/x86_64.S |   44 +--
 xen/arch/x86/setup.c   |   44 ++-
 xen/arch/x86/xen.lds.S |2 +-
 xen/include/asm-x86/config.h   |1 +
 xen/include/asm-x86/page.h |2 +-
 10 files changed, 186 insertions(+), 91 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 32d2407..0cc6f5f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -71,8 +71,10 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h 
-o \
  echo '$(TARGET).efi'; fi)
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
-   `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+#  THIS IS UGLY HACK! PLEASE DO NOT COMPLAIN. I WILL FIX IT IN NEXT 
RELEASE.
+   ./boot/mkelf32 $(TARGET)-syms $(TARGET) $(XEN_IMG_OFFSET) 
0x82d08100
+#  ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
+#  `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
 
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 3139886..7c76f80 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,6 +1,10 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET = 0x20
+
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 964851b..e322270 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,7 +12,7 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_offset(sym)   ((sym) - __XEN_VIRT_START)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -94,7 +94,7 @@ multiboot2_header_start:
 
 /* EFI64 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_start)
+   sym_offset(__efi64_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -106,11 +106,12 @@ multiboot2_header_end:
   

[Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of Multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  106 +--
 xen/arch/x86/boot/reloc.c |  152 -
 xen/arch/x86/x86_64/asm-offsets.c |7 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 427 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 1ff5937..e46d691 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,28 @@
 #define BOOT_PSEUDORM_CS 0x0020
 #define BOOT_PSEUDORM_DS 0x0028
 
+#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
+#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
+
+.macro mb2ht_args arg, args:vararg
+.long \arg
+.ifnb \args
+mb2ht_args \args
+.endif
+.endm
+
+.macro mb2ht_init type, req, args:vararg
+.align MULTIBOOT2_TAG_ALIGN
+.Lmb2ht_init_start\@:
+.short \type
+.short \req
+.long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
+.ifnb \args
+mb2ht_args \args
+.endif
+.Lmb2ht_init_end\@:
+.endm
+
 ENTRY(start)
 jmp __start
 
@@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
 multiboot1_header_end:
 
+/*** MULTIBOOT2 HEADER /
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
file. */
+.align  MULTIBOOT2_HEADER_ALIGN
+
+multiboot2_header_start:
+/* Magic number indicating a Multiboot2 header. */
+.long   MULTIBOOT2_HEADER_MAGIC
+/* Architecture: i386. */
+.long   MULTIBOOT2_ARCHITECTURE_I386
+/* Multiboot2 header length. */
+.long   multiboot2_header_end - multiboot2_header_start
+/* Multiboot2 header checksum. */
+.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+(multiboot2_header_end - multiboot2_header_start))
+
+/* Multiboot2 information request tag. */
+mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
+   MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
+
+/* Align modules at page boundry. */
+ 

[Xen-devel] [PATCH v3 06/16] x86/boot/reloc: Rename some variables and rearrange code a bit

[Daniel Kiper]

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code
a bit to make it more readable. Additionally, this way multiboot (v1)
protocol implementation and future multiboot2 protocol implementation
will use the same variable naming convention.

Signed-off-by: Daniel Kiper 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Jan Beulich 
---
v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - extract this change from main mutliboot2
 protocol implementation
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index d60a078..93b3845 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -84,41 +84,44 @@ static u32 copy_string(u32 src)
 return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t *reloc(u32 mbi_old)
+multiboot_info_t *reloc(u32 mbi_in)
 {
-multiboot_info_t *mbi = (multiboot_info_t *)copy_mem(mbi_old, 
sizeof(*mbi));
 int i;
+multiboot_info_t *mbi_out;
 
-if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = copy_string(mbi->cmdline);
+mbi_out = (multiboot_info_t *)copy_mem(mbi_in, sizeof(*mbi_out));
 
-if ( mbi->flags & MBI_MODULES )
+if ( mbi_out->flags & MBI_CMDLINE )
+mbi_out->cmdline = copy_string(mbi_out->cmdline);
+
+if ( mbi_out->flags & MBI_MODULES )
 {
 module_t *mods;
 
-mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+mbi_out->mods_addr = copy_mem(mbi_out->mods_addr,
+  mbi_out->mods_count * sizeof(module_t));
 
-mods = (module_t *)mbi->mods_addr;
+mods = (module_t *)mbi_out->mods_addr;
 
-for ( i = 0; i < mbi->mods_count; i++ )
+for ( i = 0; i < mbi_out->mods_count; i++ )
 {
 if ( mods[i].string )
 mods[i].string = copy_string(mods[i].string);
 }
 }
 
-if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
+if ( mbi_out->flags & MBI_MEMMAP )
+mbi_out->mmap_addr = copy_mem(mbi_out->mmap_addr, 
mbi_out->mmap_length);
 
-if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+if ( mbi_out->flags & MBI_LOADERNAME )
+mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
-mbi->flags &= (MBI_MEMLIMITS |
-   MBI_CMDLINE |
-   MBI_MODULES |
-   MBI_MEMMAP |
-   MBI_LOADERNAME);
+mbi_out->flags &= (MBI_MEMLIMITS |
+   MBI_CMDLINE |
+   MBI_MODULES |
+   MBI_MEMMAP |
+   MBI_LOADERNAME);
 
-return mbi;
+return mbi_out;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 11/16] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/efi/Makefile |   11 +++
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |6 ++
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..2a7d3e5 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,9 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
+efi := $(if $(efi),$(shell rm disabled)y)
 
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index f006575..d10c0ab 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1244,6 +1244,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index aa064e7..3eb21c1 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -167,6 +167,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
 unsigned int i, n;
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return -EOPNOTSUPP;
+
 switch ( idx )
 {
 case XEN_FW_EFI_VERSION:
@@ -301,6 +304,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
 EFI_STATUS status = EFI_NOT_STARTED;
 int rc = 0;
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return -EOPNOTSUPP;
+
 switch ( op->function )
 {
 case XEN_EFI_get_time:
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and
going down. Sadly this does not work when Xen is loaded using multiboot2
protocol because start lives on 1 MiB address. So, I tried to use
mem_lower address calculated by GRUB2. However, it works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((

In case of multiboot2 protocol we need that place_string() only allocate
memory chunk for EFI memory map. However, I think that it should be fixed
instead of making another function used just in one case. I thought about
two solutions.

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   this in e820 memory map and map it in Xen virtual address space.
   In later case we must also care about conflicts with e.g. crash
   kernel regions which could be quite difficult.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase
   Xen binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we want to use this memory pool for Xen and modules
   command line storage (it would be used when xen.efi is executed as EFI
   application) then we should add, I think, about 1 KiB. In this case,
   to be on safe side, we should assume at least 64 KiB pool for early
   memory allocations, which is about 4 times of our earlier calculations.
   However, during discussion on Xen-devel Jan Beulich suggested that
   just in case we should use 1 MiB memory pool like it was in original
   place_string() implementation. So, let's use 1 MiB as it was proposed.
   If we think that we should not waste unallocated memory in the pool
   on running system then we can mark this region as __initdata and move
   all required data to dynamically allocated places somewhere in __start_xen().

Now solution #2 is implemented but maybe we should consider #1 one day.

Jan Beulich added 1b) Do away with efi_arch_allocate_mmap_buffer() and use
   AllocatePages() uniformly, perhaps with a per-arch specified memory type
   (by means of which you can control whether the memory contents will remain
   preserved until the time you want to look at it). That will eliminate the
   only place_string() you're concerned about, with a patch with better
   diffstat (largely due to the questionable arch hook gone).

However, this solution does not solve conflicts problem described in #1
because EFI memory map is needed during Xen runtime after init phase.
So, finally we would get back to #1. Hmmm... Should I check how Linux
and others cope with that problem?

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/efi/efi-boot.h |   38 ++
 xen/arch/x86/setup.c|3 +--
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 6dbb14d..84afffa 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,36 @@ static void __init relocate_trampoline(unsigned long phys)
 *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define EBMALLOC_SIZE  MB(1)
+
+static char __initdata ebmalloc_mem[EBMALLOC_SIZE];
+static char __initdata *ebmalloc_free = NULL;
+
+/* EFI boot allocator. */
+static void __init *ebmalloc(size_t size)
+{
+void *ptr;
+
+/*
+ * Init ebmalloc_free on runtime. Static initialization
+ * will not work because it puts virtual address there.
+ */
+if ( ebmalloc_free == NULL )
+ebmalloc_free = ebmalloc_mem;
+
+ptr = ebmalloc_free;
+
+ebmalloc_free += size;
+
+if ( ebmalloc_free - ebmalloc_mem > sizeof(ebmalloc_mem) )
+blexit(L"Out of static memory\r\n");
+
+return ptr;
+}
+
 static void __init place_string(u32 *addr, const char *s)
 {
-static char *__initdata alloc = start;
+char *alloc = NULL;
 
 if ( s && *s )
 {
@@ -113,7 +140,7 @@ static void __init place_string(u32 *addr, const char *s)
 const char *old = (char *)(long)*addr;
 size_t len2 = *addr ? strlen(old) + 1 : 0;
 
-alloc -= len1 + len2;
+alloc = ebmalloc(len1 + len2);
 /*

[Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi.flags. This patch only defines
EFI_PLATFORM feature which is equal to old efi_enabled == 1.
Following patch will define EFI_LOADER feature accordingly.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|5 +
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   10 +-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |4 
 xen/common/efi/runtime.c   |   17 +++--
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |   12 ++--
 11 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index 8e07f8d..4cd38c8 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_PLATFORM)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -702,7 +702,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_PLATFORM) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..fdf0d8a 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_enabled(EFI_PLATFORM) && efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index e6c99b5..c5ae369 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,11 +4,8 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
-
 struct efi __read_mostly efi = {
+   .flags   = 0, /* Initialized later. */
.acpi= EFI_INVALID_TABLE_ADDR,
.acpi20  = EFI_INVALID_TABLE_ADDR,
.mps = EFI_INVALID_TABLE_ADDR,
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index ef6557c..ff26b5a 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -564,7 +564,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-   if (efi_enabled)
+   if (efi_enabled(EFI_PLATFORM))
clear_fixmap(FIX_EFI_MPF);
 }
 
@@ -722,7 +722,7 @@ void __init find_smp_config (void)
 {
unsigned int address;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_PLATFORM)) {
efi_check_config();
return;
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c5c332d..5d80868 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -434,8 +434,8 @@ static void __init parse_video_info(void)
 {
 struct boot_video_info *bvi = (boot_vid_info);
 
-/* The EFI loader fills vga_console_info directly. */
-if ( efi_enabled )
+/* vga_console_info is filled directly on EFI platform. */
+if ( efi_enabled(EFI_PLATFORM) )
 return;
 
 if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
@@ -715,7 +715,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( !(mbi->flags & MBI_MODULES) || (mbi->mods_count == 0) )
 panic("dom0 kernel not specified. Check bootloader configuration.");
 
-if ( efi_enabled )
+if ( efi_enabled(EFI_PLATFORM) )
 {
 set_pdx_range(xen_phys_start >> PAGE_SHIFT,
   

[Xen-devel] [PATCH v3 05/16] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/boot/head.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 28ac721..1ff5937 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -87,14 +87,14 @@ __start:
 jne not_multiboot
 
 /* Set up trampoline segment 64k below EBDA */
-movzwl  0x40e,%eax  /* EBDA segment */
-cmp $0xa000,%eax/* sanity check (high) */
+movzwl  0x40e,%ecx  /* EBDA segment */
+cmp $0xa000,%ecx/* sanity check (high) */
 jae 0f
-cmp $0x4000,%eax/* sanity check (low) */
+cmp $0x4000,%ecx/* sanity check (low) */
 jae 1f
 0:
-movzwl  0x413,%eax  /* use base memory size on failure */
-shl $10-4,%eax
+movzwl  0x413,%ecx  /* use base memory size on failure */
+shl $10-4,%ecx
 1:
 /*
  * Compare the value in the BDA with the information from the
@@ -106,20 +106,20 @@ __start:
 cmp $0x100,%edx /* is the multiboot value too small? */
 jb  2f  /* if so, do not use it */
 shl $10-4,%edx
-cmp %eax,%edx   /* compare with BDA value */
-cmovb   %edx,%eax   /* and use the smaller */
+cmp %ecx,%edx   /* compare with BDA value */
+cmovb   %edx,%ecx   /* and use the smaller */
 
 2:  /* Reserve 64kb for the trampoline */
-sub $0x1000,%eax
+sub $0x1000,%ecx
 
 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-xor %al, %al
-shl $4, %eax
-mov %eax,sym_phys(trampoline_phys)
+xor %cl, %cl
+shl $4, %ecx
+mov %ecx,sym_phys(trampoline_phys)
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%eax/* Boot trampoline address. */
+push%ecx/* Boot trampoline address. */
 push%ebx/* Multiboot information address. */
 callreloc
 add $8,%esp /* Remove reloc() args from stack. */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 14/16] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |7 +-
 xen/arch/x86/boot/build32.lds  |1 +
 xen/arch/x86/boot/build32.mk   |4 +-
 xen/arch/x86/boot/cmdline.S|  367 
 xen/arch/x86/boot/cmdline.c|  357 ++
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |   17 ++
 xen/arch/x86/boot/trampoline.S |   12 ++
 xen/arch/x86/boot/video.S  |6 -
 11 files changed, 400 insertions(+), 381 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c

diff --git a/.gitignore b/.gitignore
index 91f690c..6919546 100644
--- a/.gitignore
+++ b/.gitignore
@@ -237,9 +237,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 1bcb08b..32d2407 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -176,4 +176,4 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..d73cc76 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,14 @@
 obj-bin-y += head.o
 
+CMDLINE_DEPS = video.h
+
 RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
 $(BASEDIR)/include/xen/multiboot2.h
 
-head.o: reloc.S
+head.o: cmdline.S reloc.S
+
+cmdline.S: cmdline.c $(CMDLINE_DEPS)
+   $(MAKE) -f build32.mk $@ CMDLINE_DEPS="$(CMDLINE_DEPS)"
 
 reloc.S: reloc.c $(RELOC_DEPS)
$(MAKE) -f build32.mk $@ RELOC_DEPS="$(RELOC_DEPS)"
diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
index 47db9c4..6a234ea 100644
--- a/xen/arch/x86/boot/build32.lds
+++ b/xen/arch/x86/boot/build32.lds
@@ -25,6 +25,7 @@ SECTIONS
 *(.text)
 *(.text.*)
 *(.rodata)
+*(.rodata.*)
   }
 
   /DISCARD/ : {
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index eb02b4b..58e27e1 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -23,7 +23,7 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.bss|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
@@ -34,6 +34,8 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
 
+cmdline.o: cmdline.c $(CMDLINE_DEPS)
+
 reloc.o: reloc.c $(RELOC_DEPS)
 
 .PRECIOUS: %.bin %.lnk
diff --git a/xen/arch/x86/boot/cmdline.S b/xen/arch/x86/boot/cmdline.S
deleted file mode 100644
index 00687eb..000
--- a/xen/arch/x86/boot/cmdline.S
+++ /dev/null
@@ -1,367 +0,0 @@
-/**
- * cmdline.S
- *
- * Early command-line parsing.
- */
-
-.code32
-
-#include "video.h"
-
-# NB. String pointer on stack is modified to point 

[Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

[Daniel Kiper]

Speedup BSS initialization by using stosl instead of stosb.

Some may argue that Intel Ivy Bridge and later provide ERMSB feature.
This means that "rep stosb" gives better throughput than "rep stosl" on
above mentioned CPUs. However, this feature is only available on newer
Intel processors and e.g. AMD does not provide it at all. So, stosb will
just give real benefits and even beat stosl only on limited number of
machines. On the other hand stosl will speedup BSS initialization on
all x86 platforms. Hence, use stosl instead of stosb.

Additionally, align relevant comment to coding style.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S |5 +++--
 xen/arch/x86/xen.lds.S   |3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f3501fd..32a54a0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -123,12 +123,13 @@ __start:
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
 
-/* Initialize BSS (no nasty surprises!) */
+/* Initialize BSS (no nasty surprises!). */
 mov $sym_phys(__bss_start),%edi
 mov $sym_phys(__bss_end),%ecx
 sub %edi,%ecx
+shr $2,%ecx
 xor %eax,%eax
-rep stosb
+rep stosl
 
 /* Interrogate CPU extended features via CPUID. */
 mov $0x8000,%eax
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 961f48f..6802da1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -191,6 +191,8 @@ SECTIONS
CONSTRUCTORS
   } :text
 
+  /* Align BSS to speedup its initialization. */
+  . = ALIGN(4);
   .bss : { /* BSS */
. = ALIGN(STACK_SIZE);
__bss_start = .;
@@ -205,6 +207,7 @@ SECTIONS
*(.bss.percpu.read_mostly)
. = ALIGN(SMP_CACHE_BYTES);
__per_cpu_data_end = .;
+   . = ALIGN(4);
__bss_end = .;
   } :text
   _end = . ;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 16/16] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   46 +
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +++
 3 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e322270..dbf2555 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -79,6 +79,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offset(start), /* Min load address. */ \
+   0x, /* Max load address (4 GiB - 1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -178,30 +185,39 @@ efi_multiboot2_proto:
 and $~(MULTIBOOT2_TAG_ALIGN-1),%rcx
 
 0:
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%rcx)
+jne 1f
+
+mov MB2_load_base_addr(%rcx),%r15d
+sub $XEN_IMG_OFFSET,%r15
+jmp 4f
+
+1:
 /* Get EFI SystemTable address from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
-jne 1f
+jne 2f
 
 mov MB2_efi64_st(%rcx),%rsi
 
 /* Do not clear BSS twice and do not go into real mode. */
 movb$1,skip_realmode(%rip)
-jmp 3f
+jmp 4f
 
-1:
+2:
 /* Get EFI ImageHandle address from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
-jne 2f
+jne 3f
 
 mov MB2_efi64_ih(%rcx),%rdi
-jmp 3f
+jmp 4f
 
-2:
+3:
 /* Is it the end of Multiboot2 information? */
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
 je  run_bs
 
-3:
+4:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%rcx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%rcx
@@ -313,14 +329,23 @@ multiboot2_proto:
 and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
 
 0:
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne 1f
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp 3f
+
+1:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
-jne 1f
+jne 2f
 
 mov MB2_mem_lower(%ecx),%edx
-jmp trampoline_bios_setup
+jmp 3f
 
-1:
+2:
 /* EFI mode is not supported via legacy BIOS path. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
 je  mb2_too_old
@@ -332,6 +357,7 @@ multiboot2_proto:
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
 je  trampoline_bios_setup
 
+3:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%ecx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index b7aed49..d227f28 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -172,6 +172,7 @@ void __dummy__(void)
 DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 0f113f1..a1d355c 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 

[Xen-devel] [PATCH v3 13/16 - RFC] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v3 - not fixed yet:
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 should print error message and halt system.

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---
 xen/arch/x86/boot/head.S  |  177 +++--
 xen/arch/x86/efi/efi-boot.h   |   43 +
 xen/arch/x86/efi/stub.c   |5 ++
 xen/arch/x86/setup.c  |   10 ++-
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   12 +++
 xen/include/xen/efi.h |1 +
 8 files changed, 240 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e46d691..efb0614 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0  /* Number of bits per pixel - no preference. */
 
+/* Inhibit bootloader from calling ExitBootServices(). */
+mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+/* EFI64 entry point. */
+mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 multiboot2_header_end:
@@ -100,19 +107,29 @@ multiboot2_header_end:
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+.long   sym_phys(cs32_switch)
+.word   BOOT_CS32
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_mb2: .asciz "ERR: On EFI platform use latest Multiboot2 compatible 
bootloader!"
 
 .section .init.text, "ax", @progbits
 
 bad_cpu:
 mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
-jmp print_err
+mov $0xB8000,%edi   # VGA framebuffer
+jmp 1f
 not_multiboot:
 mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
-mov $0xB8000,%edi  # VGA framebuffer
+mov $0xB8000,%edi   # VGA framebuffer
+jmp 1f
+mb2_too_old:
+mov $(sym_phys(.Lbad_ldr_mb2)),%esi # Error message
+xor %edi,%edi   # No VGA framebuffer
 1:  mov (%esi),%bl
 test%bl,%bl# Terminate on '\0' sentinel
 je  .Lhalt
@@ -123,6 +140,8 @@ print_err:
 mov $0x3f8+0,%dx   # UART Transmit Holding Register
 mov %bl,%al
 out %al,%dx# Send a character over the serial line
+test%edi,%edi  # Is VGA framebuffer available?
+jz  1b
 movsb  # Write a character to the VGA framebuffer
 mov $7,%al
 stosb  # Write an attribute to the VGA framebuffer
@@ -130,6 +149,130 @@ print_err:
 .Lhalt: hlt
 jmp .Lhalt
 
+.code64
+
+__efi64_start:
+cld
+
+/* Check for Multiboot2 bootloader. */
+cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+je  efi_multiboot2_proto
+
+/* Jump to not_multiboot after switching CPU to x86_32 mode. */
+lea not_multiboot(%rip),%rdi
+jmp x86_32_switch
+
+efi_multiboot2_proto:
+/*
+ * Multiboot2 information address is 32-bit,
+ * so, zero higher half of %rbx.
+ */
+mov %ebx,%ebx
+
+/* Skip Multiboot2 information fixed part. */
+lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%rcx
+and $~(MULTIBOOT2_TAG_ALIGN-1),%rcx
+
+0:
+/* Get EFI SystemTable address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
+jne 1f
+
+mov MB2_efi64_st(%rcx),%rsi
+
+/* Do 

[Xen-devel] [PATCH v3 00/16] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending, long awaited, third version of multiboot2 protocol
support for legacy BIOS and EFI platforms. It fixes all major issues
discovered until now. There are still some minor problems which should
be fixed in one way or another. I will address them in next releases.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here are short list of changes:
  - new patches: 01, 07, 09,
  - changed patches: 02, 03, 04, 06, 08, 10, 11, 13, 14, 15, 16,
  - RFC patches: 12, 13, 15; if it is needed we could discuss at
least #12 and #15 at Xen Project Hackathon in Cambridge.

This patch series was build with following tools:
  - gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
and binutils 2.17-3+etch1,
  - gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
and binutils 2.23.2-2.el6,
  - gcc version 4.7.2 (Debian 4.7.2-5)
and binutils 2.22-8,
  - gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
and binutils 2.25-9.fc22.

I hope that starting from now there will be faster turnaround
of this patch series.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 .gitignore|5 +-
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |4 +
 xen/arch/x86/boot/Makefile|   10 +-
 xen/arch/x86/boot/build32.lds |   50 +
 xen/arch/x86/boot/build32.mk  |   14 ++-
 xen/arch/x86/boot/cmdline.S   |  367 
--
 xen/arch/x86/boot/cmdline.c   |  357 
+
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  481 
+-
 xen/arch/x86/boot/reloc.c |  246 
+++---
 xen/arch/x86/boot/trampoline.S|   18 +++-
 xen/arch/x86/boot/video.S |6 --
 xen/arch/x86/boot/wakeup.S|6 +-
 xen/arch/x86/boot/x86_64.S|   44 +++-
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   11 +-
 xen/arch/x86/efi/efi-boot.h   |   81 --
 xen/arch/x86/efi/stub.c   |   16 ++-
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   61 ++-
 xen/arch/x86/shutdown.c   |2 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   10 ++
 xen/arch/x86/xen.lds.S|7 +-
 xen/common/efi/boot.c |   19 
 xen/common/efi/runtime.c  |   23 ++--
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/config.h  |1 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |   13 ++-
 xen/include/xen/multiboot2.h  |  182 +++
 33 files changed, 1491 insertions(+), 570 deletions(-)

Daniel Kiper (16):
  x86/boot: do not create unwind tables
  x86: zero BSS using stosl instead of stosb
  x86/boot: call reloc() using cdecl calling convention
  x86/boot/reloc: create generic alloc and copy functions
  x86/boot: use %ecx instead of %eax
  x86/boot/reloc: Rename some variables and rearrange code a bit
  x86/boot: create *.lnk files with linker script
  x86: add multiboot2 protocol support
  efi: explicitly define efi struct in xen/arch/x86/efi/stub.c
  efi: create efi_enabled()
  efi: build xen.gz with EFI code
  x86/efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: make Xen early boot code relocatable
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v3 04/16] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v3 - suggestions/fixes:
   - use "g" constraint instead of "r" for alloc_mem() bytes argument
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generalize new functions names
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   59 -
 1 file changed, 37 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 006f41d..d60a078 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -43,9 +43,10 @@ asm (
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_mem(u32 bytes)
 {
-void *new;
+u32 s;
+
 asm(
 "call 1f  \n"
 "1:  pop  %%edx   \n"
@@ -53,50 +54,64 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
 "sub  %1,%0   \n"
 "and  $~15,%0 \n"
 "mov  %0,alloc-1b(%%edx)  \n"
-"mov  %0,%%edi\n"
-"rep  movsb   \n"
-   : "=" (new), "+c" (bytes), "+S" (old)
-   : : "edx", "edi", "memory");
-return new;
+   : "=" (s) : "g" (bytes) : "edx", "memory");
+
+return s;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_mem(u32 src, u32 bytes)
 {
-char *p;
-for ( p = old; *p != '\0'; p++ )
+u32 dst, dst_asm;
+
+dst = alloc_mem(bytes);
+dst_asm = dst;
+
+asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : 
"memory");
+
+return dst;
+}
+
+static u32 copy_string(u32 src)
+{
+u32 p;
+
+if ( src == 0 )
+return 0;
+
+for ( p = src; *(char *)p != '\0'; p++ )
 continue;
-return reloc_mbi_struct(old, p - old + 1);
+
+return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+multiboot_info_t *reloc(u32 mbi_old)
 {
-multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+multiboot_info_t *mbi = (multiboot_info_t *)copy_mem(mbi_old, 
sizeof(*mbi));
 int i;
 
 if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+mbi->cmdline = copy_string(mbi->cmdline);
 
 if ( mbi->flags & MBI_MODULES )
 {
-module_t *mods = reloc_mbi_struct(
-(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+module_t *mods;
 
-mbi->mods_addr = (u32)mods;
+mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+
+mods = (module_t *)mbi->mods_addr;
 
 for ( i = 0; i < mbi->mods_count; i++ )
 {
 if ( mods[i].string )
-mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+mods[i].string = copy_string(mods[i].string);
 }
 }
 
 if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = (u32)reloc_mbi_struct(
-(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
 
 if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = (u32)reloc_mbi_string(
-(char *)mbi->boot_loader_name);
+mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does
some code optimizations by creating data sections (e.g. jump addresses
for C switch/case are calculated using data in .rodata section). This
thing is not accepted by *.lnk build recipe which requires that only .text
section lives in output. Potentially we can inhibit this GCC behavior by
using special options, e.g. -fno-tree-switch-conversion. However, this
does not guarantee that in the future new similar optimizations or anything
which creates not accepted sections will not break our build recipes again.
Additionally, I do not mention that probably this is not good idea to just
disable random optimizations. So, take over full control on *.lnk linking
process by using linker script and merge all text and data sections into
one .text section.

Additionally, remove .got.plt section which is not used in our final code.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/build32.lds |   49 +
 xen/arch/x86/boot/build32.mk  |   10 ++---
 2 files changed, 56 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/boot/build32.lds

diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
new file mode 100644
index 000..47db9c4
--- /dev/null
+++ b/xen/arch/x86/boot/build32.lds
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *  Daniel Kiper 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+ENTRY(_start)
+
+SECTIONS
+{
+  /* Merge code and data into one section. */
+  .text : {
+*(.text)
+*(.text.*)
+*(.rodata)
+  }
+
+  /DISCARD/ : {
+/*
+ * .got.plt section is used only by dynamic linker
+ * and our output is not supposed to be loaded by
+ * dynamic linker. Additionally, it just contains
+ * .PLT0 which is referenced from nowhere. So, we
+ * can safely drop .got.plt here.
+ *
+ * Ha! This should be really discarded here. However,
+ * .got.plt section contains _GLOBAL_OFFSET_TABLE_
+ * symbol too and it is used as a reference for relative
+ * addressing (and only for that thing). Hence, ld
+ * complains if we remove that section because it
+ * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
+ * section during conversion to plain binary format.
+ * Please check build32.mk for more details.
+ */
+/* *(.got.plt) */
+  }
+}
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a7d388..eb02b4b 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -12,20 +12,24 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
(od -v -t x $< | tr -s ' ' | awk 'NR > 1 {print s} {s=$$0}' | \
sed 's/ /,0x/g' | sed 's/,0x$$//' | sed 's/^[0-9]*,/ .long /') >$@
 
+#
+# Drop .got.plt during conversion to plain binary format.
+# Please check build32.lds for more details.
+#
 %.bin: %.lnk
-   $(OBJCOPY) -O binary $< $@
+   $(OBJCOPY) -O binary -R .got.plt $< $@
 
 %.lnk: %.o
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.rodata.*|.bss|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
esac; \
done
-   $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<
+   $(LD) $(LDFLAGS_DIRECT) -N -T build32.lds -o $@ $<
 
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

[Daniel Kiper]

reloc() is not called according to cdecl calling convention.
This makes confusion and does not scale well for more arguments.
And patch adding multiboot2 protocol support have to pass 3
arguments instead of 2. Hence, move reloc() call to cdecl
calling convention.

I add push %ebp/mov %esp,%ebp/leave instructions here. Though they
are not strictly needed in this patch. However, then assembly code
in patch adding multiboot2 protocol support is easier to read.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - simplify assembly in xen/arch/x86/boot/reloc.c file
 (suggested by Jan Beulich),
   - reorder arguments for reloc() call from xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |4 +++-
 xen/arch/x86/boot/reloc.c |   18 ++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 32a54a0..28ac721 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -119,8 +119,10 @@ __start:
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%ebx
+push%eax/* Boot trampoline address. */
+push%ebx/* Multiboot information address. */
 callreloc
+add $8,%esp /* Remove reloc() args from stack. */
 mov %eax,sym_phys(multiboot_ptr)
 
 /* Initialize BSS (no nasty surprises!). */
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..006f41d 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,15 +10,25 @@
  *Keir Fraser 
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
+ */
 asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
+"push %ebp \n"
+"mov  %esp,%ebp\n"
 "call 1f   \n"
-"1:  pop  %ebx \n"
-"mov  %eax,alloc-1b(%ebx)  \n"
-"jmp  reloc\n"
+"1:  pop  %ecx \n"
+"mov  0xc(%ebp),%eax   \n"
+"mov  %eax,alloc-1b(%ecx)  \n"
+"push 0x8(%ebp)\n"
+"call reloc\n"
+"leave \n"
+"ret   \n"
 );
 
 /*
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

Existing solution does not allocate space for this symbol and any
references to acpi20, etc. does not make sense. As I saw any efi.*
references are protected by relevant ifs but we should not do that
because it makes code very fragile. If somebody does not know how
efi symbol is created he/she may assume that it always represent
valid structure and do invalid references somewhere.

Additionally, following 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,
define efi struct in xen/arch/x86/efi/stub.c and remove efi
symbol from ld script.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/efi/stub.c |8 
 xen/arch/x86/xen.lds.S  |2 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..e6c99b5 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -8,6 +8,14 @@
 const bool_t efi_enabled = 0;
 #endif
 
+struct efi __read_mostly efi = {
+   .acpi= EFI_INVALID_TABLE_ADDR,
+   .acpi20  = EFI_INVALID_TABLE_ADDR,
+   .mps = EFI_INVALID_TABLE_ADDR,
+   .smbios  = EFI_INVALID_TABLE_ADDR,
+   .smbios3 = EFI_INVALID_TABLE_ADDR
+};
+
 void __init efi_init_memory(void) { }
 
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { }
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6802da1..6376bfa 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -227,8 +227,6 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
   /* Sections to be discarded */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 01/16] x86/boot: do not create unwind tables

[Daniel Kiper]

This way .eh_frame section is not included in *.lnk and *.bin files.
Hence, final e.g. reloc.bin file size is reduced from 408 bytes to
272 bytes and it contains only used code and data.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/build32.mk |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a1421f..4a7d388 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/Config.mk
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS += -Werror -fno-builtin -msoft-float
+CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -msoft-float
 CFLAGS := $(filter-out -flto,$(CFLAGS)) 
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-- 
1.7.10.4


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-pair23 guest-stop/src_host   fail REGR. vs. 60684
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-libvirt-xsm  14 guest-saverestorefail   like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684

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-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux3ecf481f3d473010d0958f7a5a052a2bf4eb1a37
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  246 days
Failing since 60712  2015-08-15 18:33:48 Z  243 days  184 attempts
Testing same since91379  2016-04-14 09:51:21 Z1 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross]

On 15/04/16 12:58, Dario Faggioli wrote:
> On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
>> On 15/04/16 12:20, Ian Jackson wrote:
>>>
>>> Would either of you care to provide a version of my documentation
>>> patch
>>> which answers the questions that my text answers ?  Or shall we
>>> commit
>>> my version and you can edit it in-tree :-).
>> I can provide an updated patch.
>>
> Great.
> 
>>> All I need now is a recipe for the tools to tell what has happened
>>> and
>>> then I can make xl or libxl at least print comprehensible and
>>> correct
>>> error messages...
>> So this boils down to finding an appropriate ESOMETHING replacement
>> for the EBUSY case introduced by the temporary pinning.
>>
> Exactly.
> 
>> I think ENOTEMPTY or EADDRINUSE would fit best.
>>
> I like the latter better.
>>
>> The EBUSY returns of not successful repair attempts (trying to assign
>> a
>> cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?
>>
> I'd go for EADDRINUSE and EADDRNOTAVAIL so the two error values are
> similarly *wrong* hinting an addressing issue, which is more consistent
> (and would come handy when documenting) than having one pointing at the
> filesystem and the other at the address space.
> 
> Are you going to do the patch for this yourself as well?

Sure.


Juergen


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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[George Dunlap]

On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich  wrote:
>>Sure, mistakes happen; but I hope it's not being to controversial to
>>say that in general, the procedure should be arranged such that the
>>person who makes the mistake is the one who has to do deal with the
>>most consequences from the mistake, not the people around him.  I
>>mean, if you asked a bartender for a bottle of beer, and after he'd
>>already opened it you said, "Oh sorry, I actually wanted a cider", it
>>would be fair enough for the bartender to ask you to pay for the beer,
>>rather than eating it*, wouldn't it? :-)
>
> Sure. And I think that's what I've done. I suggested to revert the thing,
> collecting opinions either direction. I just didn't post a revert patch, as I
> think that makes little sense - a revert is a mechanical operation, which
> doesn't need people looking at the actual patch.

You don't need people to review the content of the actual patch, but
it provides a standardized way to have a discussion about the patch,
and it makes it clear what the procedure is for having it applied.
You don't need any technical code review for adding or removing
maintainers either, but we ask people to send patches to the
MAINTAINERS file anyway, because it provides a structured way to have
an open discussion and make a decision.

When Konrad asked for further input on the patch and then didn't get
any in a few days, you responded, "It looks like it will have to be
reverted then." As I've said, I think that's the wrong way round --
it's not that the commit is reverted unless someone else acks it; it's
that the commit stays unless someone acks your reversion.  If you had
posted a patch (probably RFC) requesting to revert the change in favor
of a different one, then it would have been more obvious that the
burden was on you to get the reversion Acked, rather than on Konrad to
get the existing commit re-acked.

>>Well Ian and I have already given our opinions -- Ian thinks moving to
>>a clean interface and deprecating the old one is in general a good
>>thing, and doesn't look too painful in this case.  I don't really see
>>a problem with using a large fixed size, but I don't fundamentally see
>>a problem with moving to a new clean interface either.  Given that
>>Andy has a strong aversion to the way things are, if you had only a
>>mild distaste rather than a  strong objection to the new hypercall, it
>>would probably make sense to go with the new hypercall.
>>
>>If you do have a strong objection, then maybe we could try to convince
>>Andy to accept adding subops with different calling semantics to the
>>existing hypercall.  But I would still think the burden of persuasion
>>is primarily on you.
>
>  I do not have a strong objection, or else I would have converted my ack
> into a nak instead of just withdrawing it. I just dislike the duplication, and
> hence I'm not happy with me now being the one having approved it to go
> in. Hence the request for a replacement ack (or whatever else referee
> decision).

Well this makes it sound like you're saying that you were asking us to
save you from having to appear to have approved of a patch that you
didn't like.  Which doesn't sound very nice. :-)

But I wonder if something slightly different is going on.  Forgive me
for trying to guess at motivations here, but I think it may be
helpful.  I'm often in the situation where my gut objects to a patch
that other coders I respect think is fine; and often a few years down
the road, I look back and agree that it's fine as well.  In other
words, I know that sometimes my own objections turn out to be
unreasonable; and that in any case, working with other people you
sometimes have to compromise.  But on the other hand, I've also had
the experience of giving in and accepting patches that later I regret,
or that other people come back and say, "This was a terrible idea, you
should have stood up for it more."

So in the moment -- particularly, as you say, under time pressure --
how do you determine if objecting to the patch is being unreasonable
and obstructive, or if assenting to the patch is failing your duty as
a maintainer to prevent bad code, and is a decision you'll regret
later?

Was it perhaps actually the case that your internal reasoning was
along the lines of, "Actually, adding a new hypercall seems like a bad
idea.  But since Andrew strongly disagrees, maybe I'm being
unreasonable.  Or, maybe it really is a bad idea and he's being
unreasonable.  Why don't I ask the REST maintainers to look at it; if
they Ack it, then I'm probably being too conservative; if they don't,
then I'm probably justified in objecting to it"?

If so, we should probably find a better way for maintainers to ask for
additional feedback in those situations. :-)  I'd certainly appreciate
that at times.

If that's not the case, and you genuinely only have a mild dislike for
the hypercall, then there are a couple of things to say about that.
The first is that given 

Re: [Xen-devel] [PATCH for-4.7] hotplug/Linux: fix same_vm check in block script

[Ian Jackson]

Wei Liu writes ("Re: [PATCH for-4.7] hotplug/Linux: fix same_vm check in block 
script"):
> Release-acked-by: Wei Liu 

Queued, thanks.

Ian.

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

Re: [Xen-devel] [PATCH for-4.7] tools/libxl: Fix legacy migration following COLO backchannel breakage

[Ian Jackson]

Wei Liu writes ("Re: [PATCH for-4.7] tools/libxl: Fix legacy migration 
following COLO backchannel breakage"):
> Release-acked-by: Wei Liu 
> 
> Thank you for fixing this.

Indeed, thanks everyone.  Queued.

Ian.

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

Re: [Xen-devel] [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2] xen: change the sizes of memory fields in the 
HVM start info to be 64bits"):
> On Wed, Apr 13, 2016 at 10:15:32PM -0600, Jan Beulich wrote:
>>> Roger Pau Monne  04/12/16 6:12 PM >>>
> > >At the moment the only consumer of this structure is x86, but other arches
> > >might also use it, so make all the fields 64bits. On x86 Xen will still try
> > >to place everything below the 4GiB boundary, but that might not be feasible
> > >in other arches.
> > >
> > >Signed-off-by: Roger Pau Monné 
> > >Requested-by: Jan Beulich 
> > 
> > Acked-by: Jan Beulich 
> 
> Release-acked-by: Wei Liu 

Queued, thanks.

Ian.

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