[Xen-devel] [ovmf test] 129928: regressions - FAIL
flight 129928 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129928/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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 build-i386-libvirt1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 43 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days8 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 129762: tolerable FAIL - PUSHED
flight 129762 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129762/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 6 xen-install fail like 129492 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux0b047cbc44ae7d0cea41a99cd7ec1f009360a605 baseline version: linux50961e4888a1d53544ac4ea6f185fc27ee4fee4f Last test of basis 129492 2018-11-06 04:59:11 Z7 days Testing same since 129762 2018-11-10 16:18:46 Z2 days1 attempts People who touched revisions under test: Al Viro Alan Chiang Alan Stern Alexei Starovoitov Amir Goldstein Andy Yeh Bartosz Golaszewski Brian Foster Chen Yu Christophe Leroy Clint Taylor Dan Williams Daniel Borkmann Daniel Vetter Darrick J. Wong David Howells David S. Miller Dmitry Torokhov Doug Ledford Edward Cree Eric Dumazet Eugeniy Paltsev
[Xen-devel] [ovmf test] 129923: regressions - FAIL
flight 129923 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129923/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 42 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days7 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-amd
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemuu-rhel6hvm-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 24ccea7e102de8cbc93ab3befb123bbd18532be9 Bug not present: 58a0228707870c8330917f919804986855443a19 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129922/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot --summary-out=tmp/129922.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-qemuu-rhel6hvm-amd xen-boot Searching for failure / basis pass: 129680 fail [host=pinot0] / 128945 ok. Failure / basis pass flights: 129680 / 128945 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be Basis pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 92666fdd6e0afab989b2d89759d9b43f2c645ae7 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#58a0228707870c8330917f919804986855443a19-24ccea7e102de8cbc93ab3befb123bbd18532be9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#92666fdd6e0afab989b2d89759d9b43f2c645ae7-2cf113891a38cc05434bc9876ffc107a990887be adhoc-revtuple-generator: tree discontiguous: linux-2.6 Loaded 2005 nodes in revision graph Searching for test results: 128663 pass irrelevant 128727 pass irrelevant 128861 pass irrelevant 128835 pass irrelevant 128885 pass irrelevant 128920 pass irrelevant 128945 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 92666fdd6e0afab989b2d89759d9b43f2c645ae7 128970 fail irrelevant 129005 fail irrelevant 129072 fail irrelevant 129167 fail irrelevant 129258 fail irrelevant 129304 fail irrelevant 129389 fail irrelevant 129348 fail irrelevant 129417 fail irrelevant 129530 fail irrelevant 129460 fail irrelevant 129680 fail 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be 129872 fail 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be 129890 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 b72624aad5b00f2f6e976aef4d62eeda83fd0218 129868 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 92666fdd6e0afab989b2d89759d9b43f2c645ae7 129881 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 c238ea3f4caccf36ab1a559f958cbe5192327f6a 129878 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
[Xen-devel] [xen-unstable-smoke test] 129916: regressions - FAIL
flight 129916 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129852
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen b7ae5c33e6b0c5849de9916bd4b15561be43b690
baseline version:
xen 94bd9df0f7efad8038d99ec52ba56ecec4191248
Last test of basis 129852 2018-11-12 16:00:37 Z0 days
Failing since129861 2018-11-12 19:00:52 Z0 days5 attempts
Testing same since 129870 2018-11-12 21:00:23 Z0 days4 attempts
People who touched revisions under test:
Andrew Cooper
Daniel De Graaf
Jan Beulich
Roger Pau Monné
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit b7ae5c33e6b0c5849de9916bd4b15561be43b690
Author: Andrew Cooper
Date: Fri Nov 9 13:46:27 2018 +
x86/badpage: Fix badpage->order overflow
For order 32 or more, the shift will truncate before the addition occurs.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf
Date: Fri Nov 2 13:46:11 2018 -0400
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
Acked-by: Andrew Cooper
commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper
Date: Thu Oct 18 11:30:27 2018 +0100
x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
NX support in the host is required for the shadow pagetable code to handle
SMAP correctly for guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper
Date: Thu Jul 19 16:51:57 2018 +0100
tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné
Date: Mon Nov 12 17:14:57 2018 +0100
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the
[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-examine
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-examine
testid reboot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: 7b8052e19304865477e03a0047062d977309a22f
Bug not present: d255d18a34a8d53ccc4a019dc07e17b6e8cf6bd1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129921/
commit 7b8052e19304865477e03a0047062d977309a22f
Author: Jan Beulich
Date: Mon Oct 19 04:23:29 2015 -0600
igb: fix NULL derefs due to skipped SR-IOV enabling
[ Upstream commit be06998f96ecb93938ad2cce46c4289bf7cf45bc ]
The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV
during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the
right number of queues") causes VFs no longer getting set up, leading
to NULL pointer dereferences due to the adapter's ->vf_data being NULL
while ->vfs_allocated_count is non-zero. The first commit not only
neglected the side effect of igb_sriov_reinit() that the second commit
tried to account for, but also that of setting IGB_FLAG_HAS_MSIX,
without which igb_enable_sriov() is effectively a no-op. Calling
igb_{,re}set_interrupt_capability() as done here seems to address this,
but I'm not sure whether this is better than sinply reverting the other
two commits.
Signed-off-by: Jan Beulich
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-examine.reboot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-examine.reboot
--summary-out=tmp/129921.bisection-summary --basis-template=128858
--blessings=real,real-bisect linux-3.18 test-amd64-i386-examine reboot
Searching for failure / basis pass:
129760 fail [host=debina0] / 128858 [host=albana1] 128841 [host=chardonnay0]
128807 [host=albana0] 128691 [host=elbling0] 128258 [host=rimava1] 128232
[host=pinot0] 128177 [host=debina1] 128096 [host=albana1] 127486 [host=debina1]
127472 [host=huxelrebe1] 127455 [host=chardonnay1] 127296 [host=baroque0]
127001 [host=elbling0] 126926 ok.
Failure / basis pass flights: 129760 / 126926
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 78e0897dd8b321ba1b4a2137778ab7ae7d400af5
c530a75c1e6a472b0eb9558310b518f0dfcd8860
d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
2cf113891a38cc05434bc9876ffc107a990887be
Basis pass a5f9be3576c3f9dd871f68eaf482278c0b3a6df2
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
4f080070a9809bde857851e68a3aeff0c4b9b6a6
a923919797c39d51ea0b808ea691bed20fe8e072
Generating revisions with ./adhoc-revtuple-generator
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#a5f9be3576c3f9dd871f68eaf482278c0b3a6df2-78e0897dd8b321ba1b4a2137778ab7ae7d400af5
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798
git://xenbits.xen.org/qemu-xen.git#4f080070a9809bde857851e68a3aeff0c4b9b6a6-de5b678ca4dcdfa83e322491d478d66df56c1986
git://xenbits.xen.org/xen.git#a923919797c39d51ea0b808ea691bed20fe8e072-2cf113891a38cc05434bc9876ffc107a990887be
Loaded 7018 nodes in revision graph
Searching for test results:
126926 pass a5f9be3576c3f9dd871f68eaf482278c0b3a6df2
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
4f080070a9809bde857851e68a3aeff0c4b9b6a6
a923919797c39d51ea0b808ea691bed20fe8e072
127001 [host=elbling0]
127296 [host=baroque0]
127486 [host=debina1]
127472 [host=huxelrebe1]
127455 [host=chardonnay1]
128096 [host=albana1]
128177 [host=debina1]
128232 [host=pinot0]
128258 [host=rimava1]
128691 [host=elbling0]
128807 [host=albana0]
128858 [host=albana1]
128841 [host=chardonnay0]
129760 fail
[Xen-devel] [ovmf test] 129918: regressions - FAIL
flight 129918 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129918/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 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 build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 41 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days6 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129912: regressions - FAIL
flight 129912 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129912/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 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 da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 40 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days5 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129909: regressions - FAIL
flight 129909 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129909/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129852
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen b7ae5c33e6b0c5849de9916bd4b15561be43b690
baseline version:
xen 94bd9df0f7efad8038d99ec52ba56ecec4191248
Last test of basis 129852 2018-11-12 16:00:37 Z0 days
Failing since129861 2018-11-12 19:00:52 Z0 days4 attempts
Testing same since 129870 2018-11-12 21:00:23 Z0 days3 attempts
People who touched revisions under test:
Andrew Cooper
Daniel De Graaf
Jan Beulich
Roger Pau Monné
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit b7ae5c33e6b0c5849de9916bd4b15561be43b690
Author: Andrew Cooper
Date: Fri Nov 9 13:46:27 2018 +
x86/badpage: Fix badpage->order overflow
For order 32 or more, the shift will truncate before the addition occurs.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf
Date: Fri Nov 2 13:46:11 2018 -0400
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
Acked-by: Andrew Cooper
commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper
Date: Thu Oct 18 11:30:27 2018 +0100
x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
NX support in the host is required for the shadow pagetable code to handle
SMAP correctly for guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper
Date: Thu Jul 19 16:51:57 2018 +0100
tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné
Date: Mon Nov 12 17:14:57 2018 +0100
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the
[Xen-devel] [ovmf test] 129905: regressions - FAIL
flight 129905 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 39 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days4 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129900: regressions - FAIL
flight 129900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129900/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129852
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen b7ae5c33e6b0c5849de9916bd4b15561be43b690
baseline version:
xen 94bd9df0f7efad8038d99ec52ba56ecec4191248
Last test of basis 129852 2018-11-12 16:00:37 Z0 days
Failing since129861 2018-11-12 19:00:52 Z0 days3 attempts
Testing same since 129870 2018-11-12 21:00:23 Z0 days2 attempts
People who touched revisions under test:
Andrew Cooper
Daniel De Graaf
Jan Beulich
Roger Pau Monné
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit b7ae5c33e6b0c5849de9916bd4b15561be43b690
Author: Andrew Cooper
Date: Fri Nov 9 13:46:27 2018 +
x86/badpage: Fix badpage->order overflow
For order 32 or more, the shift will truncate before the addition occurs.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf
Date: Fri Nov 2 13:46:11 2018 -0400
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
Acked-by: Andrew Cooper
commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper
Date: Thu Oct 18 11:30:27 2018 +0100
x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
NX support in the host is required for the shadow pagetable code to handle
SMAP correctly for guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper
Date: Thu Jul 19 16:51:57 2018 +0100
tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné
Date: Mon Nov 12 17:14:57 2018 +0100
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the
Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen
On Mon, 12 Nov 2018, Julien Grall wrote: > Hi Mirela, > > Thank you for posting the series. Could you provide a branch with the patch > applied? > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > > > > > The series does not include: > > a) UART driver-specific suspend/resume that gets called when console > > suspends > > I feel it will be difficult to test this series without UART driver support. > Would it be possible to integrate them in that series? Actually, you can test this series simply using upstream Linux and upstream Xen + this series. You can use echo mem > /sys/power/state in dom0 to go into suspend, and for example setup an RTC wakeup event to wakeup after a certain amount of time. For instance echo +30 > /sys/class/rtc/rtc0/wakealarm. For the Xilinx MPSoC, Linux 4.19 works fine with defconfig. Linux 4.20 (current master) gained EEMI support, but I tested it and it seems to suspend successfully even if Xen doesn't know how to handle the EEMI calls that Linux makes when suspending. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129902: regressions - FAIL
flight 129902 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129902/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 38 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days3 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
On Mon, 12 Nov 2018, Andrew Cooper wrote: > On 12/11/18 16:35, Mirela Simonovic wrote: > > Hi Julien, > > > > Thanks for your feedback, I'll need to answer in iterations. > > > > On Mon, Nov 12, 2018 at 4:27 PM Julien Grall wrote: > >> Hi Mirela, > >> > >> On 11/12/18 11:30 AM, Mirela Simonovic wrote: > >>> The implementation consists of: > >>> -Adding PSCI system suspend call as new PSCI function > >>> -Trapping PSCI system_suspend HVC > >>> -Implementing PSCI system suspend call (virtual interface that allows > >>> guests to suspend themselves) > >>> > >>> The PSCI system suspend should be called by a guest from its boot > >>> VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI > >>> CPU_OFF call prior to issuing PSCI system suspend. Interrupts that > >>> are left enabled by the guest are assumed to be its wake-up interrupts. > >>> Therefore, a wake-up interrupt triggers the resume of the guest. Guest > >>> should resume regardless of the state of Xen (suspended or not). > >>> > >>> When a guest calls PSCI system suspend the respective domain will be > >>> suspended if the following conditions are met: > >>> 1) Given resume entry point is not invalid > >>> 2) Other (if any) VCPUs of the calling guest are hot-unplugged > >>> > >>> If the conditions above are met the calling domain is labeled as > >>> suspended and the calling VCPU is blocked. If nothing else wouldn't > >>> be done the suspended domain would resume from the place where it > >>> called PSCI system suspend. This is expected if processing of the PSCI > >>> system suspend call fails. However, in the case of success the calling > >>> guest should resume (continue execution after the wake-up) from the entry > >>> point which is given as the first argument of the PSCI system suspend > >>> call. In addition to the entry point, the guest expects to start within > >>> the environment whose state matches the state after reset. This means > >>> that the guest should find reset register values, MMU disabled, etc. > >>> Thereby, the context of VCPU should be 'reset' (as if the system is > >>> comming out of reset), the program counter should contain entry point, > >>> which is 1st argument, and r0/x0 should contain context ID which is 2nd > >>> argument of PSCI system suspend call. The context of VCPU is set > >>> accordingly when the PSCI system suspend is processed, so that nothing > >>> needs to be done on resume/wake-up path. However, in order to ensure that > >>> this context doesn't get overwritten by the scheduler when scheduling out > >>> this VCPU (would normally happen after the calling CPU is blocked), we > >>> need > >>> to check whether to return early from ctxt_switch_from(). > >>> > >>> There are variables in domain structure to keep track of domain shutdown. > >>> One of existing shutdown reason is 'suspend' which this patch is using to > >>> track the suspend state of a domain. Those variables are used to determine > >>> whether to early return from ctxt_switch_from() or not. > >>> > >>> A suspended domain will resume after the Xen receives an interrupt which > >>> is > >>> targeted to the domain, unblocks the domain's VCPU, and schedules it in. > >>> When the VCPU is scheduled in, the VCPU context is already reset, and > >>> contains the right resume entry point in program counter that will be > >>> restored in ctxt_switch_to(). The only thing that needs to be done at this > >>> point is to clear the variables that marked the domain state as suspended. > >>> > >>> Signed-off-by: Mirela Simonovic > >>> Signed-off-by: Saeed Nowshadi > >>> > >>> --- > >>> Changes in v2: > >>> > >>> -Fix print to compile for arm32 and to align with Xen coding style > >>> --- > >>> xen/arch/arm/Makefile| 1 + > >>> xen/arch/arm/domain.c| 13 +++ > >>> xen/arch/arm/suspend.c | 166 > >>> +++ > >>> xen/arch/arm/vpsci.c | 19 + > >>> xen/include/asm-arm/perfc_defn.h | 1 + > >>> xen/include/asm-arm/psci.h | 2 + > >>> xen/include/asm-arm/suspend.h| 16 > >>> xen/include/xen/sched.h | 1 + > >>> 8 files changed, 219 insertions(+) > >>> create mode 100644 xen/arch/arm/suspend.c > >>> create mode 100644 xen/include/asm-arm/suspend.h > >>> > >>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > >>> index 23c5d9adbc..744b1a4dc8 100644 > >>> --- a/xen/arch/arm/Makefile > >>> +++ b/xen/arch/arm/Makefile > >>> @@ -43,6 +43,7 @@ obj-y += setup.o > >>> obj-y += shutdown.o > >>> obj-y += smp.o > >>> obj-y += smpboot.o > >>> +obj-y += suspend.o > >>> obj-y += sysctl.o > >>> obj-y += time.o > >>> obj-y += traps.o > >>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > >>> index e594b48d81..7f8105465c 100644 > >>> --- a/xen/arch/arm/domain.c > >>> +++ b/xen/arch/arm/domain.c > >>> @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) > >>> if ( is_idle_vcpu(p) ) >
[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict testid debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: ce2f42605888f18f63ff9fe0d45dd69ae83045bb Bug not present: 371a23e65db5eb3a80a148586aeb551d4d0015f1 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129897/ commit ce2f42605888f18f63ff9fe0d45dd69ae83045bb Author: George Dunlap Date: Tue Nov 6 15:41:25 2018 + tools/dm_depriv: Add first cut RLIMITs Limit the ability of a potentially compromised QEMU to consume system resources. Key limits: - RLIMIT_FSIZE (file size): 256KiB - RLIMIT_NPROC (after uid changes to a unique uid) Probably unnecessary limits but why not: - RLIMIT_CORE: 0 - RLIMIT_MSGQUEUE: 0 - RLIMIT_LOCKS: 0 - RLIMIT_MEMLOCK: 0 NB that we do not yet set RLIMIT_AS (total virtual memory) or RLIMIT_NOFILES (number of open files), since these require more care and/or more coordination with QEMU to implement. Suggested-by: Ross Lagerwall Signed-off-by: George Dunlap Acked-by: Ian Jackson --- Changes since v4: - Put global headers before local headers (sugg by Paul) - Move #undif inside the braces (sugg by Paul) Changes since v3: - Align RLIMIT_ENTRY list for easier reading - Fix wrong format string specifier - Get rid of some trailing whitespace Changes since v2: - Use a macro to define rlimit entries - Use RLIMIT_NLIMITS as an end-of-list marker, rather than -1 - Various style clean-ups CC: Ian Jackson CC: Wei Liu CC: Anthony Perard For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict.debian-hvm-install.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict.debian-hvm-install --summary-out=tmp/129897.bisection-summary --basis-template=129426 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict debian-hvm-install Searching for failure / basis pass: 129738 fail [host=debina1] / 129426 [host=debina0] 129400 [host=elbling0] 129369 [host=rimava1] 129319 [host=huxelrebe1] 129278 [host=fiano0] 129209 [host=huxelrebe0] 129138 [host=albana0] 129104 [host=joubertin0] 129074 [host=elbling1] 129010 [host=pinot1] 128972 [host=albana1] 128949 ok. Failure / basis pass flights: 129738 / 128949 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 50961e4888a1d53544ac4ea6f185fc27ee4fee4f c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 6d8ffac1f7a782dc2c7f8df3871a294729ae36bd Basis pass e7405910ca5553eae8744af4e5c03e64ee048cb1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 072e054359a4d4a4f6c3fa09585667472c4f0f1d Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#e7405910ca5553eae8744af4e5c03e64ee048cb1-50961e4888a1d53544ac4ea6f185fc27ee4fee4f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#072e054359a4d4a4f6c3fa09585667472c4f0f1d-6d8ffac1f7a782dc2c7f8df3871a294729ae36bd Loaded 3004 nodes in revision graph Searching for test results: 128949 pass e7405910ca5553eae8744af4e5c03e64ee048cb1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 072e054359a4d4a4f6c3fa09585667472c4f0f1d 129010 [host=pinot1] 128972 [host=albana1] 129074 [host=elbling1] 129104 [host=joubertin0] 129138 [host=albana0] 129209
Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume
On Mon, 12 Nov 2018, Julien Grall wrote: > Hi, > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > The MMU needs to be enabled in the resume flow before the context > > can be restored (we need to be able to access the context data by > > virtual address in order to restore it). The configuration of system > > registers prior to branching to the routine that sets up the page > > tables is copied from xen/arch/arm/arm64/head.S. > > After the MMU is enabled, the content of TTBR0_EL2 is changed to > > point to init_ttbr (page tables used at runtime). > > > > At boot the init_ttbr variable is updated when a secondary CPU is > > hotplugged. In the scenario where there is only one physical CPU in > > the system, the init_ttbr would not be initialized for the use in > > resume flow. To get the variable initialized in all scenarios in this > > patch we add that the boot CPU updates init_ttbr after it sets the > > page tables for runtime. > > > > After the memory management is resumed, the SCTLR_WXN in SCTLR_EL2 > > has to be set in order to configure that a mapping cannot be both > > writable and executable (this was configured prior to suspend). > > This is done using an existing function (mmu_init_secondary_cpu). > > > > Signed-off-by: Mirela Simonovic > > Signed-off-by: Saeed Nowshadi > > > > --- > > Changes in v2: > > > > - Patch from v1: > > "[XEN PATCH 17/21] xen/arm: Set SCTLR_WXN in SCTLR_EL2 on resume" > > is squashed with this patch, because it is indeed related to resuming > > the memory management > > - Since the original patch was named 'Enable the MMU', and this is > > not only enabling anymore, but the full resume of functionality, the > > commit title and message is fixed > > --- > > xen/arch/arm/arm64/entry.S | 88 > > ++ > > xen/arch/arm/mm.c | 1 + > > xen/arch/arm/suspend.c | 6 > > 3 files changed, 95 insertions(+) > > > > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S > > index dbc4717903..5efa30e8ee 100644 > > --- a/xen/arch/arm/arm64/entry.S > > +++ b/xen/arch/arm/arm64/entry.S > > @@ -1,6 +1,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -534,6 +535,93 @@ ENTRY(__context_switch) > > ret > > ENTRY(hyp_resume) > > +msr DAIFSet, 0xf /* Disable all interrupts */ > > + > > +tlbi alle2 > > +dsb sy /* Ensure completion of TLB flush */ > > +isb > > + > > +ldr x0, =start > > +adr x19, start /* x19 := paddr (start) */ > > +sub x20, x19, x0 /* x20 := phys-offset */ > > + > > +/* call PROCINFO_cpu_init here */ > > + > > +/* Set up memory attribute type tables */ > > +ldr x0, =MAIRVAL > > +msr mair_el2, x0 > > + > > +/* Set up TCR_EL2: > > + * PS -- Based on ID_AA64MMFR0_EL1.PARange > > + * Top byte is used > > + * PT walks use Inner-Shareable accesses, > > + * PT walks are write-back, write-allocate in both cache levels, > > + * 48-bit virtual address space goes through this table. */ > > +ldr x0, > > =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48)) > > +/* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] > > (PS) */ > > +mrs x1, ID_AA64MMFR0_EL1 > > +bfi x0, x1, #16, #3 > > + > > +msr tcr_el2, x0 > > + > > +/* Set up the SCTLR_EL2: > > + * Exceptions in LE ARM, > > + * Low-latency IRQs disabled, > > + * Write-implies-XN disabled (for now), > > + * D-cache disabled (for now), > > + * I-cache enabled, > > + * Alignment checking disabled, > > + * MMU translation disabled (for now). */ > > +ldr x0, =(HSCTLR_BASE) > > +msr SCTLR_EL2, x0 > > + > > +/* Ensure that any exceptions encountered at EL2 > > + * are handled using the EL2 stack pointer, rather > > + * than SP_EL0. */ > > +msr spsel, #1 > > + > > +/* Rebuild the boot pagetable's first-level entries. The structure > > + * is described in mm.c. > > + * > > + * After the CPU enables paging it will add the fixmap mapping > > + * to these page tables, however this may clash with the 1:1 > > + * mapping. So each CPU must rebuild the page tables here with > > + * the 1:1 in place. */ > > + > > +/* If Xen is loaded at exactly XEN_VIRT_START then we don't > > + * need an additional 1:1 mapping, the virtual mapping will > > + * suffice. > > + */ > > +cmp x19, #XEN_VIRT_START > > +cset x25, eq/* x25 := identity map in place, or > > not */ > > + > > +/* Write Xen's PT's paddr into TTBR0_EL2 */ > > +ldr x4, =boot_pgtable /*
[Xen-devel] [ovmf test] 129891: regressions - FAIL
flight 129891 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129891/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 37 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days2 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 129761: regressions - FAIL
flight 129761 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129761/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 129159 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-examine 8 reboot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux7a4269707deb6ab22d488eb1a9eedae3ef88abc5 baseline version: linux24c2342b8e51ab3185e68470709904150a1e3ee0 Last test of basis 129159 2018-10-30 00:43:28 Z 13 days Testing same since 129761 2018-11-10 16:17:21 Z2 days1 attempts People who touched revisions under test: Aaron Brown Adrian Bunk Al Viro Alan Stern Alexander Duyck Alexander Shishkin Alexei Starovoitov
[Xen-devel] [xen-unstable-smoke test] 129870: regressions - FAIL
flight 129870 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129852
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen b7ae5c33e6b0c5849de9916bd4b15561be43b690
baseline version:
xen 94bd9df0f7efad8038d99ec52ba56ecec4191248
Last test of basis 129852 2018-11-12 16:00:37 Z0 days
Failing since129861 2018-11-12 19:00:52 Z0 days2 attempts
Testing same since 129870 2018-11-12 21:00:23 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Daniel De Graaf
Jan Beulich
Roger Pau Monné
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit b7ae5c33e6b0c5849de9916bd4b15561be43b690
Author: Andrew Cooper
Date: Fri Nov 9 13:46:27 2018 +
x86/badpage: Fix badpage->order overflow
For order 32 or more, the shift will truncate before the addition occurs.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf
Date: Fri Nov 2 13:46:11 2018 -0400
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
Acked-by: Andrew Cooper
commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper
Date: Thu Oct 18 11:30:27 2018 +0100
x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
NX support in the host is required for the shadow pagetable code to handle
SMAP correctly for guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper
Date: Thu Jul 19 16:51:57 2018 +0100
tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné
Date: Mon Nov 12 17:14:57 2018 +0100
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the
Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend
On Mon, 12 Nov 2018, Julien Grall wrote:
> Hi,
>
> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > When Dom0 finalizes its suspend procedure the suspend of Xen is
> > triggered by calling system_suspend(). Dom0 finalizes the suspend from
> > its boot core (VCPU#0), which could be mapped to any physical CPU,
> > i.e. the system_suspend() function could be executed by any physical
> > CPU. Since Xen suspend procedure has to be run by the boot CPU
> > (non-boot CPUs will be disabled at some point in suspend procedure),
> > system_suspend() execution has to continue on CPU#0.
>
> Nothing in the domain_suspend code checks that domain_suspend is called by
> vCPU0. I also can't find any restriction in the PSCI spec to run on pCPU0. Can
> you provide more details why this required?
The spec says that "to use this API, a calling OS must power down all
but one core through calls to CPU_OFF". It is natural to think that the
remaining core would be (physical or virtual) cpu0, but actually it is
not clearly stated by the spec. For dom0, we could simply check that
only 1 vcpu is left ON. For Xen and the physical system_suspend call,
it makes sense to make the call on pcpu0.
> > When the system_suspend() returns 0, it means that the system was
> > suspended and it is coming out of the resume procedure. Regardless
> > of the system_suspend() return value, after this function returns
> > Xen is fully functional, and its state, including all devices and data
> > structures, matches the state prior to calling system_suspend().
> > The status is returned by system_suspend() for debugging/logging
> > purposes and function prototype compatibility.
> >
> > Signed-off-by: Mirela Simonovic
> > Signed-off-by: Saeed Nowshadi
> > ---
> > xen/arch/arm/suspend.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
> > index f2338e41db..21b45f8248 100644
> > --- a/xen/arch/arm/suspend.c
> > +++ b/xen/arch/arm/suspend.c
> > @@ -112,11 +112,20 @@ static void vcpu_suspend(register_t epoint, register_t
> > cid)
> > _arch_set_info_guest(v, );
> > }
> > +/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
> > +static long system_suspend(void *data)
> > +{
> > +BUG_ON(system_state != SYS_STATE_active);
> > +
> > +return -ENOSYS;
> > +}
> > +
> > int32_t domain_suspend(register_t epoint, register_t cid)
> > {
> > struct vcpu *v;
> > struct domain *d = current->domain;
> > bool is_thumb = epoint & 1;
> > +int status;
> > dprintk(XENLOG_DEBUG,
> > "Dom%d suspend: epoint=0x%"PRIregister",
> > cid=0x%"PRIregister"\n",
> > @@ -156,6 +165,31 @@ int32_t domain_suspend(register_t epoint, register_t
> > cid)
> >*/
> > vcpu_block_unless_event_pending(current);
> > +/* If this was dom0 the whole system should suspend: trigger Xen
> > suspend */
> > +if ( is_hardware_domain(d) )
> > +{
> > +/*
> > + * system_suspend should be called when Dom0 finalizes the suspend
> > + * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0
> > could
> > + * be mapped to any PCPU (this function could be executed by any
> > PCPU).
> > + * The suspend procedure has to be finalized by the PCPU#0
> > (non-boot
> > + * PCPUs will be disabled during the suspend).
> > + */
> > +status = continue_hypercall_on_cpu(0, system_suspend, NULL);
> > +/*
> > + * If an error happened, there is nothing that needs to be done
> > here
> > + * because the system_suspend always returns in fully functional
> > state
> > + * no matter what the outcome of suspend procedure is. If the
> > system
> > + * suspended successfully the function will return 0 after the
> > resume.
> > + * Otherwise, if an error is returned it means Xen did not
> > suspended,
> > + * but it is still in the same state as if the system_suspend was
> > never
> > + * called. We dump a debug message in case of an error for
> > debugging/
> > + * logging purpose.
> > + */
> > +if ( status )
> > +dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status);
> > +}
> > +
> > return PSCI_SUCCESS;
> > }
> >
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Bug not present: c49338ef287c44113476d4c6ccaad7fa2924f8c7
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129888/
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build
--summary-out=tmp/129888.bisection-summary --basis-template=129852
--blessings=real,real-bisect xen-unstable-smoke build-amd64 xen-build
Searching for failure / basis pass:
129861 fail [host=albana1] / 129852 [host=godello1] 129846 [host=huxelrebe1]
129836 [host=godello0] 129727 [host=godello0] 129713 [host=huxelrebe1] 129702
ok.
Failure / basis pass flights: 129861 / 129702
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Basis pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
55877a806f2fe7293779edb3a33ca6256edebed8
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
git://xenbits.xen.org/xen.git#55877a806f2fe7293779edb3a33ca6256edebed8-011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Loaded 1001 nodes in revision graph
Searching for test results:
129713 [host=huxelrebe1]
129702 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
55877a806f2fe7293779edb3a33ca6256edebed8
129727 [host=godello0]
129852 [host=godello1]
129846 [host=huxelrebe1]
129836 [host=godello0]
129871 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
3b97ba8fe9a39b02de24e502ef4f80b75276f2cc
129879 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c49338ef287c44113476d4c6ccaad7fa2924f8c7
129867 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
55877a806f2fe7293779edb3a33ca6256edebed8
129886 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
129873 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
96f6ee15ad7ca96472779fc5c083b4149495c584
129861 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
129869 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
129874 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c6aae55786e138951daf25e14709895d8c166948
129877 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
129880 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
129884 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c49338ef287c44113476d4c6ccaad7fa2924f8c7
129887 pass d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c49338ef287c44113476d4c6ccaad7fa2924f8c7
129888 fail d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Searching for interesting versions
Result found: flight 129702 (pass), for basis pass
Result found: flight 129861 (fail), for basis
Re: [Xen-devel] [RFC 09/16] xen/arm: p2m: Introduce a function to resolve translation fault
On Mon, 12 Nov 2018, Julien Grall wrote: > Hi Stefano, > > On 11/6/18 2:20 PM, Julien Grall wrote: > > On 05/11/2018 17:56, Stefano Stabellini wrote: > > > On Mon, 5 Nov 2018, Julien Grall wrote: > > > > On 02/11/2018 23:27, Stefano Stabellini wrote: > > > > > On Mon, 8 Oct 2018, Julien Grall wrote: > > > > > > > > > > > + /* > > > > > > + * Now that the work on the entry is done, set the valid bit to > > > > > > prevent > > > > > > + * another fault on that entry. > > > > > > + */ > > > > > > + resolved = true; > > > > > > + entry.p2m.valid = 1; > > > > > > + > > > > > > + p2m_write_pte(table + offsets[level], entry, p2m->clean_pte); > > > > > > + > > > > > > + /* > > > > > > + * No need to flush the TLBs as the modified entry had the > > > > > > valid bit > > > > > > + * unset. > > > > > > + */ > > > > > > + > > > > > > +out_unmap: > > > > > > + unmap_domain_page(table); > > > > > > + > > > > > > +out: > > > > > > + p2m_write_unlock(p2m); > > > > > > + > > > > > > + return resolved; > > > > > > +} > > > > > > + > > > > > > static inline int p2m_insert_mapping(struct domain *d, > > > > > > gfn_t start_gfn, > > > > > > unsigned long nr, > > > > > > > > > We probably want to update the comment on top of the call to > > > p2m_resolve_translation_fault: > > > > Whoops. I will fix it. > > Looking at this again. I think the comment on top of the call to > p2m_resolve_translation_fault still makes sense. Feel free to suggest an > update of the comment if you think it is not enough. /* * The PT walk may have failed because someone was playing with * the Stage-2 page table or because the valid bit was left * unset to track memory accesses. In these cases, we want to * return to the guest. */___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129856: regressions - FAIL
flight 129856 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129856/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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 build-i386-libvirt1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: ovmf da2c81ee96eba5d5c8ef91fd870ac98d3cf72beb baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 36 attempts Testing same since 129856 2018-11-12 17:41:20 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 807 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 0/2] misc safety certification fixes
Hi all, The first patch introduces a new macro that is used throughout the code in patch #2 to access _stext, _etext pointers and friends. Cheers, Stefano Stefano Stabellini (2): xen: introduce SYMBOL xen: use SYMBOL when required xen/arch/arm/alternative.c| 7 --- xen/arch/arm/arm32/livepatch.c| 3 ++- xen/arch/arm/arm64/livepatch.c| 3 ++- xen/arch/arm/device.c | 6 +++--- xen/arch/arm/livepatch.c | 5 +++-- xen/arch/arm/mm.c | 19 ++- xen/arch/arm/percpu.c | 8 xen/arch/arm/platform.c | 6 -- xen/arch/arm/setup.c | 8 +--- xen/arch/x86/alternative.c| 2 +- xen/arch/x86/efi/efi-boot.h | 4 ++-- xen/arch/x86/percpu.c | 8 xen/arch/x86/setup.c | 11 +++ xen/arch/x86/smpboot.c| 2 +- xen/common/kernel.c | 8 ++-- xen/common/lib.c | 2 +- xen/common/schedule.c | 2 +- xen/common/spinlock.c | 4 +++- xen/common/version.c | 6 +++--- xen/common/virtual_region.c | 2 +- xen/drivers/vpci/vpci.c | 2 +- xen/include/asm-arm/grant_table.h | 3 ++- xen/include/asm-arm/mm.h | 2 +- xen/include/xen/compiler.h| 6 ++ xen/include/xen/kernel.h | 24 25 files changed, 89 insertions(+), 64 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required
Use SYMBOL in cases of comparisons and subtractions of:
_start, _end, __init_begin, __init_end, __2M_text_end,
__2M_rodata_start, __2M_rodata_end, __2M_init_start,__2M_init_end,
__2M_rwdata_start, __2M_rwdata_end, _stext, _etext, _srodata, _erodata,
__end_vpci_array, __start_vpci_array, _sinittext, _einittext,
_stextentry, _etextentry, __start_bug_frames, __stop_bug_frames_0,
__stop_bug_frames_1, __stop_bug_frames_2,__stop_bug_frames_3,
__note_gnu_build_id_start, __note_gnu_build_id_end, __start___ex_table,
__stop___ex_table, __start___pre_ex_table, __stop___pre_ex_table,
__lock_profile_start, __lock_profile_end, __param_start,
__param_end, __setup_start, __setup_end, __initcall_start,
__initcall_end, __presmp_initcall_end, __trampoline_rel_start,
__trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_stop
__alt_instructions, __alt_instructions_end, __ctors_start, __ctors_end,
__end_schedulers_array, __start_schedulers_array, __bss_start,
__bss_end, __per_cpu_start, __per_cpu_data_end, _splatform, _eplatform,
_sdevice, _edevice, _asdevice, _aedevice, __proc_info_start,
__proc_info_end, _sdtb
as by the C standard [1].
M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
pointers that address elements of the same array
[1]
https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
QAVerify: 2761
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
Changes in v4:
- only use SYMBOL where necessary, not "everywhere": comparisons and
subtractions
- improve commit message
- remove some unnecessary casts
- fix some still unsafe casts
- extend checks to all symbols in xen/arch/x86/xen.lds.S and
xen/arch/arm/xen.lds.S
Changes in v3:
- improve commit message
- no hard tabs
- rename __symbol to SYMBOL
- fix __end_vpci_array and __start_vpci_array
- avoid all comparisons between pointers: including (void *) casted
returns from SYMBOL()
- remove useless casts to (unsigned long)
Changes in v2:
- cast return of SYMBOL to char* when required
- define __pa as unsigned long in is_kernel* functions
---
xen/arch/arm/alternative.c| 7 ---
xen/arch/arm/arm32/livepatch.c| 3 ++-
xen/arch/arm/arm64/livepatch.c| 3 ++-
xen/arch/arm/device.c | 6 +++---
xen/arch/arm/livepatch.c | 5 +++--
xen/arch/arm/mm.c | 19 ++-
xen/arch/arm/percpu.c | 8
xen/arch/arm/platform.c | 6 --
xen/arch/arm/setup.c | 8 +---
xen/arch/x86/alternative.c| 2 +-
xen/arch/x86/efi/efi-boot.h | 4 ++--
xen/arch/x86/percpu.c | 8
xen/arch/x86/setup.c | 11 +++
xen/arch/x86/smpboot.c| 2 +-
xen/common/kernel.c | 8 ++--
xen/common/lib.c | 2 +-
xen/common/schedule.c | 2 +-
xen/common/spinlock.c | 4 +++-
xen/common/version.c | 6 +++---
xen/common/virtual_region.c | 2 +-
xen/drivers/vpci/vpci.c | 2 +-
xen/include/asm-arm/grant_table.h | 3 ++-
xen/include/asm-arm/mm.h | 2 +-
xen/include/xen/kernel.h | 24
24 files changed, 83 insertions(+), 64 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 52ed7ed..b740cfe 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -131,7 +131,7 @@ static int __apply_alternatives(const struct alt_region
*region,
printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
-for ( alt = region->begin; alt < region->end; alt++ )
+for ( alt = region->begin; SYMBOL(alt) < SYMBOL(region->end); alt++ )
{
int nr_inst;
@@ -188,7 +188,7 @@ static int __apply_alternatives_multi_stop(void *unused)
int ret;
struct alt_region region;
mfn_t xen_mfn = virt_to_mfn(_start);
-paddr_t xen_size = _end - _start;
+paddr_t xen_size = SYMBOL(_end) - SYMBOL(_start);
unsigned int xen_order = get_order_from_bytes(xen_size);
void *xenmap;
@@ -206,7 +206,8 @@ static int __apply_alternatives_multi_stop(void *unused)
region.begin = __alt_instructions;
region.end = __alt_instructions_end;
-ret = __apply_alternatives(, xenmap - (void *)_start);
+ret = __apply_alternatives(,
+ (unsigned long)xenmap - SYMBOL(_start));
/* The patching is not expected to fail during boot. */
BUG_ON(ret != 0);
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a5..83f443f 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -56,7 +56,8 @@ void arch_livepatch_apply(struct livepatch_func *func)
else
insn = 0xe1a0; /*
[Xen-devel] [PATCH v7 07/25] xen/arm: don't add duplicate boot modules, introduce domU flag
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
Changes in v6:
- update comments
Changes in v5:
- improve commit message
- add in-code comments
Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 11 +++
xen/arch/arm/setup.c| 34 +-
xen/include/asm-arm/setup.h | 12 ++--
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 76693b5..e885874 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -176,6 +176,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
int len = 92;
char path[92];
int parent_node, ret;
+bool domU;
parent_node = fdt_parent_offset(fdt, node);
ASSERT(parent_node >= 0);
@@ -230,12 +231,14 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-add_boot_module(kind, start, size);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
prop = fdt_get_property(fdt, node, "bootargs", );
if ( !prop )
return;
-add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
+ kind, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -281,7 +284,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
}
static int __init early_scan_node(const void *fdt,
@@ -352,7 +355,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if ( ret < 0 )
panic("No valid device tree\n");
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2098591..c69e872 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size)
+ paddr_t start, paddr_t size,
+ bool domU)
{
struct bootmodules *mods =
struct bootmodule *mod;
+unsigned int i;
if ( mods->nr_mods == MAX_MODULES )
{
@@ -212,15 +214,31 @@ struct bootmodule __init *add_boot_module(bootmodule_kind
kind,
boot_module_kind_as_string(kind), start, start + size);
return NULL;
}
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = >module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
mod = >module[mods->nr_mods++];
mod->kind = kind;
mod->start = start;
mod->size = size;
+mod->domU = domU;
return mod;
}
+/*
+ * boot_module_find_by_kind can only be used to return Xen modules (e.g
+ * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
+ * modules.
+ */
struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
{
struct bootmodules *mods =
@@ -229,14 +247,14 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
for (i = 0 ; i < mods->nr_mods ; i++ )
{
mod = >module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
return mod;
}
return NULL;
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind)
+ bootmodule_kind kind, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -249,6 +267,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
[Xen-devel] [PATCH v7 00/25] dom0less step1: boot multiple domains from device tree
Hi all,
This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.
The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.
The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore for the
moment. This is actually OK, because this is meant for mission critical
applications that typically only access directly assigned devices. They
cannot tolerate interference or increased IRQ latency due to PV
protocols. Device assignment is not actually covered by this series, it
will be added later.
DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.
In this version of the series, I reordered the patches to make sure they
are all bisectable.
Cheers,
Stefano
The following changes since commit 359970fd8b781fac2ddcbc84dd5b890075fa08ef:
tools/libxl: Switch Arm guest type to PVH (2018-10-03 15:58:02 +0100)
are available in the git repository at:
http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git
dom0less-v7
for you to fetch changes up to 93ee838b4f488a06fe2310c7d31bbe9e1dac354f:
xen/arm: split domain_build.c (2018-11-12 14:56:15 -0800)
Stefano Stabellini (25):
xen: allow console_io hypercalls from certain DomUs
xen/arm: extend device tree based multiboot protocol
xen/arm: document dom0less
xen/arm: increase MAX_MODULES
xen/arm: check for multiboot nodes only under /chosen
xen/arm: introduce bootcmdlines
xen/arm: don't add duplicate boot modules, introduce domU flag
xen/arm: probe domU kernels and initrds
xen/arm: add start to struct bootcmdline
xen/arm: rename get_11_allocation_size to get_allocation_size
xen/arm: rename allocate_memory to allocate_memory_11
xen/arm: introduce allocate_memory
xen/arm: refactor construct_dom0
xen/arm: move unregister_init_virtual_region to init_done
xen/arm: introduce create_domUs
xen/arm: implement construct_domU
xen/arm: generate a simple device tree for domUs
xen/arm: make set_interrupt_ppi able to handle non-PPI
xen/arm: generate vpl011 node on device tree for domU
xen/arm: introduce a union in vpl011
xen/arm: refactor vpl011_data_avail
xen: support console_switching between Dom0 and DomUs on ARM
xen/arm: Allow vpl011 to be used by DomU
xen/arm: move kernel.h to asm-arm/
xen/arm: split domain_build.c
docs/INDEX |1 +
docs/features/dom0less.markdown| 49 ++
docs/misc/arm/device-tree/booting.txt | 107 +++
xen/arch/arm/acpi/Makefile |1 +
xen/arch/arm/acpi/domain_build.c | 591 +++
xen/arch/arm/bootfdt.c | 58 +-
xen/arch/arm/domain_build.c| 1091 +---
xen/arch/arm/kernel.c | 67 +-
xen/arch/arm/setup.c | 112 ++-
xen/arch/arm/vpl011.c | 297 ++--
xen/drivers/char/console.c | 90 ++-
xen/include/asm-arm/domain_build.h | 31 +
xen/{arch/arm => include/asm-arm}/kernel.h |6 +-
xen/include/asm-arm/setup.h| 36 +-
xen/include/asm-arm/vpl011.h | 20 +-
xen/include/asm-x86/setup.h|2 +
xen/include/xen/console.h |2 +
xen/include/xen/sched.h|2 +
xen/include/xsm/dummy.h|2 +
19 files changed, 1860 insertions(+), 705 deletions(-)
create mode 100644 docs/features/dom0less.markdown
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
rename xen/{arch/arm => include/asm-arm}/kernel.h (91%)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 22/25] xen: support console_switching between Dom0 and DomUs on ARM
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing comment about "notify the guest", making it clear that
it is only about the hardware domain.
Switching the console input to domUs started from Xen at boot is
#ifdef'ed to 0 in this patch. The code will be enabled when
vpl011_rx_char_xen is introduced. For now it is disabled for
bisectability.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
Changes in v6:
- improve in-code comment
- improve commit messahe
- code style
Changes in v5:
- move patch earlier and disable code that calls vpl011_rx_char_xen (not
defined yet)
- improve comments
- replace ifs with a switch
- code style
Changes in v4:
- handle console_rx == 0 in console_input_domain
- use rcu_lock_by_domain instead of get_domain_by_id
- handle the case where the returned domain is NULL
- send_global_virq(VIRQ_CONSOLE) only when chars are for Dom0
- make console_rx unsigned int
- fix comment
- code readability improvement
- fix opt_conswitch[1] == 'x' case
- move console_input_domain to next patch
Changes in v3:
- only call vpl011 functions ifdef CONFIG_SBSA_VUART_CONSOLE
- add blank line and spaces
- remove xen_rx from print messages
- rename xen_rx to console_rx
- keep switch_serial_input() at boot
- add better comments
- fix existing comment
- add warning if no guests console/uart is available
- add console_input_domain function
Changes in v2:
- only call vpl011_rx_char if the vpl011 has been initialized
---
xen/drivers/char/console.c | 82 ++
1 file changed, 68 insertions(+), 14 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3b75f7a..8a01a43 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,10 +31,13 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
#include
+#else
+#include
#endif
/* console: comma-separated list of console outputs. */
@@ -391,31 +394,82 @@ static void dump_console_ring_key(unsigned char key)
free_xenheap_pages(buf, order);
}
-/* CTRL- switches input direction between Xen and DOM0. */
+/*
+ * CTRL- changes input direction, rotating among Xen, Dom0,
+ * and the DomUs started from Xen at boot.
+ */
#define switch_code (opt_conswitch[0]-'a'+1)
-static int __read_mostly xen_rx = 1; /* FALSE => input passed to domain 0. */
+/*
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input to dom(N-1)
+ */
+static unsigned int __read_mostly console_rx = 0;
static void switch_serial_input(void)
{
-static char *input_str[2] = { "DOM0", "Xen" };
-xen_rx = !xen_rx;
-printk("*** Serial input -> %s", input_str[xen_rx]);
+if ( console_rx == max_init_domid + 1 )
+{
+console_rx = 0;
+printk("*** Serial input to Xen");
+}
+else
+{
+console_rx++;
+printk("*** Serial input to DOM%d", console_rx - 1);
+}
+
if ( switch_code )
-printk(" (type 'CTRL-%c' three times to switch input to %s)",
- opt_conswitch[0], input_str[!xen_rx]);
+printk(" (type 'CTRL-%c' three times to switch input)",
+ opt_conswitch[0]);
printk("\n");
}
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
-if ( xen_rx )
+switch ( console_rx )
+{
+case 0:
return handle_keypress(c, regs);
-/* Deliver input to guest buffer, unless it is already full. */
-if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
-serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
-/* Always notify the guest: prevents receive path from getting stuck. */
-send_global_virq(VIRQ_CONSOLE);
+case 1:
+/*
+ * Deliver input to the hardware domain buffer, unless it is
+ * already full.
+ */
+if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
+serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
+
+/*
+ * Always notify the hardware domain: prevents receive path from
+ * getting stuck.
+ */
+send_global_virq(VIRQ_CONSOLE);
+break;
+
+#if 0
+default:
+{
+struct domain *d = rcu_lock_domain_by_any_id(console_rx - 1);
+
+/*
+ * If we have a properly initialized vpl011 console for the
+ * domain, without a full PV ring to Dom0 (in that case input
+ * comes from the PV ring), then send the character to it.
+ */
+if ( d != NULL &&
+ !d->arch.vpl011.backend_in_domain
[Xen-devel] [PATCH v7 23/25] xen/arm: Allow vpl011 to be used by DomU
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUF_SIZE used in vuart.c.
Export a function named console_input_domain() to allow others to know
which domains has input at a given time.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- merge patch with "xen/vpl011: buffer out chars when the backend is xen"
(no other changes)
- keep Julien's Acked-by as both patches were Acked by Julien
Changes in v5:
- renable call to vpl011_rx_char_xen from console.c
Changes in v4:
- code style
Changes in v3:
- add in-code comments
- improve existing comments
- remove ifdef around domain_vpl011_init in construct_domU
- add ASSERT
- use SBSA_UART_FIFO_SIZE for in buffer size
- rename ring_enable to backend_in_domain
- rename struct xencons_in to struct vpl011_xen_backend
- rename inring field to xen
- rename helper functions accordingly
- remove unnecessary stub implementation of vpl011_rx_char
- move vpl011_rx_char_xen within the file to avoid the need of a forward
declaration of vpl011_data_avail
- fix small bug in vpl011_rx_char_xen: increment in_prod before using it
to check xencons_queued.
Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
(vpl011_write_data_noring)
- duplicate vpl011_read_data
---
xen/arch/arm/domain_build.c | 9 +-
xen/arch/arm/vpl011.c| 231 ++-
xen/drivers/char/console.c | 10 +-
xen/include/asm-arm/vpl011.h | 12 +++
xen/include/xen/console.h| 2 +
5 files changed, 238 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 933a6c9..064f2a9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2631,7 +2631,14 @@ static int __init construct_domU(struct domain *d,
if ( rc < 0 )
return rc;
-return construct_domain(d, );
+rc = construct_domain(d, );
+if ( rc < 0 )
+return rc;
+
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
+return rc;
}
void __init create_domUs(void)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 68452a8..719a339 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,121 @@ static void vpl011_update_interrupt_status(struct domain *d)
#endif
}
+/*
+ * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
+ * console. Only to be used when the backend is Xen.
+ */
+static void vpl011_write_data_xen(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+struct domain *input = console_input_domain();
+
+VPL011_LOCK(d, flags);
+
+intf->out[intf->out_prod++] = data;
+if ( d == input )
+{
+if ( intf->out_prod == 1 )
+{
+printk("%c", data);
+intf->out_prod = 0;
+}
+else
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("%s", intf->out);
+intf->out_prod = 0;
+}
+}
+else
+{
+if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
+ data == '\n' )
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("DOM%u: %s", d->domain_id, intf->out);
+intf->out_prod = 0;
+}
+}
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+if ( input != NULL )
+rcu_unlock_domain(input);
+}
+
+/*
+ * vpl011_read_data_xen reads data when the backend is xen. Characters
+ * are added to the
[Xen-devel] [PATCH v7 19/25] xen/arm: generate vpl011 node on device tree for domU
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.
Enable vpl011 conditionally if the user requested it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use dt_property_read_bool
Changes in v4:
- move rename set_interrupt_ppi and making set_interrupt_ppi generic to
a separate patch
- properly name the vpl011 device node name
- code style
- use #define for addrcells and sizecells
Changes in v3:
- use bool
- retain BUG_ON(irq < 16)
- add vpl011 bool to kinfo
- return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
missing
Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
xen/arch/arm/domain_build.c | 60 +
xen/arch/arm/kernel.h | 3 +++
2 files changed, 63 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 297f5dd..933a6c9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1622,6 +1622,54 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intr;
+__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
+ GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+ GUEST_PL011_SIZE);
+if ( res )
+return res;
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "interrupt-parent",
+GUEST_PHANDLE_GIC);
+if ( res )
+return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+return 0;
+}
+#endif
+
/*
* The max size for DT is 2MB. However, the generated DT is small, 4KB
* are enough for now, but we might have to increase it in the future.
@@ -1683,6 +1731,16 @@ static int __init prepare_dtb_domU(struct domain *d,
struct kernel_info *kinfo)
if ( ret )
goto err;
+if ( kinfo->vpl011 )
+{
+ret = -EINVAL;
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+ret = make_vpl011_uart_node(d, kinfo->fdt);
+#endif
+if ( ret )
+goto err;
+}
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
@@ -2551,6 +2609,8 @@ static int __init construct_domU(struct domain *d,
printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d->max_vcpus,
mem);
+kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
+
if ( vcpu_create(d, 0, 0) == NULL )
return -ENOMEM;
d->max_pages = ~0U;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4320f72..33f3e72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -33,6 +33,9 @@ struct kernel_info {
paddr_t dtb_paddr;
paddr_t initrd_paddr;
+/* Enable pl011 emulation */
+bool vpl011;
+
/* loader to use for this kernel */
void (*load)(struct kernel_info *info);
/* loader specific state */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 15/25] xen/arm: introduce create_domUs
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.
Move the discard_initial_modules after DomUs have been built.
First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v5:
- use dt_property_read_bool
- improve commit message
- code style
- use dt_find_node_by_path instead of dt_find_node_by_name
- use true with is_console
Changes in v4:
- constify parameters
- nr_spis to 0 or GUEST_VPL011_SPI - 32 + 1 depending on vpl011
- remove pointless initializer
- remove change to domain_create for dom0 (useless)
- make construct_domU return error
Changes in v3:
- move patch earlier and introduce empty construct_domU to fix bisection
builds
- fix max_init_domid to actually hold the max domid among initial
domains (instead of max_domid + 1)
- move domain_unpause_by_systemcontroller(dom0) after creating domUs
Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
xen/arch/arm/domain_build.c | 50 +
xen/arch/arm/setup.c| 5 +
xen/include/asm-arm/setup.h | 3 +++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4707f42..4709683 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2306,6 +2307,50 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
return 0;
}
+static int __init construct_domU(struct domain *d,
+ const struct dt_device_node *node)
+{
+return -ENOSYS;
+}
+
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+
+BUG_ON(chosen == NULL);
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {
+.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+.arch.nr_spis = 0,
+.max_vcpus = 1,
+.max_evtchn_port = -1,
+.max_grant_frames = 64,
+.max_maptrack_frames = 1024,
+};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+if ( dt_property_read_bool(node, "vpl011") )
+d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
+dt_property_read_u32(node, "cpus", _cfg.max_vcpus);
+
+d = domain_create(++max_init_domid, _cfg, false);
+if ( IS_ERR(d) )
+panic("Error creating domain %s", dt_node_name(node));
+
+d->is_console = true;
+
+if ( construct_domU(d, node) != 0 )
+panic("Could not set up domain %s", dt_node_name(node));
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+
int __init construct_dom0(struct domain *d)
{
struct kernel_info kinfo = {};
@@ -2356,10 +2401,7 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-rc = construct_domain(d, );
-discard_initial_modules();
-
-return rc;
+return construct_domain(d, );
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b0a5e35..3940982 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,11 +64,14 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid;
+
static __used void init_done(void)
{
/* Must be done past setting system_state. */
unregister_init_virtual_region();
+discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -963,6 +966,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
+create_domUs();
+
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0d787e6..eb0c95f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -75,6 +75,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
@@ -91,6 +93,7 @@ void acpi_create_efi_mmap_table(struct domain *d,
[Xen-devel] [PATCH v7 01/25] xen: allow console_io hypercalls from certain DomUs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini
Acked-by: Daniel De Graaf
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v3:
- remove changes to hooks.c
Changes in v2:
- introduce is_console
- remove #ifdefs
---
xen/include/xen/sched.h | 2 ++
xen/include/xsm/dummy.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0ba80cb..abcc74e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
bool auto_node_affinity;
/* Is this guest fully privileged (aka dom0)? */
bool is_privileged;
+/* Can this guest access the Xen console? */
+bool is_console;
/* Is this a xenstore domain (not dom0)? */
bool is_xenstore;
/* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..29d7b50 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
{
XSM_ASSERT_ACTION(XSM_OTHER);
+if ( d->is_console )
+return xsm_default_action(XSM_HOOK, d, NULL);
#ifdef CONFIG_VERBOSE_DEBUG
if ( cmd == CONSOLEIO_write )
return xsm_default_action(XSM_HOOK, d, NULL);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 18/25] xen/arm: make set_interrupt_ppi able to handle non-PPI
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3d33d1f..297f5dd 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -594,19 +594,20 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
typedef __be32 gic_interrupt_t[3];
-static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
- unsigned int irq,
- unsigned int cpumask,
- unsigned int level)
+static void __init set_interrupt(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
{
__be32 *cells = interrupt;
+bool is_ppi = !!(irq < 32);
BUG_ON(irq < 16);
-BUG_ON(irq >= 32);
+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
/* See linux
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
-dt_set_cell(, 1, 1); /* is a PPI */
-dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(, 1, is_ppi); /* is a PPI? */
+dt_set_cell(, 1, irq);
dt_set_cell(, 1, (cpumask << 8) | level);
}
@@ -729,7 +730,7 @@ static int __init make_hypervisor_node(struct domain *d,
* - All CPUs
* TODO: Handle properly the cpumask;
*/
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, , 1);
if ( res )
return res;
@@ -1006,15 +1007,15 @@ static int __init make_timer_node(const struct domain
*d, void *fdt,
irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
dt_dprintk(" Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
dt_dprintk(" Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_VIRT_PPI);
dt_dprintk(" Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, intrs, 3);
if ( res )
@@ -1603,9 +1604,9 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
if ( res )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 20/25] xen/arm: introduce a union in vpl011
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v4:
- name union "backend"
Changes in v3:
- rename ring field to dom
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c| 22 --
xen/include/asm-arm/vpl011.h | 8 ++--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index a281eab..ebc045e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -82,7 +82,7 @@ static uint8_t vpl011_read_data(struct domain *d)
unsigned long flags;
uint8_t data = 0;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod;
VPL011_LOCK(d, flags);
@@ -145,7 +145,7 @@ static uint8_t vpl011_read_data(struct domain *d)
static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
unsigned int fifo_level)
{
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
BUILD_BUG_ON(sizeof(intf->out) < SBSA_UART_FIFO_SIZE);
@@ -164,7 +164,7 @@ static void vpl011_write_data(struct domain *d, uint8_t
data)
{
unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX out_cons, out_prod;
VPL011_LOCK(d, flags);
@@ -382,7 +382,7 @@ static void vpl011_data_avail(struct domain *d)
{
unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
XENCONS_RING_IDX in_fifo_level, out_fifo_level;
@@ -459,14 +459,14 @@ int domain_vpl011_init(struct domain *d, struct
vpl011_init_info *info)
int rc;
struct vpl011 *vpl011 = >arch.vpl011;
-if ( vpl011->ring_buf )
+if ( vpl011->backend.dom.ring_buf )
return -EINVAL;
/* Map the guest PFN to Xen address space. */
rc = prepare_ring_for_helper(d,
gfn_x(info->gfn),
- >ring_page,
- >ring_buf);
+ >backend.dom.ring_page,
+ >backend.dom.ring_buf);
if ( rc < 0 )
goto out;
@@ -495,7 +495,8 @@ out2:
vgic_free_virq(d, GUEST_VPL011_SPI);
out1:
-destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(>backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
out:
return rc;
@@ -505,11 +506,12 @@ void domain_vpl011_deinit(struct domain *d)
{
struct vpl011 *vpl011 = >arch.vpl011;
-if ( !vpl011->ring_buf )
+if ( !vpl011->backend.dom.ring_buf )
return;
free_xen_event_channel(d, vpl011->evtchn);
-destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(>backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
}
/*
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index db95ff8..42d7a24 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -31,8 +31,12 @@
#define SBSA_UART_FIFO_SIZE 32
struct vpl011 {
-void *ring_buf;
-struct page_info *ring_page;
+union {
+struct {
+void *ring_buf;
+struct page_info *ring_page;
+} dom;
+} backend;
uint32_tuartfr; /* Flag register */
uint32_tuartcr; /* Control register */
uint32_tuartimsc; /* Interrupt mask register*/
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 03/25] xen/arm: document dom0less
Add a new document to provide information on how to use dom0less related
features and their current limitations.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX
Changes in v4:
- rename to .txt
- improve wording
Changes in v3:
- add patch
---
docs/INDEX | 1 +
docs/features/dom0less.markdown | 49 +
2 files changed, 50 insertions(+)
create mode 100644 docs/features/dom0less.markdown
diff --git a/docs/INDEX b/docs/INDEX
index 868ab1f..e673edd 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,3 +25,4 @@ misc/arm/early-printk Enabling early printk on ARM
misc/arm/passthrough Passthrough a device described in the Device
Tree to a guest
misc/arm/device-tree/booting Device tree bindings to boot Xen
misc/arm/device-tree/passthrough Device tree binding to passthrough a
device
+features/dom0less.markdown Boot multiple domains from Xen in parallel
diff --git a/docs/features/dom0less.markdown b/docs/features/dom0less.markdown
new file mode 100644
index 000..4e342b7
--- /dev/null
+++ b/docs/features/dom0less.markdown
@@ -0,0 +1,49 @@
+Dom0less
+
+
+"Dom0less" is a set of Xen features that enable the deployment of a Xen
+system without an control domain (often referred to as "dom0"). Each
+feature can be used independently from the others, unless otherwise
+stated.
+
+Booting Multiple Domains from Device Tree
+-
+
+This feature enables Xen to create a set of DomUs at boot time.
+Information about the DomUs to be created by Xen is passed to the
+hypervisor via Device Tree. Specifically, the existing Device Tree based
+Multiboot specification has been extended to allow for multiple domains
+to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more
+information about the Multiboot specification and how to use it.
+
+Currently, a control domain ("dom0") is still required, but in the
+future it will become unnecessary when all domains are created
+directly from Xen. Instead of waiting for the control domain to be fully
+booted and the Xen tools to become available, domains created by Xen
+this way are started right away in parallel. Hence, their boot time is
+typically much shorter.
+
+Domains started by Xen at boot time currently have the following
+limitations:
+
+- They cannot be properly shutdown or rebooted using xl. If one of them
+ crashes, the whole platform should be rebooted.
+
+- Some xl operations might not work as expected. xl is meant to be used
+ with domains that have been created by it. Using xl with domains
+ started by Xen at boot might not work as expected.
+
+- The GIC version is the native version. In absence of other
+ information, the GIC version exposed to the domains started by Xen at
+ boot is the same as the native GIC version.
+
+- No PV drivers. There is no support for PV devices at the moment. All
+ devices need to be statically assigned to guests.
+
+- Pinning vCPUs of domains started by Xen at boot can be
+ done from the control domain, using `xl vcpu-pin` as usual. It is not
+ currently possible to configure vCPU pinning without a control domain.
+ However, the NULL scheduler can be selected by passing `sched=null` to
+ the Xen command line. The NULL scheduler automatically assigns and
+ pins vCPUs to pCPUs, but the vCPU-pCPU assignments cannot be
+ configured.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 09/25] xen/arm: add start to struct bootcmdline
Add a new start address field to struct bootcmdline to easily match a
cmdline to the corresponding bootmodule. This is useful for debugging
(not actually needed for functionalities today, but could be.)
Instead of printing the index in the cmdline array, print the start
address of the corresponding bootmodule for each cmdline in
early_print_info.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/bootfdt.c | 4 ++--
xen/arch/arm/setup.c| 3 ++-
xen/include/asm-arm/setup.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index e885874..13583e5 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -238,7 +238,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
if ( !prop )
return;
add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
- kind, domU);
+ kind, start, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -335,7 +335,7 @@ static void __init early_print_info(void)
}
printk("\n");
for ( i = 0 ; i < cmds->nr_mods; i++ )
-printk("CMDLINE[%d]:%s %s\n", i,
+printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
cmds->cmdline[i].dt_name,
>cmdline[i].cmdline[0]);
printk("\n");
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dbba8f3..a819953 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -254,7 +254,7 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU)
+ bootmodule_kind kind, paddr_t start, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -268,6 +268,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
cmd->kind = kind;
cmd->domU = domU;
+cmd->start = start;
ASSERT(strlen(name) <= DT_MAX_NAME);
safe_strcpy(cmd->dt_name, name);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 33fb04e..0d787e6 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -49,6 +49,7 @@ struct bootmodule {
struct bootcmdline {
bootmodule_kind kind;
bool domU;
+paddr_t start;
char dt_name[DT_MAX_NAME];
char cmdline[BOOTMOD_MAX_CMDLINE];
};
@@ -104,7 +105,7 @@ struct bootmodule *boot_module_find_by_kind(bootmodule_kind
kind);
struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind
kind,
paddr_t start);
void add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU);
+ bootmodule_kind kind, paddr_t start, bool domU);
struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
struct bootcmdline * __init boot_cmdline_find_by_name(const char *name);
const char * __init boot_module_kind_as_string(bootmodule_kind kind);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 25/25] xen/arm: split domain_build.c
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/domain_build.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- build domain_build.init.o
- remove "static" from prepare_acpi implementation
Changes in v6:
- fix license
Changes in v4:
- rename acpi_dt_build to domain_build.c
- add copyright header
- remove useless #include
- remove acpi_dt_build.h, add domain_build.h
---
xen/arch/arm/acpi/Makefile | 1 +
xen/arch/arm/acpi/domain_build.c | 591 +
xen/arch/arm/domain_build.c| 585 +---
xen/include/asm-arm/domain_build.h | 31 ++
4 files changed, 628 insertions(+), 580 deletions(-)
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8..274dc2e 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
obj-y += lib.o
+obj-y += domain_build.init.o
obj-y += boot.init.o
diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
new file mode 100644
index 000..5aae32a
--- /dev/null
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -0,0 +1,591 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int __init acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long mfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+mfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, mfn, mfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
+static int __init acpi_route_spis(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/*
+ * Route the IRQ to hardware domain and permit the access.
+ * The interrupt type will be set by set by the hardware domain.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+/*
+ * TODO: Exclude the SPIs SMMU uses which should not be routed to
+ * the hardware domain.
+ */
+desc = irq_to_desc(i);
+if ( desc->action != NULL)
+continue;
+
+/* XXX: Shall we use a proper devname? */
+res = map_irq_to_domain(d, i, true, "ACPI");
+if ( res )
+return res;
+}
+
+return 0;
+}
+
+static int __init acpi_make_hypervisor_node(const struct kernel_info *kinfo,
+struct membank tbl_add[])
+{
+const char compat[] =
+"xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+"xen,xen";
+int res;
+/* Convenience alias */
+void *fdt = kinfo->fdt;
+
+dt_dprintk("Create hypervisor node\n");
+
+/* See linux Documentation/devicetree/bindings/arm/xen.txt */
+res = fdt_begin_node(fdt, "hypervisor");
+if ( res )
+return res;
+
+/* Cannot use fdt_property_string due to embedded nulls */
+res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+if ( res )
+return res;
+
+res = acpi_make_efi_nodes(fdt, tbl_add);
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+/*
+ * Prepare a minimal DTB for Dom0 which contains bootargs, initrd, memory
+ * information, EFI table.
+ */
+static int __init create_acpi_dtb(struct kernel_info *kinfo,
+ struct membank tbl_add[])
+{
+int new_size;
+int ret;
+
+dt_dprintk("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = ACPI_DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(new_size);
+
+if ( kinfo->fdt == NULL )
+return
[Xen-devel] [PATCH v7 08/25] xen/arm: probe domU kernels and initrds
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Set command line for dom0 in kernel_probe for consistency.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- style improvement in comment
- remove redundant cmdline assignment in construct_dom0
Changes in v5:
- constify kernel_probe
- add ASSERT and comment in kernel_probe
- limit variable scope
- fix printk message
- int/unsigned int
- set cmdline for dom0 too
- improve code readability
Changes in v3:
- retrieve cmdline from bootcmdlines array
Changes in v2:
- fix indentation
- unify kernel_probe with kernel_probe_domU
- find cmdline on device_tree from kernel_probe
---
xen/arch/arm/domain_build.c | 4 +--
xen/arch/arm/kernel.c | 64 -
xen/arch/arm/kernel.h | 2 +-
xen/arch/arm/setup.c| 31 ++
xen/include/asm-arm/setup.h | 3 +++
5 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6b15bc7..59c9f34 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2107,7 +2107,6 @@ static void __init find_gnttab_region(struct domain *d,
int __init construct_dom0(struct domain *d)
{
-const struct bootcmdline *kernel =
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
struct kernel_info kinfo = {};
struct vcpu *saved_current;
int rc, i, cpu;
@@ -2135,7 +2134,7 @@ int __init construct_dom0(struct domain *d)
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
-rc = kernel_probe();
+rc = kernel_probe(, NULL);
if ( rc < 0 )
return rc;
@@ -2153,7 +2152,6 @@ int __init construct_dom0(struct domain *d)
#endif
-kinfo.cmdline = (kernel != NULL) ? >cmdline[0] : NULL;
allocate_memory(d, );
find_gnttab_region(d, );
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..ae3673e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct
kernel_info *info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
{
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
int rc;
+/* domain is NULL only for the hardware domain */
+if ( domain == NULL )
+{
+ASSERT(is_hardware_domain(info->d));
+
+mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+info->kernel_bootmodule = mod;
+info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
+else
+{
+const char *name = NULL;
+
+dt_for_each_child_node(domain, node)
+{
+if ( dt_device_is_compatible(node, "multiboot,kernel") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+mod = boot_module_find_by_addr_and_kind(
+BOOTMOD_KERNEL, kernel_addr);
+info->kernel_bootmodule = mod;
+}
+else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+BOOTMOD_RAMDISK, initrd_addr);
+}
+else
+continue;
+}
+name = dt_node_name(domain);
+cmd = boot_cmdline_find_by_name(name);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
if ( !mod || !mod->size )
{
printk(XENLOG_ERR "Missing kernel boot module?\n");
return -ENOENT;
}
-info->kernel_bootmodule = mod;
-
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
-
-info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+printk("Loading Dom%pd kernel from boot module @ %"PRIpaddr"\n",
+ info->d, info->kernel_bootmodule->start);
if ( info->initrd_bootmodule )
printk("Loading ramdisk from
[Xen-devel] [PATCH v7 05/25] xen/arm: check for multiboot nodes only under /chosen
Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- set path size to 92, treat -FDT_ERR_NOSPACE as erro
Changes in v6:
- do not proceed if fdt_get_path returns error != -FDT_ERR_NOSPACE
- remove sizeof, use hardcoded value
Changes in v5:
- add patch
- add check on return value of fdt_get_path
---
xen/arch/arm/bootfdt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8eba42c..b1d226f 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -173,7 +173,15 @@ static void __init process_multiboot_node(const void *fdt,
int node,
bootmodule_kind kind;
paddr_t start, size;
const char *cmdline;
-int len;
+/* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
+int len = 92;
+char path[92];
+int ret;
+
+/* Check that the node is under "/chosen" (first 7 chars of path) */
+ret = fdt_get_path(fdt, node, path, len);
+if ( ret != 0 || strncmp(path, "/chosen", 7) )
+return;
prop = fdt_get_property(fdt, node, "reg", );
if ( !prop )
@@ -286,8 +294,8 @@ static int __init early_scan_node(const void *fdt,
{
if ( device_tree_node_matches(fdt, node, "memory") )
process_memory_node(fdt, node, name, address_cells, size_cells);
-else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" )
||
- device_tree_node_compatible(fdt, node, "multiboot,module" ))
+else if ( depth <= 3 && (device_tree_node_compatible(fdt, node,
"xen,multiboot-module" ) ||
+ device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
process_chosen_node(fdt, node, name, address_cells, size_cells);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 24/25] xen/arm: move kernel.h to asm-arm/
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
xen/include/asm-arm/kernel.h | 86
4 files changed, 88 insertions(+), 89 deletions(-)
delete mode 100644 xen/arch/arm/kernel.h
create mode 100644 xen/include/asm-arm/kernel.h
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 064f2a9..35de50c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
-#include "kernel.h"
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index ae3673e..d04a862 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -16,8 +16,7 @@
#include
#include
-
-#include "kernel.h"
+#include
#define UIMAGE_MAGIC 0x27051956
#define UIMAGE_NMLEN 32
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
deleted file mode 100644
index 33f3e72..000
--- a/xen/arch/arm/kernel.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Kernel image loading.
- *
- * Copyright (C) 2011 Citrix Systems, Inc.
- */
-#ifndef __ARCH_ARM_KERNEL_H__
-#define __ARCH_ARM_KERNEL_H__
-
-#include
-#include
-
-struct kernel_info {
-#ifdef CONFIG_ARM_64
-enum domain_type type;
-#endif
-
-struct domain *d;
-
-void *fdt; /* flat device tree */
-paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-struct meminfo mem;
-
-/* kernel entry point */
-paddr_t entry;
-
-/* grant table region */
-paddr_t gnttab_start;
-paddr_t gnttab_size;
-
-/* boot blob load addresses */
-const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
-const char* cmdline;
-paddr_t dtb_paddr;
-paddr_t initrd_paddr;
-
-/* Enable pl011 emulation */
-bool vpl011;
-
-/* loader to use for this kernel */
-void (*load)(struct kernel_info *info);
-/* loader specific state */
-union {
-struct {
-paddr_t kernel_addr;
-paddr_t len;
-#ifdef CONFIG_ARM_64
-paddr_t text_offset; /* 64-bit Image only */
-#endif
-paddr_t start; /* 32-bit zImage only */
-} zimage;
-};
-};
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- * ->type
- * ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- * ->mem
- * ->fdt
- *
- * Sets in info:
- * ->entry
- * ->dtb_paddr
- * ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
-#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
new file mode 100644
index 000..33f3e72
--- /dev/null
+++ b/xen/include/asm-arm/kernel.h
@@ -0,0 +1,86 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include
+#include
+
+struct kernel_info {
+#ifdef CONFIG_ARM_64
+enum domain_type type;
+#endif
+
+struct domain *d;
+
+void *fdt; /* flat device tree */
+paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+struct meminfo mem;
+
+/* kernel entry point */
+paddr_t entry;
+
+/* grant table region */
+paddr_t gnttab_start;
+paddr_t gnttab_size;
+
+/* boot blob load addresses */
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const char* cmdline;
+paddr_t dtb_paddr;
+paddr_t initrd_paddr;
+
+/* Enable pl011 emulation */
+bool vpl011;
+
+/* loader to use for this kernel */
+void (*load)(struct kernel_info *info);
+/* loader specific state */
+union {
+struct {
+paddr_t kernel_addr;
+paddr_t len;
+#ifdef CONFIG_ARM_64
+paddr_t text_offset; /* 64-bit Image only */
+#endif
+paddr_t start; /* 32-bit zImage only */
+} zimage;
+};
+};
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ * ->type
+ * ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ * ->mem
+ * ->fdt
+ *
+ * Sets in info:
+ * ->entry
+ *
[Xen-devel] [PATCH v7 21/25] xen/arm: refactor vpl011_data_avail
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- remove forward declaration of vpl011_data_avail
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c | 64 +--
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index ebc045e..68452a8 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -378,30 +378,13 @@ static const struct mmio_handler_ops vpl011_mmio_handler
= {
.write = vpl011_mmio_write,
};
-static void vpl011_data_avail(struct domain *d)
+static void vpl011_data_avail(struct domain *d,
+ XENCONS_RING_IDX in_fifo_level,
+ XENCONS_RING_IDX in_size,
+ XENCONS_RING_IDX out_fifo_level,
+ XENCONS_RING_IDX out_size)
{
-unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
-XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
-XENCONS_RING_IDX in_fifo_level, out_fifo_level;
-
-VPL011_LOCK(d, flags);
-
-in_cons = intf->in_cons;
-in_prod = intf->in_prod;
-out_cons = intf->out_cons;
-out_prod = intf->out_prod;
-
-smp_rmb();
-
-in_fifo_level = xencons_queued(in_prod,
- in_cons,
- sizeof(intf->in));
-
-out_fifo_level = xencons_queued(out_prod,
-out_cons,
-sizeof(intf->out));
/ Update the UART RX state /
@@ -410,11 +393,11 @@ static void vpl011_data_avail(struct domain *d)
vpl011->uartfr &= ~RXFE;
/* Set the FIFO_FULL bit if the Xen buffer is full. */
-if ( in_fifo_level == sizeof(intf->in) )
+if ( in_fifo_level == in_size )
vpl011->uartfr |= RXFF;
/* Assert the RX interrupt if the FIFO is more than half way filled. */
-if ( in_fifo_level >= sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+if ( in_fifo_level >= in_size - SBSA_UART_FIFO_LEVEL )
vpl011->uartris |= RXI;
/*
@@ -427,7 +410,7 @@ static void vpl011_data_avail(struct domain *d)
/ Update the UART TX state /
-if ( out_fifo_level != sizeof(intf->out) )
+if ( out_fifo_level != out_size )
{
vpl011->uartfr &= ~TXFF;
@@ -445,13 +428,38 @@ static void vpl011_data_avail(struct domain *d)
if ( out_fifo_level == 0 )
vpl011->uartfr |= TXFE;
-
-VPL011_UNLOCK(d, flags);
}
static void vpl011_notification(struct vcpu *v, unsigned int port)
{
-vpl011_data_avail(v->domain);
+unsigned long flags;
+struct domain *d = v->domain;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
+XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
+XENCONS_RING_IDX in_fifo_level, out_fifo_level;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+out_cons = intf->out_cons;
+out_prod = intf->out_prod;
+
+smp_rmb();
+
+in_fifo_level = xencons_queued(in_prod,
+ in_cons,
+ sizeof(intf->in));
+
+out_fifo_level = xencons_queued(out_prod,
+out_cons,
+sizeof(intf->out));
+
+vpl011_data_avail(v->domain, in_fifo_level, sizeof(intf->in),
+ out_fifo_level, sizeof(intf->out));
+
+VPL011_UNLOCK(d, flags);
}
int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 13/25] xen/arm: refactor construct_dom0
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- rename __construct_domain to construct_domain
Changes in v4:
- newline and style changes
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- move discard_initial_modules() after __construct_domain()
- remove useless blank line
- leave safety BUG_ONs in __construct_domain
- rename prepare_dtb to prepare_dtb_hwdom
---
xen/arch/arm/domain_build.c | 122
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 957572b..4707f42 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1472,7 +1472,7 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
-static int __init prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
*kinfo)
{
const p2m_type_t default_p2mt = p2m_mmio_direct_c;
const void *fdt;
@@ -2207,73 +2207,29 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
}
-int __init construct_dom0(struct domain *d)
+static int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
{
-struct kernel_info kinfo = {};
struct vcpu *saved_current;
-int rc, i, cpu;
-
+int i, cpu;
struct vcpu *v = d->vcpu[0];
struct cpu_user_regs *regs = >arch.cpu_info->guest_cpu_user_regs;
-/* Sanity! */
-BUG_ON(d->domain_id != 0);
BUG_ON(d->vcpu[0] == NULL);
BUG_ON(v->is_initialised);
-printk("*** LOADING DOMAIN 0 ***\n");
-if ( dom0_mem <= 0 )
-{
-warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
NOW\n");
-dom0_mem = MB(512);
-}
-
-
-iommu_hwdom_init(d);
-
-d->max_pages = ~0U;
-
-kinfo.unassigned_mem = dom0_mem;
-kinfo.d = d;
-
-rc = kernel_probe(, NULL);
-if ( rc < 0 )
-return rc;
-
#ifdef CONFIG_ARM_64
/* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
+if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
{
printk("Platform does not support 32-bit domain\n");
return -EINVAL;
}
-d->arch.type = kinfo.type;
if ( is_64bit_domain(d) )
vcpu_switch_to_aarch64_mode(v);
#endif
-allocate_memory_11(d, );
-find_gnttab_region(d, );
-
-/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-rc = gic_map_hwdom_extra_mappings(d);
-if ( rc < 0 )
-return rc;
-
-rc = platform_specific_mapping(d);
-if ( rc < 0 )
-return rc;
-
-if ( acpi_disabled )
-rc = prepare_dtb(d, );
-else
-rc = prepare_acpi(d, );
-
-if ( rc < 0 )
-return rc;
-
/*
* The following loads use the domain's p2m and require current to
* be a vcpu of the domain, temporarily switch
@@ -2286,20 +2242,18 @@ int __init construct_dom0(struct domain *d)
* kernel_load will determine the placement of the kernel as well
* as the initrd & fdt in RAM, so call it first.
*/
-kernel_load();
+kernel_load(kinfo);
/* initrd_load will fix up the fdt, so call it before dtb_load */
-initrd_load();
-dtb_load();
+initrd_load(kinfo);
+dtb_load(kinfo);
/* Now that we are done restore the original p2m and current. */
set_current(saved_current);
p2m_restore_state(saved_current);
-discard_initial_modules();
-
memset(regs, 0, sizeof(*regs));
-regs->pc = (register_t)kinfo.entry;
+regs->pc = (register_t)kinfo->entry;
if ( is_32bit_domain(d) )
{
@@ -2317,14 +2271,14 @@ int __init construct_dom0(struct domain *d)
*/
regs->r0 = 0; /* SBZ */
regs->r1 = 0x; /* We use DTB therefore no machine id */
-regs->r2 = kinfo.dtb_paddr;
+regs->r2 = kinfo->dtb_paddr;
}
#ifdef CONFIG_ARM_64
else
{
regs->cpsr = PSR_GUEST64_INIT;
/* From linux/Documentation/arm64/booting.txt */
-regs->x0 = kinfo.dtb_paddr;
+regs->x0 = kinfo->dtb_paddr;
regs->x1 = 0; /* Reserved for future use */
regs->x2 = 0; /* Reserved for future use */
regs->x3 = 0; /* Reserved for future use */
@@ -2352,6 +2306,62 @@ int __init construct_dom0(struct domain *d)
return 0;
}
+int __init construct_dom0(struct domain *d)
+{
+struct kernel_info kinfo = {};
+int rc;
+
+/* Sanity! */
+BUG_ON(d->domain_id != 0);
+
+printk("*** LOADING DOMAIN 0 ***\n");
+if (
[Xen-devel] [PATCH v7 16/25] xen/arm: implement construct_domU
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.
Remove #if 0 from allocate_memory as this patch will start using it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- turn %lu into %PRIx64 for arm32 compilation
Changes in v5:
- move changes to kernel_probe prototype to previous patch
- improve commit message
- remove superflous allocation of d->vcpu
- use mem * SZ_1K
Changes in v4:
- constify kernel_probe
- change title
- better error messages and printed info
- 64bit memory
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- rename mem to memory
- make cpus and memory mandatory
- remove wront comment from commit message
- cpus and memory are read as integers
- read the vpl011 option
---
xen/arch/arm/domain_build.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4709683..8d7983a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -369,7 +370,6 @@ static void __init allocate_memory_11(struct domain *d,
}
}
-#if 0
static bool __init allocate_bank_memory(struct domain *d,
struct kernel_info *kinfo,
gfn_t sgfn,
@@ -468,7 +468,6 @@ fail:
" %ldKB unallocated. Fix the VMs configurations.\n",
(unsigned long)kinfo->unassigned_mem >> 10);
}
-#endif
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
@@ -2310,7 +2309,37 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
static int __init construct_domU(struct domain *d,
const struct dt_device_node *node)
{
-return -ENOSYS;
+struct kernel_info kinfo = {};
+int rc;
+u64 mem;
+
+rc = dt_property_read_u64(node, "memory", );
+if ( !rc )
+{
+printk("Error building DomU: cannot read \"memory\" property\n");
+return -EINVAL;
+}
+kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d->max_vcpus,
mem);
+
+if ( vcpu_create(d, 0, 0) == NULL )
+return -ENOMEM;
+d->max_pages = ~0U;
+
+kinfo.d = d;
+
+rc = kernel_probe(, node);
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_ARM_64
+/* type must be set before allocate memory */
+d->arch.type = kinfo.type;
+#endif
+allocate_memory(d, );
+
+return construct_domain(d, );
}
void __init create_domUs(void)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 06/25] xen/arm: introduce bootcmdlines
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only once), but they can still have their separate bootcmdline
entries.
Add a dt_name field to struct bootcmdline to make it easier to find the
correct entry. Store the name of the "xen,domain" compatible node (for
example "Dom1"). This is a better choice compared to the name of the
"multiboot,kernel" compatible node, because their names are not unique.
For instance there can be more than one "module@0x4c00" in the
system, but there can only be one "/chosen/Dom1".
Add a pointer to struct kernel_info to point to the cmdline for a given
kernel.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- code style
- add ack
Changes in v5:
- remove leftover DEBUG message
- improve commit message
- use kinfo->cmdline when possible
- move add_bood_cmdline to setup.c
Changes in v4:
- check that the multiboot node is under /chosen
- use cmd and cmds as variable names for struct bootcmdline and struct
bootcmdline*
- fix printk
- use ASSERT instea of panic
- do not add empty cmdline entries
- add more debug printks to early_print_info
- code style fixes
- add comment on DT_MAX_NAME
- increase DT_MAX_NAME to 41
- make nr_mods unsigned int
Changes in v3:
- introduce bootcmdlines
- do not modify boot_fdt_cmdline
- add comments
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 43 ++---
xen/arch/arm/domain_build.c | 12 ++--
xen/arch/arm/kernel.h | 1 +
xen/arch/arm/setup.c| 47 ++---
xen/include/asm-arm/setup.h | 19 --
5 files changed, 87 insertions(+), 35 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index b1d226f..76693b5 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -172,11 +172,13 @@ static void __init process_multiboot_node(const void
*fdt, int node,
const __be32 *cell;
bootmodule_kind kind;
paddr_t start, size;
-const char *cmdline;
/* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
int len = 92;
char path[92];
-int ret;
+int parent_node, ret;
+
+parent_node = fdt_parent_offset(fdt, node);
+ASSERT(parent_node >= 0);
/* Check that the node is under "/chosen" (first 7 chars of path) */
ret = fdt_get_path(fdt, node, path, len);
@@ -228,17 +230,12 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "bootargs", );
-if ( prop )
-{
-if ( len > BOOTMOD_MAX_CMDLINE )
-panic("module %s command line too long\n", name);
-cmdline = prop->data;
-}
-else
-cmdline = NULL;
+add_boot_module(kind, start, size);
-add_boot_module(kind, start, size, cmdline);
+prop = fdt_get_property(fdt, node, "bootargs", );
+if ( !prop )
+return;
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -284,7 +281,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start, NULL);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start);
}
static int __init early_scan_node(const void *fdt,
@@ -307,6 +304,7 @@ static void __init early_print_info(void)
{
struct meminfo *mi =
struct bootmodules *mods =
+struct bootcmdlines *cmds =
int i, nr_rsvd;
for ( i = 0; i < mi->nr_banks; i++ )
@@ -315,12 +313,12 @@ static void __init early_print_info(void)
mi->bank[i].start + mi->bank[i].size - 1);
printk("\n");
for ( i = 0 ; i < mods->nr_mods; i++ )
-printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s %s\n",
+printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
i,
mods->module[i].start,
mods->module[i].start + mods->module[i].size,
- boot_module_kind_as_string(mods->module[i].kind),
- mods->module[i].cmdline);
+ boot_module_kind_as_string(mods->module[i].kind));
+
nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
for ( i = 0; i < nr_rsvd; i++ )
{
@@ -333,6 +331,11 @@ static void __init early_print_info(void)
i, s, e);
}
printk("\n");
+for ( i = 0 ; i < cmds->nr_mods; i++ )
+printk("CMDLINE[%d]:%s %s\n", i,
+ cmds->cmdline[i].dt_name,
+ >cmdline[i].cmdline[0]);
+printk("\n");
}
/**
@@
[Xen-devel] [PATCH v7 10/25] xen/arm: rename get_11_allocation_size to get_allocation_size
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no change in print messages
- do not remove BUG_ON
Changes in v2:
- new patch
---
xen/arch/arm/domain_build.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 59c9f34..ca0c4f7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
return vcpu_create(dom0, 0, 0);
}
-static unsigned int __init get_11_allocation_size(paddr_t size)
+static unsigned int __init get_allocation_size(paddr_t size)
{
/*
* get_order_from_bytes returns the order greater than or equal to
@@ -249,7 +249,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
int i;
bool lowmem = true;
@@ -301,7 +301,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* If we failed to allocate bank0 under 4GB, continue allocating
* memory from above 4GB and fill in banks.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
{
pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
@@ -312,7 +312,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem && order < min_low_order)
{
D11PRINT("Failed at min_low_order, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -332,7 +332,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem )
{
D11PRINT("Allocation below bank 0, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -347,7 +347,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* Success, next time around try again to get the largest order
* allocation possible.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
}
if ( kinfo->unassigned_mem )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 02/25] xen/arm: extend device tree based multiboot protocol
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- memory is 64bit
Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs
Changes in v2:
- lower case kernel
- rename mem to memory
- mandate cpus and memory
- replace domU-kernel with kernel and domU-ramdisk with ramdisk
- rename xen,domU with xen,domain
- add info about dom0
- switch memory and cpus to integers
- remove defaults
- add vpl011
---
docs/misc/arm/device-tree/booting.txt | 107 ++
1 file changed, 107 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index ce2d0dc..317a9e9 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -119,3 +119,110 @@ For those you would hardcode the Xen commandline in the
DTB under
line by writing bootargs (as for native Linux).
A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
for Dom0 and bootargs for native Linux.
+
+
+Creating Multiple Domains directly from Xen
+===
+
+It is possible to have Xen create other domains, in addition to dom0,
+out of the information provided via device tree. A kernel and initrd
+(optional) need to be specified for each guest.
+
+For each domain to be created there needs to be one node under /chosen
+with the following properties:
+
+- compatible
+
+For domUs: "xen,domain"
+
+- memory
+
+ A 64-bit integer specifying the amount of kilobytes of RAM to
+allocate to the guest.
+
+- cpus
+
+An integer specifying the number of vcpus to allocate to the guest.
+
+- vpl011
+
+An empty property to enable/disable a virtual pl011 for the guest to use.
+
+- #address-cells and #size-cells
+
+Both #address-cells and #size-cells need to be specified because
+both sub-nodes (described shortly) have reg properties.
+
+Under the "xen,domain" compatible node, one or more sub-nodes are present
+for the DomU kernel and ramdisk.
+
+The kernel sub-node has the following properties:
+
+- compatible
+
+"multiboot,kernel"
+
+- reg
+
+Specifies the physical address of the kernel in RAM and its
+length.
+
+- bootargs (optional)
+
+Command line parameters for the guest kernel.
+
+The ramdisk sub-node has the following properties:
+
+- compatible
+
+"multiboot,ramdisk"
+
+- reg
+
+Specifies the physical address of the ramdisk in RAM and its
+length.
+
+
+Example
+===
+
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 131072>;
+cpus = <2>;
+vpl011;
+
+module@0x4a00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4a00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4b00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4b00 0xff>;
+};
+};
+
+domU2 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 65536>;
+cpus = <1>;
+
+module@0x4c00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4c00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4d00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4d00 0xff>;
+};
+};
+};
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 14/25] xen/arm: move unregister_init_virtual_region to init_done
Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index a819953..b0a5e35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -66,6 +66,9 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
static __used void init_done(void)
{
+/* Must be done past setting system_state. */
+unregister_init_virtual_region();
+
free_init_memory();
startup_cpu_idle_loop();
}
@@ -960,9 +963,6 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
-/* Must be done past setting system_state. */
-unregister_init_virtual_region();
-
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 04/25] xen/arm: increase MAX_MODULES
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Doug Goldstein
---
xen/include/asm-arm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0cc3330..f1e4a3f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -8,7 +8,7 @@
#define NR_MEM_BANKS 128
-#define MAX_MODULES 5 /* Current maximum useful modules */
+#define MAX_MODULES 32 /* Current maximum useful modules */
typedef enum {
BOOTMOD_XEN,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 17/25] xen/arm: generate a simple device tree for domUs
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use d->arch.vgic.version
Changes in v4:
- code style
- two separate functions for gicv2 and gicv3
- remove useless local variables
- fix typos
- do not use host address and size cells for the guest DT
- use #define for addrcells and sizecells
Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervisor_node until all Xen related functionalities
(evtchns, grant table, etc.) work correctly
Changes in v2:
- move prepare_dtb rename to previous patch
- use switch for the gic version
- use arm,gic-400 instead of arm,cortex-a15-gic
- add @unit-address in the gic node name
- add comment on DOMU_DTB_SIZE
---
xen/arch/arm/domain_build.c | 235 +++-
1 file changed, 233 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8d7983a..3d33d1f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1034,7 +1034,6 @@ static int __init make_timer_node(const struct domain *d,
void *fdt,
return res;
}
-#ifdef CONFIG_ACPI
/*
* This function is used as part of the device tree generation for Dom0
* on ACPI systems, and DomUs started directly from Xen based on device
@@ -1080,7 +1079,6 @@ static int __init make_chosen_node(const struct
kernel_info *kinfo)
return res;
}
-#endif
static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
bool need_mapping, const char *devname)
@@ -1472,6 +1470,235 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
+static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-400");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICD_BASE, GUEST_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICC_BASE, GUEST_GICC_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V3:
+return make_gicv3_domU_node(d, fdt);
+case GIC_V2:
+return make_gicv2_domU_node(d, fdt);
+default:
+panic("Unsupported GIC version");
+}
+}
+
+static int __init make_timer_domU_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t
[Xen-devel] [PATCH v7 12/25] xen/arm: introduce allocate_memory
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
This is under #if 0 as not used for now.
Signed-off-by: Julien Grall
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- use %pd
- populate bank earlier to remove local variables
Changes in v6:
- turn dprintks into printk
- use panic instead of printk+BUG_ON
- use Julien's implementation of allocate_bank_memory
Changes in v5:
- improve commit message
- code style
- remove unneeded local var
- while loop in allocate_bank_memory to allocate memory so that it
doesn't have to be contiguos
- combile while loops in allocate_memory
Changes in v4:
- move earlier, add #if 0
- introduce allocate_bank_memory, remove insert_bank
- allocate_bank_memory allocate memory and inserts the bank, while
allocate_memory specifies where to do that
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 101
1 file changed, 101 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 66a258a..957572b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -368,6 +368,107 @@ static void __init allocate_memory_11(struct domain *d,
}
}
+#if 0
+static bool __init allocate_bank_memory(struct domain *d,
+ struct kernel_info *kinfo,
+ gfn_t sgfn,
+ unsigned long tot_size)
+{
+int res;
+struct page_info *pg;
+struct membank *bank;
+unsigned int max_order = ~0;
+
+bank = >mem.bank[kinfo->mem.nr_banks];
+bank->start = gfn_to_gaddr(sgfn);
+bank->size = tot_size;
+
+while ( tot_size > 0 )
+{
+unsigned int order = get_allocation_size(tot_size);
+
+order = min(max_order, order);
+
+pg = alloc_domheap_pages(d, order, 0);
+if ( !pg )
+{
+/*
+ * If we can't allocate one page, then it is unlikely to
+ * succeed in the next iteration. So bail out.
+ */
+if ( !order )
+return false;
+
+/*
+ * If we can't allocate memory with order, then it is
+ * unlikely to succeed in the next iteration.
+ * Record the order - 1 to avoid re-trying.
+ */
+max_order = order - 1;
+continue;
+}
+
+res = guest_physmap_add_page(d, sgfn, page_to_mfn(pg), order);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+return false;
+}
+
+sgfn = gfn_add(sgfn, 1UL << order);
+tot_size -= (1ULL << (PAGE_SHIFT + order));
+}
+
+kinfo->mem.nr_banks++;
+kinfo->unassigned_mem -= bank->size;
+
+return true;
+}
+
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+unsigned int i;
+unsigned long bank_size;
+
+printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+kinfo->mem.nr_banks = 0;
+bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
+ bank_size) )
+goto fail;
+
+bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
+ bank_size) )
+goto fail;
+
+if ( kinfo->unassigned_mem )
+goto fail;
+
+for( i = 0; i < kinfo->mem.nr_banks; i++ )
+{
+printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+ d,
+ i,
+ kinfo->mem.bank[i].start,
+ kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ (unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+
+return;
+
+fail:
+panic("Failed to allocate requested domain memory."
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ " %ldKB unallocated. Fix the VMs configurations.\n",
+ (unsigned long)kinfo->unassigned_mem >> 10);
+}
+#endif
+
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 11/25] xen/arm: rename allocate_memory to allocate_memory_11
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ca0c4f7..66a258a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -243,7 +243,8 @@ fail:
* (as described above) we allow higher allocations and continue until
* that runs out (or we have allocated sufficient dom0 memory).
*/
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+ struct kernel_info *kinfo)
{
const unsigned int min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -2152,7 +2153,7 @@ int __init construct_dom0(struct domain *d)
#endif
-allocate_memory(d, );
+allocate_memory_11(d, );
find_gnttab_region(d, );
/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 05/26] xen/arm: check for multiboot nodes only under /chosen
Hi,
On 12/11/2018 21:13, Stefano Stabellini wrote:
> On Fri, 9 Nov 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/9/18 9:38 PM, Stefano Stabellini wrote:
>>> On Fri, 9 Nov 2018, Julien Grall wrote:
Hi,
On 02/11/2018 23:44, Stefano Stabellini wrote:
> Make sure to only look for multiboot compatible nodes only under
> /chosen, not under any other paths (depth <= 3).
>
> Signed-off-by: Stefano Stabellini
>
> ---
>
> Changes in v6:
> - do not proceed if fdt_get_path returns error != -FDT_ERR_NOSPACE
> - remove sizeof, use hardcoded value
>
> Changes in v5:
> - add patch
> - add check on return value of fdt_get_path
> ---
> xen/arch/arm/bootfdt.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 8eba42c..a42fe87 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -173,7 +173,15 @@ static void __init process_multiboot_node(const
> void
> *fdt, int node,
> bootmodule_kind kind;
> paddr_t start, size;
> const char *cmdline;
> -int len;
> +int len = 8; /* sizeof "/chosen" */
> +char path[8];
> +int ret;
> +
> +/* Check that the node is under "chosen" */
> +ret = fdt_get_path(fdt, node, path, len);
> +if ( (ret != 0 && ret != -FDT_ERR_NOSPACE) ||
I don't understand why you specifically check for -FDT_ERR_NOSPACE here.
Looking at fdt_get_path(...) there are case where the function may return
-FDT_ERR_NOSPACE yet not filling up path. So you would end up to compare
garbage.
>>>
>>> I am explicitely checking for -FDT_ERR_NOSPACE because it is a valid
>>> condition in this case: -FDT_ERR_NOSPACE is returned where `path' is not
>>> big enough to contain the full device tree path. It is OK and expected,
>>> given that path is only 8 chars long. So, in case of -FDT_ERR_NOSPACE,
>>> we should continue and do the comparison with "/chosen". For other
>>> errors we should return.
>>
>> Let's take an example with a path called /deadbeef. This will not hold in the
>> variable path. Do you agree that fdt_get_path will return -FDT_ERR_NO_SPACE
>> in
>> that case?
>>
>> AFAIU the function fdt_get_path, the buffer will contain the character
>> / followed by garbage as '\0' is only added in successful path.
>>
>> This also fit with the description of fdt_get_path when -FDT_ERR_NO_SPACE. It
>> does not promise you the buffer will contain anything. It only tells you that
>> the path on the given node will not fit in the buffer.
>>
>> So I still don't think you can assume the behavior you described above.
>
> The lack of '\0' is not an issue, we can still compare the content with
> strncmp even if '\0' is missing.
The problem is not really because of '\0' is missing but the fact you
may not have 8 valid characters in the buffer. In some case, you will
only have one, yet you compare with a 8 characters string.
> But you are right, the description is
> not clear about the content of `path' if -FDT_ERR_NO_SPACE is returned.
> It doesn't clearly say that the content is still guaranteed to be
> properly populated until the end of `buf'.
>
> If we don't want to rely on the implementation of fdt_get_path to still
> populate the content in case of -FDT_ERR_NO_SPACE,
I would have been happy to just update the documentation but the code
does not seem match that behavior (see above). If you can prove me the
case I gave can work perfectly, then I might reconsider it.
then we'll have to
> allocate roughtly DT_MAX_NAME*3 = 41*3 chars for path.
> Technically I think it would be DT_MAX_NAME*2+6 ("chosen") +3 ('/' three
> times) + ('\0') = 92. We could use 100 chars to stay on the safe side.
I would prefer the 92 characters with a comment on top. This is quite
unlikely to hit it.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 05/26] xen/arm: check for multiboot nodes only under /chosen
On Fri, 9 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/9/18 9:38 PM, Stefano Stabellini wrote:
> > On Fri, 9 Nov 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 02/11/2018 23:44, Stefano Stabellini wrote:
> > > > Make sure to only look for multiboot compatible nodes only under
> > > > /chosen, not under any other paths (depth <= 3).
> > > >
> > > > Signed-off-by: Stefano Stabellini
> > > >
> > > > ---
> > > >
> > > > Changes in v6:
> > > > - do not proceed if fdt_get_path returns error != -FDT_ERR_NOSPACE
> > > > - remove sizeof, use hardcoded value
> > > >
> > > > Changes in v5:
> > > > - add patch
> > > > - add check on return value of fdt_get_path
> > > > ---
> > > >xen/arch/arm/bootfdt.c | 14 +++---
> > > >1 file changed, 11 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > > > index 8eba42c..a42fe87 100644
> > > > --- a/xen/arch/arm/bootfdt.c
> > > > +++ b/xen/arch/arm/bootfdt.c
> > > > @@ -173,7 +173,15 @@ static void __init process_multiboot_node(const
> > > > void
> > > > *fdt, int node,
> > > >bootmodule_kind kind;
> > > >paddr_t start, size;
> > > >const char *cmdline;
> > > > -int len;
> > > > +int len = 8; /* sizeof "/chosen" */
> > > > +char path[8];
> > > > +int ret;
> > > > +
> > > > +/* Check that the node is under "chosen" */
> > > > +ret = fdt_get_path(fdt, node, path, len);
> > > > +if ( (ret != 0 && ret != -FDT_ERR_NOSPACE) ||
> > >
> > > I don't understand why you specifically check for -FDT_ERR_NOSPACE here.
> > >
> > > Looking at fdt_get_path(...) there are case where the function may return
> > > -FDT_ERR_NOSPACE yet not filling up path. So you would end up to compare
> > > garbage.
> >
> > I am explicitely checking for -FDT_ERR_NOSPACE because it is a valid
> > condition in this case: -FDT_ERR_NOSPACE is returned where `path' is not
> > big enough to contain the full device tree path. It is OK and expected,
> > given that path is only 8 chars long. So, in case of -FDT_ERR_NOSPACE,
> > we should continue and do the comparison with "/chosen". For other
> > errors we should return.
>
> Let's take an example with a path called /deadbeef. This will not hold in the
> variable path. Do you agree that fdt_get_path will return -FDT_ERR_NO_SPACE in
> that case?
>
> AFAIU the function fdt_get_path, the buffer will contain the character
> / followed by garbage as '\0' is only added in successful path.
>
> This also fit with the description of fdt_get_path when -FDT_ERR_NO_SPACE. It
> does not promise you the buffer will contain anything. It only tells you that
> the path on the given node will not fit in the buffer.
>
> So I still don't think you can assume the behavior you described above.
The lack of '\0' is not an issue, we can still compare the content with
strncmp even if '\0' is missing. But you are right, the description is
not clear about the content of `path' if -FDT_ERR_NO_SPACE is returned.
It doesn't clearly say that the content is still guaranteed to be
properly populated until the end of `buf'.
If we don't want to rely on the implementation of fdt_get_path to still
populate the content in case of -FDT_ERR_NO_SPACE, then we'll have to
allocate roughtly DT_MAX_NAME*3 = 41*3 chars for path.
Technically I think it would be DT_MAX_NAME*2+6 ("chosen") +3 ('/' three
times) + ('\0') = 92. We could use 100 chars to stay on the safe side.
Is that OK for you?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-qemuu-nested-amd
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-qemuu-nested-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 24ccea7e102de8cbc93ab3befb123bbd18532be9 Bug not present: 58a0228707870c8330917f919804986855443a19 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129864/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-qemuu-nested-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-qemuu-nested-amd.xen-boot --summary-out=tmp/129864.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-amd64-qemuu-nested-amd xen-boot Searching for failure / basis pass: 129680 fail [host=pinot1] / 128945 ok. Failure / basis pass flights: 129680 / 128945 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be Basis pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 92666fdd6e0afab989b2d89759d9b43f2c645ae7 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#58a0228707870c8330917f919804986855443a19-24ccea7e102de8cbc93ab3befb123bbd18532be9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#92666fdd6e0afab989b2d89759d9b43f2c645ae7-2cf113891a38cc05434bc9876ffc107a990887be adhoc-revtuple-generator: tree discontiguous: linux-2.6 Loaded 2005 nodes in revision graph Searching for test results: 128663 pass irrelevant 128727 pass irrelevant 128861 pass irrelevant 128835 pass irrelevant 128885 pass irrelevant 128920 pass irrelevant 128945 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 92666fdd6e0afab989b2d89759d9b43f2c645ae7 128970 fail irrelevant 129005 fail irrelevant 129072 fail irrelevant 129167 fail irrelevant 129258 fail irrelevant 129304 fail irrelevant 129389 fail irrelevant 129348 fail irrelevant 129417 fail irrelevant 129530 fail irrelevant 129460 fail irrelevant 129680 fail 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be 129830 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 46029da12e5efeca6d957e5793bd34f2965fa0a1 129848 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be 129864 fail 24ccea7e102de8cbc93ab3befb123bbd18532be9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 2cf113891a38cc05434bc9876ffc107a990887be 129835 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 c238ea3f4caccf36ab1a559f958cbe5192327f6a 129837 pass 58a0228707870c8330917f919804986855443a19 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798
[Xen-devel] [xen-unstable-smoke test] 129861: regressions - FAIL
flight 129861 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129852
build-armhf 6 xen-buildfail REGR. vs. 129852
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
baseline version:
xen 94bd9df0f7efad8038d99ec52ba56ecec4191248
Last test of basis 129852 2018-11-12 16:00:37 Z0 days
Testing same since 129861 2018-11-12 19:00:52 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Daniel De Graaf
Jan Beulich
Roger Pau Monné
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf fail
build-amd64-libvirt blocked
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf
Date: Fri Nov 2 13:46:11 2018 -0400
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
Acked-by: Andrew Cooper
commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper
Date: Thu Oct 18 11:30:27 2018 +0100
x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
NX support in the host is required for the shadow pagetable code to handle
SMAP correctly for guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper
Date: Thu Jul 19 16:51:57 2018 +0100
tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper
Date: Thu Jul 19 16:50:03 2018 +0100
libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure
definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné
Date: Mon Nov 12 17:14:57 2018 +0100
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the trampoline stack.
Fix this by always reserving the low 1MB regardless of whether Xen is
running as a guest or natively.
Reported-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Reviewed-by: Wei Liu
commit c6aae55786e138951daf25e14709895d8c166948
Author: Roger Pau Monné
Date: Mon Nov 12 17:13:57 2018 +0100
guest/pvh: fix handling of multiboot module list
When booting
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
On 11/12/18 4:35 PM, Mirela Simonovic wrote: Hi Julien, Thanks for your feedback, I'll need to answer in iterations. On Mon, Nov 12, 2018 at 4:27 PM Julien Grall wrote: Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: The implementation consists of: -Adding PSCI system suspend call as new PSCI function -Trapping PSCI system_suspend HVC -Implementing PSCI system suspend call (virtual interface that allows guests to suspend themselves) The PSCI system suspend should be called by a guest from its boot VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI CPU_OFF call prior to issuing PSCI system suspend. Interrupts that are left enabled by the guest are assumed to be its wake-up interrupts. Therefore, a wake-up interrupt triggers the resume of the guest. Guest should resume regardless of the state of Xen (suspended or not). When a guest calls PSCI system suspend the respective domain will be suspended if the following conditions are met: 1) Given resume entry point is not invalid 2) Other (if any) VCPUs of the calling guest are hot-unplugged If the conditions above are met the calling domain is labeled as suspended and the calling VCPU is blocked. If nothing else wouldn't be done the suspended domain would resume from the place where it called PSCI system suspend. This is expected if processing of the PSCI system suspend call fails. However, in the case of success the calling guest should resume (continue execution after the wake-up) from the entry point which is given as the first argument of the PSCI system suspend call. In addition to the entry point, the guest expects to start within the environment whose state matches the state after reset. This means that the guest should find reset register values, MMU disabled, etc. Thereby, the context of VCPU should be 'reset' (as if the system is comming out of reset), the program counter should contain entry point, which is 1st argument, and r0/x0 should contain context ID which is 2nd argument of PSCI system suspend call. The context of VCPU is set accordingly when the PSCI system suspend is processed, so that nothing needs to be done on resume/wake-up path. However, in order to ensure that this context doesn't get overwritten by the scheduler when scheduling out this VCPU (would normally happen after the calling CPU is blocked), we need to check whether to return early from ctxt_switch_from(). There are variables in domain structure to keep track of domain shutdown. One of existing shutdown reason is 'suspend' which this patch is using to track the suspend state of a domain. Those variables are used to determine whether to early return from ctxt_switch_from() or not. A suspended domain will resume after the Xen receives an interrupt which is targeted to the domain, unblocks the domain's VCPU, and schedules it in. When the VCPU is scheduled in, the VCPU context is already reset, and contains the right resume entry point in program counter that will be restored in ctxt_switch_to(). The only thing that needs to be done at this point is to clear the variables that marked the domain state as suspended. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- Changes in v2: -Fix print to compile for arm32 and to align with Xen coding style --- xen/arch/arm/Makefile| 1 + xen/arch/arm/domain.c| 13 +++ xen/arch/arm/suspend.c | 166 +++ xen/arch/arm/vpsci.c | 19 + xen/include/asm-arm/perfc_defn.h | 1 + xen/include/asm-arm/psci.h | 2 + xen/include/asm-arm/suspend.h| 16 xen/include/xen/sched.h | 1 + 8 files changed, 219 insertions(+) create mode 100644 xen/arch/arm/suspend.c create mode 100644 xen/include/asm-arm/suspend.h diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 23c5d9adbc..744b1a4dc8 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -43,6 +43,7 @@ obj-y += setup.o obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o +obj-y += suspend.o obj-y += sysctl.o obj-y += time.o obj-y += traps.o diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index e594b48d81..7f8105465c 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) if ( is_idle_vcpu(p) ) return; +/* VCPU's context should not be saved if its domain is suspended */ +if ( p->domain->is_shut_down && +(p->domain->shutdown_code == SHUTDOWN_suspend) ) +return; SHUTDOWN_suspend is used in Xen for other purpose (see SCHEDOP_shutdown). The other user of that code relies on all the state to be saved on suspend. We just need a flag to mark a domain as suspended, and I do believe SHUTDOWN_suspend is not used anywhere else. Let's come back on this. See Andrew's comment here. However, what is the issue with saving all the registers here?
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
Hi Andrew, On 11/12/18 4:41 PM, Andrew Cooper wrote: On 12/11/18 16:35, Mirela Simonovic wrote: diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index e594b48d81..7f8105465c 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) if ( is_idle_vcpu(p) ) return; +/* VCPU's context should not be saved if its domain is suspended */ +if ( p->domain->is_shut_down && +(p->domain->shutdown_code == SHUTDOWN_suspend) ) +return; SHUTDOWN_suspend is used in Xen for other purpose (see SCHEDOP_shutdown). The other user of that code relies on all the state to be saved on suspend. We just need a flag to mark a domain as suspended, and I do believe SHUTDOWN_suspend is not used anywhere else. Let's come back on this. SHUTDOWN_suspend is used for migration. Grep for it through the Xen tree and you'll find several pieces of documentation, including the description of what this shutdown code means. What you are introducing here is not a shutdown - it is a suspend with the intent to resume executing later. As such, it shouldn't use Xen's shutdown infrastructure, which exists mainly to communicate with the toolstack. Would domain pause/unpause be a better solution? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
(+ Andre) On 11/12/18 5:42 PM, Mirela Simonovic wrote: Hi Julien, On Mon, Nov 12, 2018 at 6:00 PM Julien Grall wrote: On 11/12/18 4:52 PM, Mirela Simonovic wrote: Hi Julien, Hi, Thanks for the feedback. On Mon, Nov 12, 2018 at 4:36 PM Julien Grall wrote: Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: GIC and virtual timer context must be saved when the domain suspends. Please provide the rationale for this. Is it required by the spec? This is required for GIC because a guest leaves enabled interrupts in the GIC that could wake it up, and on resume it should be able to detect which interrupt woke it up. Without saving/restoring the state of GIC this would not be possible. I am confused. In patch #10, you save the GIC host because the GIC can be powered-down. Linux is also saving the GIC state. So how the interrupt can come up if the GIC is powered down? After Xen (or Linux in the config without Xen) hands over the control to EL3 on suspend (calls system suspend PSCI to EL3), it leaves enabled interrupts that are its wake-up sources. Saving a GIC state only means that its current configuration will be remembered somewhere in data structures, but the configuration is not changed on suspend. Everything that happens with interrupt configuration from this point on is platform specific. Now there are 2 options: 1) EL3 will never allow CPU0 to be powered down and the wake-up interrupt will indeed propagate via GIC; or 2) CPU0 will be powered down and the GIC may be powered down as well, so an external help is needed to deal with wake-up and resume (e.g. in order to react to a wake-up interrupt while the GIC is down, and power up CPU0). This external help is provided by some low-power processor outside of the Cortex-A cluster. So the platform firmware is responsible for properly configuring a wake-up path if GIC goes down. This is commonly handled by EL3 communicating with low-power processor. When the GIC power comes up, the interrupt triggered by a peripheral is still active and the software on Cortex-A cluster should be able to observe it once the GIC state is restored, i.e. interrupts get enabled at GIC. Thank you for the explanation. Now the question is why can't we reset at least the GIC CPU interface? AFAIU, the guest should restore them in any case. The only things we need to know is the interrupt was received for a given guest. We can then queue it and wake-up the domain. This seems to fit with the description on top of gic_dist_save() in Linux GICv2 driver. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/badpage: Fix badpage->order overflow
On 12/11/18 09:54, Jan Beulich wrote: On 09.11.18 at 15:42, wrote: >> For order 32 or more, the shift will truncate. Spotted by Coverity. > I find this pretty absurd. What about order 64 or more? Are you > suggesting you expect 16Tb or larger bad page ranges? > >> Signed-off-by: Andrew Cooper > Anyway, as I don't mind the adjustment > Acked-by: Jan Beulich > > But I'm sure you're aware we have many more examples of > 1U (or even plain 1) getting shifted by an order value. There is nothing absurd here. The complaint is that there are two parts of a single calculation at different widths, where C's integer promotion rules results in code which reads correctly, but behaves incorrectly. If badpage->mfn was uint32_t, there would be no complaint, because all parts of the expression would be evaluated at the same width. This complaint is only because you've got a 32bit shift, and a 64bit addition. As for likelihood, I really hope we don't need mark a 16Tb range as bad, but given the ability to express this, would you really notice that the result was subtly wrong? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129852: tolerable all pass - PUSHED
flight 129852 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129852/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 94bd9df0f7efad8038d99ec52ba56ecec4191248 baseline version: xen 3b439f636ee9a9588203cf0aa0edfa18ccdc60b9 Last test of basis 129846 2018-11-12 13:03:01 Z0 days Testing same since 129852 2018-11-12 16:00:37 Z0 days1 attempts People who touched revisions under test: Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm 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 : To xenbits.xen.org:/home/xen/git/xen.git 3b439f636e..94bd9df0f7 94bd9df0f7efad8038d99ec52ba56ecec4191248 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] xen: use SYMBOL everywhere
On Mon, 12 Nov 2018, Julien Grall wrote: > Hi Stefano, > > On 11/8/18 10:27 PM, Stefano Stabellini wrote: > > On Thu, 8 Nov 2018, Jan Beulich wrote: > > > > > > On 06.11.18 at 23:05, wrote: > > > > Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it > > > > is required when comparing and subtracting pointers [1], but use it > > > > everywhere to avoid confusion. > > > > > > I think using it when not needed is causing more confusion. Also > > > why would you then not use it on all other data symbols? The > > > patch will end up quite a bit more reasonable in size once you drop > > > the unnecessary changes. > > > > OK, I am happy to do that. It will probably be better that way. > > > > > > > > --- > > > > xen/arch/arm/alternative.c | 7 ++-- > > > > xen/arch/arm/arm32/livepatch.c | 2 +- > > > > xen/arch/arm/arm64/livepatch.c | 2 +- > > > > xen/arch/arm/domain_build.c | 2 +- > > > > xen/arch/arm/livepatch.c| 6 +-- > > > > xen/arch/arm/mm.c | 17 > > > > xen/arch/arm/setup.c| 8 ++-- > > > > xen/arch/x86/setup.c| 79 > > > > +++-- > > > > xen/arch/x86/tboot.c| 12 +++--- > > > > xen/arch/x86/x86_64/machine_kexec.c | 4 +- > > > > xen/drivers/vpci/vpci.c | 7 +++- > > > > xen/include/asm-arm/grant_table.h | 3 +- > > > > xen/include/asm-arm/mm.h| 4 +- > > > > xen/include/asm-x86/mm.h| 4 +- > > > > xen/include/xen/kernel.h| 24 +-- > > > > 15 files changed, 97 insertions(+), 84 deletions(-) > > > > > > Just like for v2: Did you really check you caught them all? The vPCI > > > ones I had pointed at back then were only an example. Another > > > example now is xen/common/kernel.c:_cmdline_parse(). > > > > It is difficult to catch them all. Any suggestion on how to make sure > > there are no leftover (other than waiting for the next QAVerify scan)? > > The webpage [1] seems to suggest coverity would be able to catch the undefined > behavior fixed in that patch. > > I am not sure what version of coverity is used to analyze Xen, but it probably > worth to have a try. > > Cheers, > > [1] > https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array To do this, I would need to be able to create a special branch with my fixes for Coverity to use. However, I don't have "write access" to any Xen Project Coverity instances at the moment. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 07/44] x86emul: also allow running the 32-bit harness on a 64-bit distro
On 25/09/18 14:29, Jan Beulich wrote: > In order to be able to verify the 32-bit variant builds and runs, > introduce a respective target (and the necessary other adjustments). > > Signed-off-by: Jan Beulich I tried this, but got: make: Entering directory '/local/xen.git/tools/tests/x86_emulator/32' gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -m32 -I/local/xen.git/tools/tests/x86_emulator/32/../../../../tools/include -I. -D__XEN_TOOLS__ -c -g -o x86-emulate.o ../x86-emulate.c gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -m32 -I/local/xen.git/tools/tests/x86_emulator/32/../../../../tools/include -I. -o test_x86_emulator x86-emulate.o ../test_x86_emulator.o ../evex-disp8.o ../wrappers.o /usr/bin/ld: i386:x86-64 architecture of input file `../test_x86_emulator.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../evex-disp8.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../wrappers.o' is incompatible with i386 output collect2: error: ld returned 1 exit status ../Makefile:153: recipe for target 'test_x86_emulator' failed > --- > v4: Moved ahead in series. > v3: New. > > --- a/.gitignore > +++ b/.gitignore > @@ -240,6 +240,7 @@ tools/security/xensec_tool > tools/tests/depriv/depriv-fd-checker > tools/tests/x86_emulator/*.bin > tools/tests/x86_emulator/*.tmp > +tools/tests/x86_emulator/32/x86_emulate > tools/tests/x86_emulator/3dnow*.[ch] > tools/tests/x86_emulator/asm > tools/tests/x86_emulator/avx*.[ch] > --- /dev/null > +++ b/tools/tests/x86_emulator/32/Makefile > @@ -0,0 +1,4 @@ > +override XEN_COMPILE_ARCH := x86_32 > +XEN_ROOT = $(CURDIR)/../../../.. > +VPATH += .. > +include ../Makefile > --- a/tools/tests/x86_emulator/Makefile > +++ b/tools/tests/x86_emulator/Makefile > @@ -1,5 +1,7 @@ > > +ifeq ($(XEN_ROOT),) > XEN_ROOT=$(CURDIR)/../../.. > +endif How about ?= ? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
Hi Julien, On Mon, Nov 12, 2018 at 6:00 PM Julien Grall wrote: > > > > On 11/12/18 4:52 PM, Mirela Simonovic wrote: > > Hi Julien, > > Hi, > > > Thanks for the feedback. > > > > On Mon, Nov 12, 2018 at 4:36 PM Julien Grall wrote: > >> > >> Hi Mirela, > >> > >> On 11/12/18 11:30 AM, Mirela Simonovic wrote: > >>> GIC and virtual timer context must be saved when the domain suspends. > >> > >> Please provide the rationale for this. Is it required by the spec? > >> > > > > This is required for GIC because a guest leaves enabled interrupts in > > the GIC that could wake it up, and on resume it should be able to > > detect which interrupt woke it up. Without saving/restoring the state > > of GIC this would not be possible. > > I am confused. In patch #10, you save the GIC host because the GIC can > be powered-down. Linux is also saving the GIC state. So how the > interrupt can come up if the GIC is powered down? > After Xen (or Linux in the config without Xen) hands over the control to EL3 on suspend (calls system suspend PSCI to EL3), it leaves enabled interrupts that are its wake-up sources. Saving a GIC state only means that its current configuration will be remembered somewhere in data structures, but the configuration is not changed on suspend. Everything that happens with interrupt configuration from this point on is platform specific. Now there are 2 options: 1) EL3 will never allow CPU0 to be powered down and the wake-up interrupt will indeed propagate via GIC; or 2) CPU0 will be powered down and the GIC may be powered down as well, so an external help is needed to deal with wake-up and resume (e.g. in order to react to a wake-up interrupt while the GIC is down, and power up CPU0). This external help is provided by some low-power processor outside of the Cortex-A cluster. So the platform firmware is responsible for properly configuring a wake-up path if GIC goes down. This is commonly handled by EL3 communicating with low-power processor. When the GIC power comes up, the interrupt triggered by a peripheral is still active and the software on Cortex-A cluster should be able to observe it once the GIC state is restored, i.e. interrupts get enabled at GIC. > > For timer, my understanding is that vtimer accounts for how long the > > guest was executing and this tracking should not be affected by the > > suspend/resume sequence. Without saving/restoring the state of vtimer, > > the time tracking would be affected by the suspend/resume. > > Currently, vtimer does not take such things into account. It only setup > a timer in Xen to wake up the guest later on. > > > Hope this is ok, I'll add it to the commit message. > > > >>> This is done by moving the respective code in ctxt_switch_from() > >>> before the return that happens if the domain suspended. > >>> > >>> Signed-off-by: Mirela Simonovic > >>> Signed-off-by: Saeed Nowshadi > >>> --- > >>>xen/arch/arm/domain.c | 14 +++--- > >>>1 file changed, 7 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > >>> index 7f8105465c..bebe3238e8 100644 > >>> --- a/xen/arch/arm/domain.c > >>> +++ b/xen/arch/arm/domain.c > >>> @@ -97,6 +97,13 @@ static void ctxt_switch_from(struct vcpu *p) > >>>if ( is_idle_vcpu(p) ) > >>>return; > >>> > >>> +/* VGIC */ > >>> +gic_save_state(p); > >>> + > >>> +/* Arch timer */ > >>> +p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1); > >>> +virt_timer_save(p); > >>> + > >>>/* VCPU's context should not be saved if its domain is suspended */ > >> > >> The GIC and timer are part of the vCPU context. So this comment looks a > >> bit stale. > > > > It's not stale, but incorrect in that perspective. The comment should > > be updated to "VCPU architecture specific context should ..." > > But the timer is part of the architecture... > > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 06/11] libxl_exec: Add libxl__spawn_initiate_failure
Anthony PERARD writes ("[PATCH v6 06/11] libxl_exec: Add
libxl__spawn_initiate_failure"):
> This function can be used by user of libxl__spawn_* when they setup a
> notification other than xenstore. The parent can already report success
> via libxl__spawn_initiate_detach(), this new function can be used for
> failure instead of waiting for the timeout.
...
> + * ... It
> + * is possible for a spawn to fail for multiple reasons, for example
> + * call(s) to libxl__spawn_initiate_failure and also for some other reason.
> + * In that case the first rc value from any source will take precedence.
But your patch does not make this true, because an rc value from
libxl__spawn_initiate_failure may be overwritten by a later call to
spawn_fail.
And the reason you have written this (latent, probably as far as the
application is currently concerned) bug is that:
> +void libxl__spawn_initiate_failure(libxl__gc *gc, libxl__spawn_state *ss,
> + int rc)
> +/* The spawn state must be Attached on entry and will be Attached Failed
> + * on return. */
> +{
> +assert(rc);
> +if (!ss->rc)
> +ss->rc = rc;
> +spawn_detach(gc, ss);
> +}
This is an open-coded copy of spawn_fail. If you hadn't written a
copy of it, you would have changed the rc squashing in spawn_fail too.
I think libxl__spawn_initiate_failure and spawn_fail need to be two
names for the same function.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/11] libxl: Design of an async API to issue QMP commands to QEMU
Anthony PERARD writes ("[PATCH v6 04/11] libxl: Design of an async API to issue
QMP commands to QEMU"):
> All the functions will be implemented in later patches.
>
> This patch includes the API that libxl can use to send QMP commands to
> QEMU.
...
> Rewrite the comment about the callback, and explain that on error,
> the `ev` may be Idle or may still be Connected
This is good, thanks.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129847: regressions - FAIL
flight 129847 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129847/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 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 build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf 246604e3a46db5a5746a082df0465b37f45c039b baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z6 days Failing since129526 2018-11-06 20:49:26 Z5 days 35 attempts Testing same since 129847 2018-11-12 13:41:25 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 794 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 03/11] libxl_qmp: Change qmp_qemu_check_version to compare version
Anthony PERARD writes ("[PATCH v6 03/11] libxl_qmp: Change
qmp_qemu_check_version to compare version"):
> This patch makes the function simpler to read. It also add the ability
> for a caller to tell if QEMU is newer or have the exact version.
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 02/11] libxl_qmp: Separate QMP message generation from qmp_send_prepare
Thanks for the repost. I feel I am going to make some comments which
could perhaps have been made earlier, so sorry for that:
Anthony PERARD writes ("[PATCH v6 02/11] libxl_qmp: Separate QMP message
generation from qmp_send_prepare"):
> v6:
> comment about ownership of buf
This is good. But:
> -static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
> - const char *cmd, libxl__json_object *args,
> - qmp_callback_t callback, void *opaque,
> - qmp_request_context *context)
Previously this function returned memory allocated from malloc, and
this was not documented. I think it should be, for both this and for
qmp_prepare_cmd. See the big libxl.h comment on "memory allocation".
> @@ -608,6 +607,32 @@ static char *qmp_send_prepare(libxl__gc *gc,
> libxl__qmp_handler *qmp,
> s = yajl_gen_get_buf(hand, , );
>
> if (s) {
> +goto out;
> +}
Should there be a log message here ? If not, maybe you just meant
if (s) goto out;
In libxl_json.c we find the pattern is usually:
if (s != yajl_gen_status_ok) goto out;
but I guess we can hardcode the assumption that yajl_gen_status_ok==0.
> +ret = libxl__sprintf(NOGC, "%*.*s\r\n", (int)len, (int)len, buf);
> +len += 2;
Please use %n to get the length, instead. This kind of ad-hoc
addition encodes the buffer usage information in two disjoint places
and can easily result in buffer length bugs when the code is later
modified.
> static int qmp_send(libxl__qmp_handler *qmp,
> @@ -641,7 +663,8 @@ static int qmp_send(libxl__qmp_handler *qmp,
> int rc = -1;
> GC_INIT(qmp->ctx);
>
> -buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context);
> +buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context,
> + NULL);
>
> if (buf == NULL) {
> goto out;
> @@ -650,12 +673,10 @@ static int qmp_send(libxl__qmp_handler *qmp,
> if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
> "QMP command", "QMP socket"))
> goto out;
> -if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
> -"CRLF", "QMP socket"))
> -goto out;
>
> rc = qmp->last_id_used;
> out:
> +free(buf);
This patch seems to be a mixture of four things:
1. Changing the return value convention of qmp_send_prepare
to expect the caller to free it.
2. Changing qmp_send_prepare to include the \r\n
3. Splitting qmp_prepare_cmd out from qmp_send_prepare
4. Changing qmp_send_prepare to tell the caller the length
Overall I think there is supposed to be no functional change ?
This should be mentioned in the commit message.
I appreciate that these four things are small, perhaps too small to
split out, but they should all be mentioned in the commit message.
And then, the reasons for these changes are unstated. AFAICT:
3 is wanted because we are going to have a new caller which wants to
handle the sending itself. Fine.
2 is wanted because every caller will want this, so it should be done
in the common function.
1 is wanted because 2 demands it.
4 ??? The existing code uses strlen. JSON can't contain nul bytes.
Why should the new caller not do similarly ? If the use of strlen is
wrong why not change the old caller ? (Maybe it is going away, in
which case that needs to be mentioned.)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn
Hi, On 11/12/18 4:58 PM, Andrii Anisov wrote: What's wrong with including clean-up patch in a series adding a feature? I do not mean it is wrong. Just assuming that introducing a new feature and cleaning up a code might be different processes with a different review period. We don't have different process nor different review period between clean-up and new feature. I tend to do clean-up when writing new features... See my cacheflush series as well. If the clean-up is small then I will append/prepend to the feature series. This patch modify a function that was called by this patch and therefore depends on the rest of the series. This was written with this series so it makes sense to me to do it together as it dictates the order I would like the patches applied and simplify tracking (I have many series in flight). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
On 11/12/18 4:52 PM, Mirela Simonovic wrote: Hi Julien, Hi, Thanks for the feedback. On Mon, Nov 12, 2018 at 4:36 PM Julien Grall wrote: Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: GIC and virtual timer context must be saved when the domain suspends. Please provide the rationale for this. Is it required by the spec? This is required for GIC because a guest leaves enabled interrupts in the GIC that could wake it up, and on resume it should be able to detect which interrupt woke it up. Without saving/restoring the state of GIC this would not be possible. I am confused. In patch #10, you save the GIC host because the GIC can be powered-down. Linux is also saving the GIC state. So how the interrupt can come up if the GIC is powered down? For timer, my understanding is that vtimer accounts for how long the guest was executing and this tracking should not be affected by the suspend/resume sequence. Without saving/restoring the state of vtimer, the time tracking would be affected by the suspend/resume. Currently, vtimer does not take such things into account. It only setup a timer in Xen to wake up the guest later on. Hope this is ok, I'll add it to the commit message. This is done by moving the respective code in ctxt_switch_from() before the return that happens if the domain suspended. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- xen/arch/arm/domain.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 7f8105465c..bebe3238e8 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -97,6 +97,13 @@ static void ctxt_switch_from(struct vcpu *p) if ( is_idle_vcpu(p) ) return; +/* VGIC */ +gic_save_state(p); + +/* Arch timer */ +p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1); +virt_timer_save(p); + /* VCPU's context should not be saved if its domain is suspended */ The GIC and timer are part of the vCPU context. So this comment looks a bit stale. It's not stale, but incorrect in that perspective. The comment should be updated to "VCPU architecture specific context should ..." But the timer is part of the architecture... Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 01/11] libxl: Enhance libxl__sendmsg_fds to deal with EINTR and EWOULDBLOCK
Anthony PERARD writes ("[PATCH v6 01/11] libxl: Enhance libxl__sendmsg_fds to
deal with EINTR and EWOULDBLOCK"):
> This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
> EINTR error.
>
> This patch also allow a caller of libxl__sendmsg_fds to deal with
> EWOULDBLOCK. It is best to only sent one byte when dealing with
> non-blocking fds so a EWOULDBLOCK error would mean that the fds haven't
> been sent yet.
This restriction is more than "it is best" - violating it can result
in an assertion failure. I think it should be documented here:
> -/* on failure, logs */
> +/* returns ERROR_NOT_READY on EWOULDBLOCK
> + * or logs on failure. */
I looked at the actual code:
> -r = sendmsg(carrier, , 0);
> -if (r < 0) {
> -LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
> -return ERROR_FAIL;
> -}
> +while (1) {
> +r = sendmsg(carrier, , 0);
> +if (r < 0) {
> +if (errno == EINTR)
> +continue;
> +if (errno == EWOULDBLOCK) {
> +assert(datalen == 1);
> +return ERROR_NOT_READY;
> +}
> +LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
> +return ERROR_FAIL;
> +}
> +break;
> +};
The previous code didn't check that the return value was as expected.
So the function could never be safely called with r!=1 since sendmsg
might report a short write, and libxl__sendmsg_fds wouldn't notice.
Now you have the opportunity to fix this...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn
> What's wrong with including clean-up patch in a series adding a feature? I do not mean it is wrong. Just assuming that introducing a new feature and cleaning up a code might be different processes with a different review period. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 10/11] libxl: Change libxl__domain_suspend_device_model() to be async
This create an extra step for the two call sites of the function.
libxl__domain_suspend_device_model() in this patch gets an extra error
variable (there is ret and rc), but ret goes away in the next patch.
Signed-off-by: Anthony PERARD
---
libxl_domain_soft_reset() haven't been tested, as it doesn't appear to
possible to call the function from xl.
---
Notes:
v6:
fix multiple way to report errors,
libxl__domain_suspend_device_model will now only report via
callbacks, and return void
add rc in libxl__domain_suspend_device_model (ret isn't a proper rc
as libxl__qmp_save don't return one)
tools/libxl/libxl_create.c | 35 +---
tools/libxl/libxl_dom_suspend.c | 36 -
tools/libxl/libxl_internal.h| 7 +--
3 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fcbe36feba..47d95dda4a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1759,6 +1759,9 @@ error:
domcreate_complete(egc, >dcs, rc);
}
+static void soft_reset_dm_suspended(libxl__egc *egc,
+libxl__domain_suspend_state *dsps,
+int rc);
static int do_domain_soft_reset(libxl_ctx *ctx,
libxl_domain_config *d_config,
uint32_t domid_soft_reset,
@@ -1841,11 +1844,24 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
goto out;
}
-rc = libxl__domain_suspend_device_model(gc, >dsps);
-if (rc) {
-LOGD(ERROR, domid_soft_reset, "failed to suspend device model.");
-goto out;
-}
+dss->dsps.ao = ao;
+dss->dsps.callback_device_model_done = soft_reset_dm_suspended;
+libxl__domain_suspend_device_model(egc, >dsps); /* must be last */
+
+return AO_INPROGRESS;
+
+ out:
+return AO_CREATE_FAIL(rc);
+}
+
+static void soft_reset_dm_suspended(libxl__egc *egc,
+libxl__domain_suspend_state *dsps,
+int rc)
+{
+STATE_AO_GC(dsps->ao);
+libxl__domain_soft_reset_state *srs =
+CONTAINER_OF(dsps, *srs, dss.dsps);
+libxl__app_domain_create_state *cdcs = >cdcs;
/*
* Ask all backends to disconnect by removing the domain from
@@ -1853,18 +1869,13 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
* xenstore again with probably different store/console/...
* channels.
*/
-xs_release_domain(ctx->xsh, cdcs->dcs.domid_soft_reset);
+xs_release_domain(CTX->xsh, cdcs->dcs.domid_soft_reset);
srs->dds.ao = ao;
-srs->dds.domid = domid_soft_reset;
+srs->dds.domid = cdcs->dcs.domid_soft_reset;
srs->dds.callback = domain_soft_reset_cb;
srs->dds.soft_reset = true;
libxl__domain_destroy(egc, >dds);
-
-return AO_INPROGRESS;
-
- out:
-return AO_CREATE_FAIL(rc);
}
static void domain_create_cb(libxl__egc *egc,
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 1e904bae8a..f8ff5cf0c5 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -68,10 +68,12 @@ out:
/*- callbacks, called by xc_domain_save -*/
-int libxl__domain_suspend_device_model(libxl__gc *gc,
+void libxl__domain_suspend_device_model(libxl__egc *egc,
libxl__domain_suspend_state *dsps)
{
+STATE_AO_GC(dsps->ao);
int ret = 0;
+int rc = 0;
uint32_t const domid = dsps->domid;
const char *const filename = dsps->dm_savefile;
@@ -83,18 +85,29 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
break;
}
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (libxl__qmp_stop(gc, domid))
-return ERROR_FAIL;
+ret = libxl__qmp_stop(gc, domid);
+if (ret) {
+rc = ERROR_FAIL;
+goto out;
+}
/* Save DM state into filename */
ret = libxl__qmp_save(gc, domid, filename, dsps->live);
-if (ret)
+if (ret) {
+rc = ERROR_FAIL;
unlink(filename);
+goto out;
+}
break;
default:
-return ERROR_INVAL;
+rc = ERROR_INVAL;
+goto out;
}
-return ret;
+out:
+if (rc)
+LOGD(ERROR, dsps->domid,
+ "failed to suspend device model, rc=%d", rc);
+dsps->callback_device_model_done(egc, dsps, rc); /* must be last */
}
static void domain_suspend_common_wait_guest(libxl__egc *egc,
@@ -371,20 +384,15 @@ static void
domain_suspend_common_guest_suspended(libxl__egc *egc,
libxl__domain_suspend_state *dsps)
{
STATE_AO_GC(dsps->ao);
-int rc;
libxl__ev_evtchn_cancel(gc, >guest_evtchn);
libxl__ev_xswatch_deregister(gc, >guest_watch);
libxl__ev_time_deregister(gc,
[Xen-devel] [PATCH v6 11/11] libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp
The re-implementation is done because we want to be able to send the
file description that QEMU can use to save its state. When QEMU is
restricted, it would not be able to write to a path.
This replace both libxl__qmp_stop() and libxl__qmp_save().
qmp_qemu_check_version() was only used by libxl__qmp_save(), so it is
replace by a version using libxl__ev_qmp instead.
Coding style fixed in libxl__domain_suspend_device_model() for the
return value.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
extract open call from libxl__carefd_opened to respect coding style
libxl__qmp_suspend_save now always report success/error
via dsps->callback_device_model_done
v5:
rename goto 'out' label to 'error', as it is use only for errors.
re-add/keep the comment about the "live" parameter in dm_state_fd_ready
use libxl__remove_file instead of plain unlink
v4:
This patch replace the patch "libxl_qmp: Have QEMU save its state to a
file
descriptor" from previous version of the serie.
It uses libxl__ev_qmp instead.
tools/libxl/libxl_dom_suspend.c | 19 +---
tools/libxl/libxl_internal.h| 10 +-
tools/libxl/libxl_qmp.c | 159 +---
3 files changed, 137 insertions(+), 51 deletions(-)
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index f8ff5cf0c5..d1af3a6573 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -34,6 +34,7 @@ int libxl__domain_suspend_init(libxl__egc *egc,
libxl__ev_evtchn_init(>guest_evtchn);
libxl__ev_xswatch_init(>guest_watch);
libxl__ev_time_init(>guest_timeout);
+libxl__ev_qmp_init(>qmp);
if (type == LIBXL_DOMAIN_TYPE_INVALID) goto out;
dsps->type = type;
@@ -72,7 +73,6 @@ void libxl__domain_suspend_device_model(libxl__egc *egc,
libxl__domain_suspend_state *dsps)
{
STATE_AO_GC(dsps->ao);
-int ret = 0;
int rc = 0;
uint32_t const domid = dsps->domid;
const char *const filename = dsps->dm_savefile;
@@ -85,19 +85,9 @@ void libxl__domain_suspend_device_model(libxl__egc *egc,
break;
}
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-ret = libxl__qmp_stop(gc, domid);
-if (ret) {
-rc = ERROR_FAIL;
-goto out;
-}
-/* Save DM state into filename */
-ret = libxl__qmp_save(gc, domid, filename, dsps->live);
-if (ret) {
-rc = ERROR_FAIL;
-unlink(filename);
-goto out;
-}
-break;
+/* calls dsps->callback_device_model_done when done */
+libxl__qmp_suspend_save(egc, dsps); /* must be last */
+return;
default:
rc = ERROR_INVAL;
goto out;
@@ -406,6 +396,7 @@ static void domain_suspend_common_done(libxl__egc *egc,
libxl__ev_evtchn_cancel(gc, >guest_evtchn);
libxl__ev_xswatch_deregister(gc, >guest_watch);
libxl__ev_time_deregister(gc, >guest_timeout);
+libxl__ev_qmp_dispose(gc, >qmp);
dsps->callback_common_done(egc, dsps, rc);
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28af6d866c..6ec33f6eb6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1947,13 +1947,8 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
libxl_device_pci *pcidev);
/* Resume hvm domain */
_hidden int libxl__qmp_system_wakeup(libxl__gc *gc, int domid);
-/* Suspend QEMU. */
-_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
/* Resume QEMU. */
_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
-/* Save current QEMU state into fd. */
-_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename,
-bool live);
/* Load current QEMU state from file. */
_hidden int libxl__qmp_restore(libxl__gc *gc, int domid, const char *filename);
/* Set dirty bitmap logging status */
@@ -3412,6 +3407,7 @@ struct libxl__domain_suspend_state {
libxl__xswait_state pvcontrol;
libxl__ev_xswatch guest_watch;
libxl__ev_time guest_timeout;
+libxl__ev_qmp qmp;
const char *dm_savefile;
void (*callback_device_model_done)(libxl__egc*,
@@ -3423,6 +3419,10 @@ int libxl__domain_suspend_init(libxl__egc *egc,
libxl__domain_suspend_state *dsps,
libxl_domain_type type);
+/* calls dsps->callback_device_model_done when done */
+_hidden void libxl__qmp_suspend_save(libxl__egc *egc,
+ libxl__domain_suspend_state *dsps);
+
struct libxl__domain_save_state {
/* set by caller of libxl__domain_save */
libxl__ao *ao;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 5d3984e6a5..b7e011940f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -405,12 +405,12 @@ static
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
Hi Julien,
Thanks for the feedback.
On Mon, Nov 12, 2018 at 4:36 PM Julien Grall wrote:
>
> Hi Mirela,
>
> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > GIC and virtual timer context must be saved when the domain suspends.
>
> Please provide the rationale for this. Is it required by the spec?
>
This is required for GIC because a guest leaves enabled interrupts in
the GIC that could wake it up, and on resume it should be able to
detect which interrupt woke it up. Without saving/restoring the state
of GIC this would not be possible.
For timer, my understanding is that vtimer accounts for how long the
guest was executing and this tracking should not be affected by the
suspend/resume sequence. Without saving/restoring the state of vtimer,
the time tracking would be affected by the suspend/resume.
Hope this is ok, I'll add it to the commit message.
> > This is done by moving the respective code in ctxt_switch_from()
> > before the return that happens if the domain suspended.
> >
> > Signed-off-by: Mirela Simonovic
> > Signed-off-by: Saeed Nowshadi
> > ---
> > xen/arch/arm/domain.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 7f8105465c..bebe3238e8 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -97,6 +97,13 @@ static void ctxt_switch_from(struct vcpu *p)
> > if ( is_idle_vcpu(p) )
> > return;
> >
> > +/* VGIC */
> > +gic_save_state(p);
> > +
> > +/* Arch timer */
> > +p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1);
> > +virt_timer_save(p);
> > +
> > /* VCPU's context should not be saved if its domain is suspended */
>
> The GIC and timer are part of the vCPU context. So this comment looks a
> bit stale.
It's not stale, but incorrect in that perspective. The comment should
be updated to "VCPU architecture specific context should ..."
>
> > if ( p->domain->is_shut_down &&
> > (p->domain->shutdown_code == SHUTDOWN_suspend) )
> > @@ -115,10 +122,6 @@ static void ctxt_switch_from(struct vcpu *p)
> > p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
> > p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
> >
> > -/* Arch timer */
> > -p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1);
> > -virt_timer_save(p);
> > -
> > if ( is_32bit_domain(p->domain) && cpu_has_thumbee )
> > {
> > p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
> > @@ -170,9 +173,6 @@ static void ctxt_switch_from(struct vcpu *p)
> > /* VFP */
> > vfp_save_state(p);
> >
> > -/* VGIC */
> > -gic_save_state(p);
> > -
> > isb();
> > }
> >
> >
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn
On 11/12/18 4:49 PM, Andrii Anisov wrote: Hello Julien, Hi, I'm just wondering if this patch really belongs to xentrace series. It rather looks like a separate cleanup patch. What's wrong with including clean-up patch in a series adding a feature? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 08/11] libxl: QEMU startup sync based on QMP
This is only activated when dm_restrict=1, as explained in the previous
patch "libxl_dm: Pre-open QMP socket for QEMU"
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
---
Notes:
v6:
invent ERROR_QEMU_API
return better rc: ERROR_QEMU_API or ERROR_NOT_READY
enhance log messages (debug and error)
v5:
removed empty success branch in device_model_qmp_cb()
call libxl__ev_qmp_init() earlier in libxl__spawn_local_dm.
otherwise the error path would use an uninitialised
libxl__ev_qmp.
v4:
moved to libxl__dm_spawn_* from libxl__spawn_*
tools/libxl/libxl_dm.c | 55
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_types.idl | 1 +
3 files changed, 57 insertions(+)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3bf1e37894..2417abe651 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2313,6 +2313,9 @@ static void device_model_startup_failed(libxl__egc *egc,
int rc);
static void device_model_detached(libxl__egc *egc,
libxl__spawn_state *spawn);
+static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+int rc);
/* our "next step" function, called from those callbacks and elsewhere */
static void device_model_spawn_outcome(libxl__egc *egc,
@@ -2343,6 +2346,8 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
const char *dm;
int dm_state_fd = -1;
+libxl__ev_qmp_init(>qmp);
+
if (libxl_defbool_val(b_info->device_model_stubdomain)) {
abort();
}
@@ -2450,6 +2455,16 @@ retry_transaction:
spawn->failure_cb = device_model_startup_failed;
spawn->detached_cb = device_model_detached;
+if (state->dm_monitor_fd >= 0) {
+/* There is a valid QMP socket available now,
+ * use it to find out when QEMU is ready */
+dmss->qmp.callback = device_model_qmp_cb;
+dmss->qmp.domid = domid;
+dmss->qmp.fd = -1;
+rc = libxl__ev_qmp_send(gc, >qmp, "query-status", NULL);
+if (rc) goto out_close;
+}
+
rc = libxl__spawn_spawn(egc, spawn);
if (rc < 0)
goto out_close;
@@ -2524,6 +2539,44 @@ static void device_model_detached(libxl__egc *egc,
device_model_spawn_outcome(egc, dmss, 0);
}
+static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+int rc)
+{
+EGC_GC;
+libxl__dm_spawn_state *dmss = CONTAINER_OF(ev, *dmss, qmp);
+const libxl__json_object *o;
+const char *status;
+
+libxl__ev_qmp_dispose(gc, ev);
+
+if (rc)
+goto failed;
+
+o = libxl__json_map_get("status", response, JSON_STRING);
+if (!o) {
+LOGD(ERROR, ev->domid,
+ "Missing \"status\" in response to \"query-status\"");
+LOGD(DEBUG, ev->domid, ".. instead, got: %s",
+ libxl__json_object_to_json(gc, response));
+rc = ERROR_QEMU_API;
+goto failed;
+}
+status = libxl__json_object_get_string(o);
+if (strcmp(status, "running")) {
+LOGD(ERROR, ev->domid, "Unexpected QEMU status: %s", status);
+rc = ERROR_NOT_READY;
+goto failed;
+}
+
+libxl__spawn_initiate_detach(gc, >spawn);
+return;
+
+failed:
+LOGD(ERROR, ev->domid, "QEMU did not start properly, rc=%d", rc);
+libxl__spawn_initiate_failure(gc, >spawn, rc);
+}
+
static void device_model_spawn_outcome(libxl__egc *egc,
libxl__dm_spawn_state *dmss,
int rc)
@@ -2547,6 +2600,8 @@ static void device_model_spawn_outcome(libxl__egc *egc,
}
}
+libxl__ev_qmp_dispose(gc, >qmp);
+
out:
dmss->callback(egc, dmss, rc);
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b768d1b09f..de3862c839 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3898,6 +3898,7 @@ struct libxl__dm_spawn_state {
libxl_domain_config *guest_config;
libxl__domain_build_state *build_state; /* relates to guest_domid */
libxl__dm_spawn_cb *callback;
+libxl__ev_qmp qmp;
};
_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index fec42b260c..a0912718e0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,6 +75,7 @@ libxl_error = Enumeration("error", [
(-29, "QMP_COMMAND_NOT_FOUND"), # the requested command has not been found
(-30, "QMP_DEVICE_NOT_ACTIVE"), # a device has failed to be become active
(-31, "QMP_DEVICE_NOT_FOUND"), # the requested device has not been
[Xen-devel] [PATCH v6 00/11] libxl: Enable save/restore/migration of a restricted QEMU + libxl__ev_qmp_*
Changes in v6: Implementation of libxl__ev_qmp_* functions have been squashed to a single patch. And with that, a lot of changes in order to make it simpler to read the implementation, have better error reporting and a few bug fix. Checkout more detail changelog in the notes of each patch, as there is many. Changes in v5: Plenty of patch have been applied. Other changes mostly are coding style and other typos. Some bug fixes. Details can be found in patch notes. I have left aside the change to cdrom_insert until I can found what to do with the userdata lock. Changes in v4: Better API which meant a lot of other changes. In order for libxl to be able to manage QEMU while it is restricted, a few changes are needed. We need a new way to get a startup notification from QEMU as xenstore may not be accessible when QEMU is ready. We also need to a different way to have QEMU save it's state and to insert cdrom as a restricted QEMU doesn't have access to the file system. For both, we can use QMP, we can use it to query QEMU's status, and we can use it to send a file descriptor through which QEMU can save its state, or it can be a cdrom. We take this opportunity to rewrite the QMP client, and this time been asynchronous, the result is libxl__ev_qmp_*. The plat de résistance in this patch series start with patch "libxl: Design of an async API to issue QMP commands to QEMU" which implement libxl__ev_qmp_* functions to turn the QMP client into asynchronous mode. This comes with changes that uses the new interface. * "libxl: QEMU startup sync based on QMP" which can use QMP to find out when QEMU as started. this requires: "libxl_dm: Pre-open QMP socket for QEMU" But that only works with dm_restrict=1 as explain in the patch. * "libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp" Which rewrite libxl__qmp_save(), and adds the ability to have QEMU save its state to a file descriptor which libxl will have openned. Patches series available in a git tag: git fetch https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git tags/libxl-ev-qmp-v6 git checkout -b libxl-ev-qmp-v6 FETCH_HEAD Cheers, Anthony PERARD (11): libxl: Enhance libxl__sendmsg_fds to deal with EINTR and EWOULDBLOCK libxl_qmp: Separate QMP message generation from qmp_send_prepare libxl_qmp: Change qmp_qemu_check_version to compare version libxl: Design of an async API to issue QMP commands to QEMU libxl_qmp: Implementation of libxl__ev_qmp_* libxl_exec: Add libxl__spawn_initiate_failure libxl_dm: Pre-open QMP socket for QEMU libxl: QEMU startup sync based on QMP libxl_qmp: Store advertised QEMU version in libxl__ev_qmp libxl: Change libxl__domain_suspend_device_model() to be async libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp tools/libxl/libxl_create.c | 38 +- tools/libxl/libxl_dm.c | 126 - tools/libxl/libxl_dom_suspend.c | 37 +- tools/libxl/libxl_exec.c| 11 + tools/libxl/libxl_internal.h| 162 +- tools/libxl/libxl_qmp.c | 925 ++-- tools/libxl/libxl_types.idl | 7 + tools/libxl/libxl_utils.c | 19 +- 8 files changed, 1222 insertions(+), 103 deletions(-) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 07/11] libxl_dm: Pre-open QMP socket for QEMU
This patch move the creation of the QMP unix socket from QEMU to libxl.
But libxl doesn't rely on this yet.
When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be usefull to findout if QEMU is ready, and
pre-opening it means that libxl can connect to it without waiting for
QEMU to create it.
The pre-openning is conditionnal, based on the use of dm_restrict
because it is using a new command line option of QEMU, and dm_restrict
support in QEMU is newer.
-chardev socket,fd=X is available with QEMU 2.12, since commit:
> char: allow passing pre-opened socket file descriptor at startup
> 0935700f8544033ebbd41e1f13cd528f8a58d24d
dm_restrict is available in QEMU 3.0.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
move dm_monitor_fd into libxl_domain_build_info (or d_state)
-> move the creation of the socket into libxl__spawn_local_dm
instead of libxl__build_device_model_args
Use libxl_domid type instead of int for libxl__pre_open_qmp_socket()
Check function calls (bind and listen) return value in a separate
statement.
typo and other coding style issue fixes
v5:
use libxl__remove_file
few changes in coding style
remove stale includes (sys/socket, sys/un) which are now in
libxl_internal.h
v4:
separate the logic to open a socket into a function.
Use libxl__prepare_sockaddr_un() to check path size
tools/libxl/libxl_create.c | 3 ++
tools/libxl/libxl_dm.c | 71 ++--
tools/libxl/libxl_internal.h | 1 +
3 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa573344bc..fcbe36feba 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -539,6 +539,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
*d_config,
libxl_domain_create_info *info = _config->c_info;
libxl_domain_build_info *b_info = _config->b_info;
+/* Attempt to initialise libxl__domain_build_state */
+state->dm_monitor_fd = -1;
+
uuid_string = libxl__uuid2string(gc, info->uuid);
if (!uuid_string) {
rc = ERROR_NOMEM;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 9c47060473..3bf1e37894 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -910,6 +910,53 @@ static char *qemu_disk_ide_drive_string(libxl__gc *gc,
const char *target_path,
return drive;
}
+static int libxl__pre_open_qmp_socket(libxl__gc *gc, libxl_domid domid,
+ int *fd_r)
+{
+int rc, r;
+int fd;
+struct sockaddr_un un;
+const char *path = libxl__qemu_qmp_path(gc, domid);
+
+assert(fd_r != NULL);
+
+fd = socket(AF_UNIX, SOCK_STREAM, 0);
+if (fd < 0) {
+LOGED(ERROR, domid, "socket() failed");
+return ERROR_FAIL;
+}
+
+rc = libxl__prepare_sockaddr_un(gc, , path, "QEMU's QMP socket");
+if (rc)
+goto out;
+
+rc = libxl__remove_file(gc, path);
+if (rc)
+goto out;
+
+r = bind(fd, (struct sockaddr *) , sizeof(un));
+if (r < 0) {
+LOGED(ERROR, domid, "bind('%s') failed", path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+r = listen(fd, 1);
+if (r < 0) {
+LOGED(ERROR, domid, "listen() failed");
+rc = ERROR_FAIL;
+goto out;
+}
+
+*fd_r = fd;
+rc = 0;
+
+out:
+if (rc && fd >= 0)
+close(fd);
+return rc;
+}
+
static int libxl__build_device_model_args_new(libxl__gc *gc,
const char *dm, int guest_domid,
const libxl_domain_config
*guest_config,
@@ -944,10 +991,16 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
GCSPRINTF("%d", guest_domid), NULL);
flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxl-cmd,"
- "path=%s,server,nowait",
- libxl__qemu_qmp_path(gc, guest_domid)));
+if (state->dm_monitor_fd >= 0) {
+flexarray_append(dm_args,
+GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
+ state->dm_monitor_fd));
+} else {
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,"
+ "path=%s,server,nowait",
+ libxl__qemu_qmp_path(gc, guest_domid)));
+}
flexarray_append(dm_args, "-no-shutdown");
flexarray_append(dm_args, "-mon");
@@ -2000,6 +2053,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss)
if (ret)
goto out;
+d_state->dm_monitor_fd = -1;
ret = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
[Xen-devel] [PATCH v6 04/11] libxl: Design of an async API to issue QMP commands to QEMU
All the functions will be implemented in later patches.
This patch includes the API that libxl can use to send QMP commands to
QEMU.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
use libxl_domid type for domid instead of plain uin32_t
avoid the work "chained", rewrite the paragraph about sending one
cmd after another
Rewrite the comment about the callback, and explain that on error,
the `ev` may be Idle or may still be Connected
Change the carefd to a simple int (field cfd -> fd)
v5:
some changes in the comment
tools/libxl/libxl_internal.h | 74 +++-
1 file changed, 72 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae5960d869..f089524460 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -186,6 +186,8 @@ typedef struct libxl__ao libxl__ao;
typedef struct libxl__aop_occurred libxl__aop_occurred;
typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
+typedef struct libxl__json_object libxl__json_object;
+typedef struct libxl__carefd libxl__carefd;
typedef struct libxl__domain_create_state libxl__domain_create_state;
typedef void libxl__domain_create_cb(struct libxl__egc *egc,
@@ -349,6 +351,74 @@ struct libxl__ev_child {
LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
};
+/*
+ * QMP asynchronous calls
+ *
+ * This facility allows a command to be sent to QEMU, and the response
+ * to be handed to a callback function.
+ *
+ * Commands can be submited one after an other with the same
+ * connection (e.g. the result from the "add-fd" command need to be
+ * use in a follow-up command before disconnecting from QMP). A
+ * libxl__ev_qmp can be reused when the callback is been called in
+ * order to use the same connection.
+ *
+ * Only one connection at a time can be made to one QEMU, so avoid
+ * keeping a libxl__ev_qmp Connected for to long and call
+ * libxl__ev_qmp_dispose as soon as it is not needed anymore.
+ *
+ * Possible states of a libxl__ev_qmp:
+ * Undefined
+ *Might contain anything.
+ * Idle
+ *Struct contents are defined enough to pass to any
+ *libxl__ev_qmp_* function.
+ *The struct does not contain references to any allocated private
+ *resources so can be thrown away.
+ * Active
+ *Currently waiting for the callback to be called.
+ *_dispose must be called to reclaim resources.
+ * Connected
+ *Struct contain allocated ressources.
+ *Calling _send() with this same ev will use the same QMP connection.
+ *_dispose() must be called to reclaim resources.
+ *
+ * libxl__ev_qmp_init: Undefined/Idle -> Idle
+ *
+ * libxl__ev_qmp_send: Idle/Connected -> Active (on error: Idle)
+ *Sends a command to QEMU.
+ *callback will be called when a response is received or when an
+ *error as occured.
+ *
+ * libxl__ev_qmp_dispose: Connected/Active/Idle -> Idle
+ *
+ * callback: When called: Active -> Connected (on error: Idle/Connected)
+ *When called, ev is Connected and can be reused or disposed of.
+ *On error, the callback is called with response == NULL and the
+ *error code in rc. The new state of ev depending on the value of rc:
+ *- rc == ERROR_QMP_*: This is an error associated with the cmd to
+ * run, ev is Connected.
+ *- otherwise: An other error happend, ev is now Idle.
+ *The callback is only called once.
+ */
+typedef struct libxl__ev_qmp libxl__ev_qmp;
+typedef void libxl__ev_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+int rc);
+
+_hidden void libxl__ev_qmp_init(libxl__ev_qmp *ev);
+_hidden int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
+ const char *cmd, libxl__json_object *args);
+_hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
+
+struct libxl__ev_qmp {
+/* caller should include this in their own struct */
+/* caller must fill these in, and they must all remain valid */
+libxl_domid domid;
+libxl__ev_qmp_callback *callback;
+int fd; /* set to send a fd with the command, -1 otherwise */
+};
+
/*
* evgen structures, which are the state we use for generating
@@ -1895,7 +1965,7 @@ typedef enum {
JSON_ANY = 255 /* this is a mask of all values above, adjust as needed
*/
} libxl__json_node_type;
-typedef struct libxl__json_object {
+struct libxl__json_object {
libxl__json_node_type type;
union {
bool b;
@@ -1908,7 +1978,7 @@ typedef struct libxl__json_object {
flexarray_t *map;
} u;
struct libxl__json_object *parent;
-} libxl__json_object;
+};
typedef int (*libxl__json_parse_callback)(libxl__gc *gc,
libxl__json_object *o,
--
[Xen-devel] [PATCH v6 02/11] libxl_qmp: Separate QMP message generation from qmp_send_prepare
To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp.
Also, add the QMP end of command '\r\n' into the generated string.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
comment about ownership of buf
use lib__sprintf instead of two strncpy
v5:
rename qmp_prepare_qmp_cmd to qmp_prepare_cmd
fix coding style
tools/libxl/libxl_qmp.c | 57 -
1 file changed, 39 insertions(+), 18 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6a5c997546..2dd54d5398 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -571,17 +571,16 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler
*qmp)
return rc;
}
-static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
- const char *cmd, libxl__json_object *args,
- qmp_callback_t callback, void *opaque,
- qmp_request_context *context)
+static char *qmp_prepare_cmd(libxl__gc *gc, const char *cmd,
+ const libxl__json_object *args,
+ int id, size_t *len_r)
{
-const unsigned char *buf = NULL;
-char *ret = NULL;
-libxl_yajl_length len = 0;
+yajl_gen hand = NULL;
+/* memory for 'buf' is owned by 'hand' */
+const unsigned char *buf;
+libxl_yajl_length len;
yajl_gen_status s;
-yajl_gen hand;
-callback_id_pair *elm = NULL;
+char *ret = NULL;
hand = libxl_yajl_gen_alloc(NULL);
@@ -598,7 +597,7 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
libxl__yajl_gen_asciiz(hand, "execute");
libxl__yajl_gen_asciiz(hand, cmd);
libxl__yajl_gen_asciiz(hand, "id");
-yajl_gen_integer(hand, ++qmp->last_id_used);
+yajl_gen_integer(hand, id);
if (args) {
libxl__yajl_gen_asciiz(hand, "arguments");
libxl__json_object_to_yajl_gen(gc, hand, args);
@@ -608,6 +607,32 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
s = yajl_gen_get_buf(hand, , );
if (s) {
+goto out;
+}
+
+ret = libxl__sprintf(NOGC, "%*.*s\r\n", (int)len, (int)len, buf);
+len += 2;
+
+if (len_r)
+*len_r = len;
+
+out:
+yajl_gen_free(hand);
+return ret;
+}
+
+static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
+ const char *cmd, libxl__json_object *args,
+ qmp_callback_t callback, void *opaque,
+ qmp_request_context *context,
+ size_t *len_r)
+{
+char *buf;
+callback_id_pair *elm;
+
+buf = qmp_prepare_cmd(gc, cmd, args, ++qmp->last_id_used, NULL);
+
+if (!buf) {
LOGD(ERROR, qmp->domid, "Failed to generate a qmp command");
goto out;
}
@@ -623,13 +648,10 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
elm->context = context;
LIBXL_STAILQ_INSERT_TAIL(>callback_list, elm, next);
-ret = libxl__strndup(gc, (const char*)buf, len);
-
LOGD(DEBUG, qmp->domid, "next qmp command: '%s'", buf);
out:
-yajl_gen_free(hand);
-return ret;
+return buf;
}
static int qmp_send(libxl__qmp_handler *qmp,
@@ -641,7 +663,8 @@ static int qmp_send(libxl__qmp_handler *qmp,
int rc = -1;
GC_INIT(qmp->ctx);
-buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context);
+buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context,
+ NULL);
if (buf == NULL) {
goto out;
@@ -650,12 +673,10 @@ static int qmp_send(libxl__qmp_handler *qmp,
if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
"QMP command", "QMP socket"))
goto out;
-if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-"CRLF", "QMP socket"))
-goto out;
rc = qmp->last_id_used;
out:
+free(buf);
GC_FREE;
return rc;
}
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 01/11] libxl: Enhance libxl__sendmsg_fds to deal with EINTR and EWOULDBLOCK
This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
EINTR error.
This patch also allow a caller of libxl__sendmsg_fds to deal with
EWOULDBLOCK. It is best to only sent one byte when dealing with
non-blocking fds so a EWOULDBLOCK error would mean that the fds haven't
been sent yet.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 ++-
tools/libxl/libxl_utils.c| 19 ++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e498435e16..ae5960d869 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,7 +1864,8 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t
domid);
_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
const libxl_domain_config
*guest_config);
-/* on failure, logs */
+/* returns ERROR_NOT_READY on EWOULDBLOCK
+ * or logs on failure. */
int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
const void *data, size_t datalen,
int nfds, const int fds[], const char *what);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 5854717b11..5d20fd57c5 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -1088,11 +1088,20 @@ int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
msg.msg_controllen = cmsg->cmsg_len;
-r = sendmsg(carrier, , 0);
-if (r < 0) {
-LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
-return ERROR_FAIL;
-}
+while (1) {
+r = sendmsg(carrier, , 0);
+if (r < 0) {
+if (errno == EINTR)
+continue;
+if (errno == EWOULDBLOCK) {
+assert(datalen == 1);
+return ERROR_NOT_READY;
+}
+LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+return ERROR_FAIL;
+}
+break;
+};
return 0;
}
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn
Hello Julien,
I'm just wondering if this patch really belongs to xentrace series.
It rather looks like a separate cleanup patch.
Sincerely,
Andrii Anisov.
вт, 6 лист. 2018 о 21:16 Julien Grall пише:
> No functional change intended.
>
> Only reasonable clean-ups are done in this patch. The rest will use _gfn
> for the time being.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/guestcopy.c | 2 +-
> xen/arch/arm/mm.c| 2 +-
> xen/arch/x86/cpu/vpmu.c | 2 +-
> xen/arch/x86/domain.c| 12 ++--
> xen/arch/x86/domctl.c| 6 +++---
> xen/arch/x86/hvm/dm.c| 2 +-
> xen/arch/x86/hvm/domain.c| 2 +-
> xen/arch/x86/hvm/hvm.c | 9 +
> xen/arch/x86/hvm/svm/svm.c | 8
> xen/arch/x86/hvm/viridian/viridian.c | 24
> xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
> xen/arch/x86/hvm/vmx/vvmx.c | 12 ++--
> xen/arch/x86/mm.c| 24 ++--
> xen/arch/x86/mm/p2m.c| 2 +-
> xen/arch/x86/mm/shadow/hvm.c | 6 +++---
> xen/arch/x86/physdev.c | 3 ++-
> xen/arch/x86/pv/descriptor-tables.c | 5 ++---
> xen/arch/x86/pv/emul-priv-op.c | 6 +++---
> xen/arch/x86/pv/mm.c | 2 +-
> xen/arch/x86/traps.c | 11 ++-
> xen/common/domain.c | 2 +-
> xen/common/event_fifo.c | 12 ++--
> xen/common/memory.c | 4 ++--
> xen/common/tmem_xen.c| 2 +-
> xen/include/asm-arm/p2m.h| 6 +++---
> xen/include/asm-x86/p2m.h| 11 +++
> 26 files changed, 95 insertions(+), 86 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 7a0f3e9d5f..55892062bb 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -37,7 +37,7 @@ static struct page_info *translate_get_page(copy_info_t
> info, uint64_t addr,
> return get_page_from_gva(info.gva.v, addr,
> write ? GV2M_WRITE : GV2M_READ);
>
> -page = get_page_from_gfn(info.gpa.d, paddr_to_pfn(addr), ,
> P2M_ALLOC);
> +page = get_page_from_gfn(info.gpa.d, gaddr_to_gfn(addr), ,
> P2M_ALLOC);
>
> if ( !page )
> return NULL;
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 72d0285768..88711096ef 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1268,7 +1268,7 @@ int xenmem_add_to_physmap_one(
>
> /* Take reference to the foreign domain page.
> * Reference will be released in XENMEM_remove_from_physmap */
> -page = get_page_from_gfn(od, idx, , P2M_ALLOC);
> +page = get_page_from_gfn(od, _gfn(idx), , P2M_ALLOC);
> if ( !page )
> {
> put_pg_owner(od);
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index 8a4f753eae..4d8f153031 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -607,7 +607,7 @@ static int pvpmu_init(struct domain *d,
> xen_pmu_params_t *params)
> struct vcpu *v;
> struct vpmu_struct *vpmu;
> struct page_info *page;
> -uint64_t gfn = params->val;
> +gfn_t gfn = _gfn(params->val);
>
> if ( (params->vcpu >= d->max_vcpus) || (d->vcpu[params->vcpu] ==
> NULL) )
> return -EINVAL;
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index f6fe954313..c5cce4b38d 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -797,7 +797,7 @@ int arch_set_info_guest(
> unsigned long flags;
> bool compat;
> #ifdef CONFIG_PV
> -unsigned long cr3_gfn;
> +gfn_t cr3_gfn;
> struct page_info *cr3_page;
> unsigned long cr4;
> int rc = 0;
> @@ -1061,9 +1061,9 @@ int arch_set_info_guest(
> set_bit(_VPF_in_reset, >pause_flags);
>
> if ( !compat )
> -cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
> +cr3_gfn = _gfn(xen_cr3_to_pfn(c.nat->ctrlreg[3]));
> else
> -cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
> +cr3_gfn = _gfn(compat_cr3_to_pfn(c.cmp->ctrlreg[3]));
> cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
>
> if ( !cr3_page )
> @@ -1092,7 +1092,7 @@ int arch_set_info_guest(
> case 0:
> if ( !compat && !VM_ASSIST(d, m2p_strict) &&
> !paging_mode_refcounts(d) )
> -fill_ro_mpt(_mfn(cr3_gfn));
> +fill_ro_mpt(_mfn(gfn_x(cr3_gfn)));
> break;
> default:
> if ( cr3_page == current->arch.old_guest_table )
> @@ -1107,7 +1107,7 @@ int arch_set_info_guest(
> v->arch.guest_table = pagetable_from_page(cr3_page);
> if ( c.nat->ctrlreg[1] )
> {
> -cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
> +cr3_gfn =
[Xen-devel] [PATCH v6 03/11] libxl_qmp: Change qmp_qemu_check_version to compare version
This patch makes the function simpler to read. It also add the ability
for a caller to tell if QEMU is newer or have the exact version.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
new patch
tools/libxl/libxl_qmp.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 2dd54d5398..43ae9a0374 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -392,13 +392,27 @@ static int qmp_handle_response(libxl__gc *gc,
libxl__qmp_handler *qmp,
return 0;
}
-static bool qmp_qemu_check_version(libxl__qmp_handler *qmp, int major,
- int minor, int micro)
+/*
+ * return values:
+ * < 0 if qemu's version < asked version
+ * = 0 if qemu's version == asked version
+ * > 0 if qemu's version > asked version
+ */
+static int qmp_qemu_compare_version(libxl__qmp_handler *qmp, int major,
+int minor, int micro)
{
-return qmp->version.major > major ||
-(qmp->version.major == major &&
-(qmp->version.minor > minor ||
- (qmp->version.minor == minor && qmp->version.micro >= micro)));
+#define CHECK_VERSION(level) do { \
+if (qmp->version.level > (level)) return +1; \
+if (qmp->version.level < (level)) return -1; \
+} while (0)
+
+CHECK_VERSION(major);
+CHECK_VERSION(minor);
+CHECK_VERSION(micro);
+
+#undef CHECK_VERSION
+
+return 0;
}
/*
@@ -1020,7 +1034,7 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char
*filename, bool live)
/* live parameter was added to QEMU 2.11. It signal QEMU that the save
* operation is for a live migration rather that for taking a snapshot. */
-if (qmp_qemu_check_version(qmp, 2, 11, 0))
+if (qmp_qemu_compare_version(qmp, 2, 11, 0) >= 0)
qmp_parameters_add_bool(gc, , "live", live);
rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 09/11] libxl_qmp: Store advertised QEMU version in libxl__ev_qmp
This will be used in a later patch.
Signed-off-by: Anthony PERARD
---
Notes:
v6:
new local macro GRAB_VERSION
better definition of qemu_version field in libxl_internal.h
v5:
initialise qemu_version struct in libxl__ev_qmp_init
tools/libxl/libxl_internal.h | 8
tools/libxl/libxl_qmp.c | 23 +++
2 files changed, 31 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index de3862c839..53814be9d7 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -431,6 +431,14 @@ struct libxl__ev_qmp {
libxl__ev_qmp_callback *callback;
int fd; /* set to send a fd with the command, -1 otherwise */
+/* read-only when Connected
+ * and not to be accessed by the caller otherwise */
+struct {
+int major;
+int minor;
+int micro;
+} qemu_version;
+
/*
* remaining fields are private to libxl_ev_qmp_*
*/
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 895628066a..5d3984e6a5 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1841,6 +1841,25 @@ static int qmp_ev_handle_message(libxl__egc *egc,
return ERROR_PROTOCOL_ERROR_QMP;
}
+/*
+ * Store advertised QEMU version
+ * { "QMP": { "version": {
+ * "qemu": { "major": int, "minor": int, "micro": int } } } }
+ */
+o = libxl__json_map_get("QMP", resp, JSON_MAP);
+o = libxl__json_map_get("version", o, JSON_MAP);
+o = libxl__json_map_get("qemu", o, JSON_MAP);
+#define GRAB_VERSION(level) \
+ev->qemu_version.level = libxl__json_object_get_integer( \
+libxl__json_map_get(#level, o, JSON_INTEGER));
+GRAB_VERSION(major);
+GRAB_VERSION(minor);
+GRAB_VERSION(micro);
+#undef GRAB_VERSION
+LOGD(DEBUG, ev->domid, "QEMU version: %d.%d.%d",
+ ev->qemu_version.major, ev->qemu_version.minor,
+ ev->qemu_version.micro);
+
/* Prepare next message to send */
assert(!ev->tx_buf);
ev->tx_buf = qmp_prepare_cmd(gc, "qmp_capabilities", NULL,
@@ -1927,6 +1946,10 @@ out_unknown_id:
void libxl__ev_qmp_init(libxl__ev_qmp *ev)
{
+ev->qemu_version.major = -1;
+ev->qemu_version.minor = -1;
+ev->qemu_version.micro = -1;
+
ev->id = QMP_CAPABILITY_NEGOTIATION_MSGID + 1;
ev->qmp_cfd = NULL;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 05/11] libxl_qmp: Implementation of libxl__ev_qmp_*
Signed-off-by: Anthony PERARD
---
Notes:
v6:
This is a squash of 7 commits on the previous version:
- libxl_qmp: Connect to QMP socket
- libxl_qmp: Implement fd callback and read data
- libxl_qmp: Parse JSON input from QMP
- libxl_qmp: Prepare the command to be sent
- libxl_qmp: Handle write to QMP socket
- libxl_qmp: Handle messages from QEMU
- libxl_qmp: Respond to QMP greeting
General rework of the implementation.
Added more comment, with a description of allowed internal states.
Check for EINPROGRESS after connect().
Read until EWOULDBLOCK.
Handle EWOULDBLOCK on write and sendmsg.
Using memmem instead of strstr.
Using memmove instead of having an offset in rx_buf.
Rework buffer allocation
Don't feed \r into json parser anymore
Add a check for a maximum RX buffer size
Added more error messages
New error code ERROR_PROTOCOL_ERROR_QMP
Rewrite conversion of QMP ErrorClass to libxl_error code
Added helpers: qmp_ev_ensure_reading_writing, qmp_ev_set_state
Split some functions, squash others
Added ev->msg* to store generated user command as tx_buf is used during
connection (for qmp_capabilities)
Remove qmp_state_greeting
Added qmp_state_waiting_reply
v5:
nits
use a define instead of a static int for
QMP_CAPABILITY_NEGOCIATION_MSGID
use a switch in qmp_ev_callback_writable to check qmp_state
Add a description of the different value of libxl__qmp_state enum.
some cleanup
remove read loop that only handled EINTR, simply return
initialize len and s at declaration time
remove old comment
rename buf_fd to send_fd
Adding default:abort() in qmp_ev_handle_message.
v4:
remove use of a linked list of receive buffer, and use realloc instead.
simplification of the patch due to use of a single allocated space for
the
receive buffer.
tools/libxl/libxl_internal.h | 35 ++
tools/libxl/libxl_qmp.c | 668 +++
tools/libxl/libxl_types.idl | 6 +
3 files changed, 709 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f089524460..e02597a0cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -411,12 +411,47 @@ _hidden int libxl__ev_qmp_send(libxl__gc *gc,
libxl__ev_qmp *ev,
const char *cmd, libxl__json_object *args);
_hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
+typedef enum {
+/* initial state */
+qmp_state_disconnected = 1,
+/* connected to QMP socket, waiting for greeting message */
+qmp_state_connecting,
+/* qmp_capabilities command sent, waiting for reply */
+qmp_state_capability_negotiation,
+/* ready to send commands */
+qmp_state_connected,
+/* cmd sent, waiting for reply */
+qmp_state_waiting_reply,
+} libxl__qmp_state;
+
struct libxl__ev_qmp {
/* caller should include this in their own struct */
/* caller must fill these in, and they must all remain valid */
libxl_domid domid;
libxl__ev_qmp_callback *callback;
int fd; /* set to send a fd with the command, -1 otherwise */
+
+/*
+ * remaining fields are private to libxl_ev_qmp_*
+ */
+
+int id;
+libxl__carefd *qmp_cfd;
+libxl__ev_fd qmp_efd;
+libxl__qmp_state qmp_state;
+/* receive buffer, with:
+ * rx_buf_size: current allocated size,
+ * rx_buf_used: actual data in the buffer */
+char *rx_buf;
+size_t rx_buf_size;
+size_t rx_buf_used;
+/* sending buffer */
+char *tx_buf;
+size_t tx_buf_len;
+size_t tx_buf_off;
+/* The message to send when ready */
+char *msg;
+size_t msg_len;
};
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 43ae9a0374..895628066a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -75,11 +75,18 @@
# define DEBUG_REPORT_RECEIVED(dom, buf, len) ((void)0)
#endif
+#ifdef DEBUG_QMP_CLIENT
+# define LOG_QMP(f, ...) LOGD(DEBUG, ev->domid, f, ##__VA_ARGS__)
+#else
+# define LOG_QMP(f, ...)
+#endif
+
/*
* QMP types & constant
*/
#define QMP_RECEIVE_BUFFER_SIZE 4096
+#define QMP_MAX_SIZE_RX_BUF MB(8)
#define PCI_PT_QDEV_ID "pci-pt-%02x_%02x.%01x"
/*
@@ -1315,6 +1322,667 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t
domid,
return ret;
}
+/* Implementation of libxl__ev_qmp */
+
+/*
+ * Possible internal state compared to qmp_state:
+ *
+ * qmp_state disconnected connecting capability connected waiting
+ *_negotiation_reply
+ * External Idle Active Active Connected Active
+ * qmp_cfdcloseopen open
[Xen-devel] [PATCH v6 06/11] libxl_exec: Add libxl__spawn_initiate_failure
This function can be used by user of libxl__spawn_* when they setup a
notification other than xenstore. The parent can already report success
via libxl__spawn_initiate_detach(), this new function can be used for
failure instead of waiting for the timeout.
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
---
Notes:
v6:
long line fix
typos fixed
fix leak of internal state into external doc
if the function is call multiple times, set rc only the first time.
v5:
fix typos
tools/libxl/libxl_exec.c | 11 +++
tools/libxl/libxl_internal.h | 23 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 02e6c917f0..bf87bc563c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -373,6 +373,17 @@ void libxl__spawn_initiate_detach(libxl__gc *gc,
libxl__spawn_state *ss)
spawn_detach(gc, ss);
}
+void libxl__spawn_initiate_failure(libxl__gc *gc, libxl__spawn_state *ss,
+ int rc)
+/* The spawn state must be Attached on entry and will be Attached Failed
+ * on return. */
+{
+assert(rc);
+if (!ss->rc)
+ss->rc = rc;
+spawn_detach(gc, ss);
+}
+
static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss, int rc)
/* Caller must have logged. Must be last thing in calling function,
* as it may make the callback. Precondition: Attached or Detaching. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e02597a0cd..6c118ccb3b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1552,7 +1552,8 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
*
* The inner child must soon exit or exec. It must also soon exit or
* notify the parent of its successful startup by writing to the
- * xenstore path xspath.
+ * xenstore path xspath OR via other means that the parent will have
+ * to set up.
*
* The user (in the parent) will be called back (confirm_cb) every
* time that xenstore path is modified.
@@ -1608,6 +1609,26 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc,
libxl__spawn_state *spawn);
*/
_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
+/*
+ * libxl__spawn_initiate_failure - Propagate failure from the caller to the
+ * callee.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, a failure will be reported.
+ *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
+ * Logs errors.
+ *
+ * The spawn state must be Attached on entry and will remain Attached. It
+ * is possible for a spawn to fail for multiple reasons, for example
+ * call(s) to libxl__spawn_initiate_failure and also for some other reason.
+ * In that case the first rc value from any source will take precedence.
+ */
+_hidden void libxl__spawn_initiate_failure(libxl__gc *gc,
+ libxl__spawn_state *ss, int rc);
+
/*
* If successful, this should return 0.
*
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
On 12/11/18 16:35, Mirela Simonovic wrote: > Hi Julien, > > Thanks for your feedback, I'll need to answer in iterations. > > On Mon, Nov 12, 2018 at 4:27 PM Julien Grall wrote: >> Hi Mirela, >> >> On 11/12/18 11:30 AM, Mirela Simonovic wrote: >>> The implementation consists of: >>> -Adding PSCI system suspend call as new PSCI function >>> -Trapping PSCI system_suspend HVC >>> -Implementing PSCI system suspend call (virtual interface that allows >>> guests to suspend themselves) >>> >>> The PSCI system suspend should be called by a guest from its boot >>> VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI >>> CPU_OFF call prior to issuing PSCI system suspend. Interrupts that >>> are left enabled by the guest are assumed to be its wake-up interrupts. >>> Therefore, a wake-up interrupt triggers the resume of the guest. Guest >>> should resume regardless of the state of Xen (suspended or not). >>> >>> When a guest calls PSCI system suspend the respective domain will be >>> suspended if the following conditions are met: >>> 1) Given resume entry point is not invalid >>> 2) Other (if any) VCPUs of the calling guest are hot-unplugged >>> >>> If the conditions above are met the calling domain is labeled as >>> suspended and the calling VCPU is blocked. If nothing else wouldn't >>> be done the suspended domain would resume from the place where it >>> called PSCI system suspend. This is expected if processing of the PSCI >>> system suspend call fails. However, in the case of success the calling >>> guest should resume (continue execution after the wake-up) from the entry >>> point which is given as the first argument of the PSCI system suspend >>> call. In addition to the entry point, the guest expects to start within >>> the environment whose state matches the state after reset. This means >>> that the guest should find reset register values, MMU disabled, etc. >>> Thereby, the context of VCPU should be 'reset' (as if the system is >>> comming out of reset), the program counter should contain entry point, >>> which is 1st argument, and r0/x0 should contain context ID which is 2nd >>> argument of PSCI system suspend call. The context of VCPU is set >>> accordingly when the PSCI system suspend is processed, so that nothing >>> needs to be done on resume/wake-up path. However, in order to ensure that >>> this context doesn't get overwritten by the scheduler when scheduling out >>> this VCPU (would normally happen after the calling CPU is blocked), we need >>> to check whether to return early from ctxt_switch_from(). >>> >>> There are variables in domain structure to keep track of domain shutdown. >>> One of existing shutdown reason is 'suspend' which this patch is using to >>> track the suspend state of a domain. Those variables are used to determine >>> whether to early return from ctxt_switch_from() or not. >>> >>> A suspended domain will resume after the Xen receives an interrupt which is >>> targeted to the domain, unblocks the domain's VCPU, and schedules it in. >>> When the VCPU is scheduled in, the VCPU context is already reset, and >>> contains the right resume entry point in program counter that will be >>> restored in ctxt_switch_to(). The only thing that needs to be done at this >>> point is to clear the variables that marked the domain state as suspended. >>> >>> Signed-off-by: Mirela Simonovic >>> Signed-off-by: Saeed Nowshadi >>> >>> --- >>> Changes in v2: >>> >>> -Fix print to compile for arm32 and to align with Xen coding style >>> --- >>> xen/arch/arm/Makefile| 1 + >>> xen/arch/arm/domain.c| 13 +++ >>> xen/arch/arm/suspend.c | 166 >>> +++ >>> xen/arch/arm/vpsci.c | 19 + >>> xen/include/asm-arm/perfc_defn.h | 1 + >>> xen/include/asm-arm/psci.h | 2 + >>> xen/include/asm-arm/suspend.h| 16 >>> xen/include/xen/sched.h | 1 + >>> 8 files changed, 219 insertions(+) >>> create mode 100644 xen/arch/arm/suspend.c >>> create mode 100644 xen/include/asm-arm/suspend.h >>> >>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile >>> index 23c5d9adbc..744b1a4dc8 100644 >>> --- a/xen/arch/arm/Makefile >>> +++ b/xen/arch/arm/Makefile >>> @@ -43,6 +43,7 @@ obj-y += setup.o >>> obj-y += shutdown.o >>> obj-y += smp.o >>> obj-y += smpboot.o >>> +obj-y += suspend.o >>> obj-y += sysctl.o >>> obj-y += time.o >>> obj-y += traps.o >>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >>> index e594b48d81..7f8105465c 100644 >>> --- a/xen/arch/arm/domain.c >>> +++ b/xen/arch/arm/domain.c >>> @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) >>> if ( is_idle_vcpu(p) ) >>> return; >>> >>> +/* VCPU's context should not be saved if its domain is suspended */ >>> +if ( p->domain->is_shut_down && >>> +(p->domain->shutdown_code == SHUTDOWN_suspend) ) >>> +return; >> SHUTDOWN_suspend is used
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
Hi Julien, Thanks for your feedback, I'll need to answer in iterations. On Mon, Nov 12, 2018 at 4:27 PM Julien Grall wrote: > > Hi Mirela, > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > The implementation consists of: > > -Adding PSCI system suspend call as new PSCI function > > -Trapping PSCI system_suspend HVC > > -Implementing PSCI system suspend call (virtual interface that allows > > guests to suspend themselves) > > > > The PSCI system suspend should be called by a guest from its boot > > VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI > > CPU_OFF call prior to issuing PSCI system suspend. Interrupts that > > are left enabled by the guest are assumed to be its wake-up interrupts. > > Therefore, a wake-up interrupt triggers the resume of the guest. Guest > > should resume regardless of the state of Xen (suspended or not). > > > > When a guest calls PSCI system suspend the respective domain will be > > suspended if the following conditions are met: > > 1) Given resume entry point is not invalid > > 2) Other (if any) VCPUs of the calling guest are hot-unplugged > > > > If the conditions above are met the calling domain is labeled as > > suspended and the calling VCPU is blocked. If nothing else wouldn't > > be done the suspended domain would resume from the place where it > > called PSCI system suspend. This is expected if processing of the PSCI > > system suspend call fails. However, in the case of success the calling > > guest should resume (continue execution after the wake-up) from the entry > > point which is given as the first argument of the PSCI system suspend > > call. In addition to the entry point, the guest expects to start within > > the environment whose state matches the state after reset. This means > > that the guest should find reset register values, MMU disabled, etc. > > Thereby, the context of VCPU should be 'reset' (as if the system is > > comming out of reset), the program counter should contain entry point, > > which is 1st argument, and r0/x0 should contain context ID which is 2nd > > argument of PSCI system suspend call. The context of VCPU is set > > accordingly when the PSCI system suspend is processed, so that nothing > > needs to be done on resume/wake-up path. However, in order to ensure that > > this context doesn't get overwritten by the scheduler when scheduling out > > this VCPU (would normally happen after the calling CPU is blocked), we need > > to check whether to return early from ctxt_switch_from(). > > > > There are variables in domain structure to keep track of domain shutdown. > > One of existing shutdown reason is 'suspend' which this patch is using to > > track the suspend state of a domain. Those variables are used to determine > > whether to early return from ctxt_switch_from() or not. > > > > A suspended domain will resume after the Xen receives an interrupt which is > > targeted to the domain, unblocks the domain's VCPU, and schedules it in. > > When the VCPU is scheduled in, the VCPU context is already reset, and > > contains the right resume entry point in program counter that will be > > restored in ctxt_switch_to(). The only thing that needs to be done at this > > point is to clear the variables that marked the domain state as suspended. > > > > Signed-off-by: Mirela Simonovic > > Signed-off-by: Saeed Nowshadi > > > > --- > > Changes in v2: > > > > -Fix print to compile for arm32 and to align with Xen coding style > > --- > > xen/arch/arm/Makefile| 1 + > > xen/arch/arm/domain.c| 13 +++ > > xen/arch/arm/suspend.c | 166 > > +++ > > xen/arch/arm/vpsci.c | 19 + > > xen/include/asm-arm/perfc_defn.h | 1 + > > xen/include/asm-arm/psci.h | 2 + > > xen/include/asm-arm/suspend.h| 16 > > xen/include/xen/sched.h | 1 + > > 8 files changed, 219 insertions(+) > > create mode 100644 xen/arch/arm/suspend.c > > create mode 100644 xen/include/asm-arm/suspend.h > > > > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > > index 23c5d9adbc..744b1a4dc8 100644 > > --- a/xen/arch/arm/Makefile > > +++ b/xen/arch/arm/Makefile > > @@ -43,6 +43,7 @@ obj-y += setup.o > > obj-y += shutdown.o > > obj-y += smp.o > > obj-y += smpboot.o > > +obj-y += suspend.o > > obj-y += sysctl.o > > obj-y += time.o > > obj-y += traps.o > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > > index e594b48d81..7f8105465c 100644 > > --- a/xen/arch/arm/domain.c > > +++ b/xen/arch/arm/domain.c > > @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) > > if ( is_idle_vcpu(p) ) > > return; > > > > +/* VCPU's context should not be saved if its domain is suspended */ > > +if ( p->domain->is_shut_down && > > +(p->domain->shutdown_code == SHUTDOWN_suspend) ) > > +return; > SHUTDOWN_suspend is used in Xen for other purpose (see > SCHEDOP_shutdown). The
Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume
Hi, On 11/12/18 11:30 AM, Mirela Simonovic wrote: The MMU needs to be enabled in the resume flow before the context can be restored (we need to be able to access the context data by virtual address in order to restore it). The configuration of system registers prior to branching to the routine that sets up the page tables is copied from xen/arch/arm/arm64/head.S. After the MMU is enabled, the content of TTBR0_EL2 is changed to point to init_ttbr (page tables used at runtime). At boot the init_ttbr variable is updated when a secondary CPU is hotplugged. In the scenario where there is only one physical CPU in the system, the init_ttbr would not be initialized for the use in resume flow. To get the variable initialized in all scenarios in this patch we add that the boot CPU updates init_ttbr after it sets the page tables for runtime. After the memory management is resumed, the SCTLR_WXN in SCTLR_EL2 has to be set in order to configure that a mapping cannot be both writable and executable (this was configured prior to suspend). This is done using an existing function (mmu_init_secondary_cpu). Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- Changes in v2: - Patch from v1: "[XEN PATCH 17/21] xen/arm: Set SCTLR_WXN in SCTLR_EL2 on resume" is squashed with this patch, because it is indeed related to resuming the memory management - Since the original patch was named 'Enable the MMU', and this is not only enabling anymore, but the full resume of functionality, the commit title and message is fixed --- xen/arch/arm/arm64/entry.S | 88 ++ xen/arch/arm/mm.c | 1 + xen/arch/arm/suspend.c | 6 3 files changed, 95 insertions(+) diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S index dbc4717903..5efa30e8ee 100644 --- a/xen/arch/arm/arm64/entry.S +++ b/xen/arch/arm/arm64/entry.S @@ -1,6 +1,7 @@ #include #include #include +#include #include #include #include @@ -534,6 +535,93 @@ ENTRY(__context_switch) ret ENTRY(hyp_resume) +msr DAIFSet, 0xf /* Disable all interrupts */ + +tlbi alle2 +dsb sy /* Ensure completion of TLB flush */ +isb + +ldr x0, =start +adr x19, start /* x19 := paddr (start) */ +sub x20, x19, x0 /* x20 := phys-offset */ + +/* call PROCINFO_cpu_init here */ + +/* Set up memory attribute type tables */ +ldr x0, =MAIRVAL +msr mair_el2, x0 + +/* Set up TCR_EL2: + * PS -- Based on ID_AA64MMFR0_EL1.PARange + * Top byte is used + * PT walks use Inner-Shareable accesses, + * PT walks are write-back, write-allocate in both cache levels, + * 48-bit virtual address space goes through this table. */ +ldr x0, =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48)) +/* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] (PS) */ +mrs x1, ID_AA64MMFR0_EL1 +bfi x0, x1, #16, #3 + +msr tcr_el2, x0 + +/* Set up the SCTLR_EL2: + * Exceptions in LE ARM, + * Low-latency IRQs disabled, + * Write-implies-XN disabled (for now), + * D-cache disabled (for now), + * I-cache enabled, + * Alignment checking disabled, + * MMU translation disabled (for now). */ +ldr x0, =(HSCTLR_BASE) +msr SCTLR_EL2, x0 + +/* Ensure that any exceptions encountered at EL2 + * are handled using the EL2 stack pointer, rather + * than SP_EL0. */ +msr spsel, #1 + +/* Rebuild the boot pagetable's first-level entries. The structure + * is described in mm.c. + * + * After the CPU enables paging it will add the fixmap mapping + * to these page tables, however this may clash with the 1:1 + * mapping. So each CPU must rebuild the page tables here with + * the 1:1 in place. */ + +/* If Xen is loaded at exactly XEN_VIRT_START then we don't + * need an additional 1:1 mapping, the virtual mapping will + * suffice. + */ +cmp x19, #XEN_VIRT_START +cset x25, eq/* x25 := identity map in place, or not */ + +/* Write Xen's PT's paddr into TTBR0_EL2 */ +ldr x4, =boot_pgtable /* xen_pgtable*/ +add x4, x4, x20 /* x4 := paddr (boot_pagetable) */ +msr TTBR0_EL2, x4 + +/* Set up page tables */ +blsetup_page_tables + +ldr x1, =mmu_resumed /* Explicit vaddr, not RIP-relative */ +mrs x0, SCTLR_EL2 +orr x0, x0, #SCTLR_M /* Enable MMU */ +orr x0, x0, #SCTLR_C /* Enable D-cache */ +dsb sy/* Flush PTE writes and finish reads */ +msr SCTLR_EL2, x0 /* now
[Xen-devel] [PATCH v2 1/5] xen/domain: Introduce a new sanitise_domain_config() helper
Call it from the head of domain_create() (before doing any memory
allocations), which will apply the checks to dom0 as well as domU's.
For now, just subsume the XEN_DOMCTL_CDF_* check from XEN_DOMCTL_createdomain.
In an effort to aid future developoment, leave a debug printk() identifying
the cause of sanitisation failures.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
v2:
* Rename to sanitise_domain_config()
* Leave a dprintk() behind
---
xen/common/domain.c | 18 ++
xen/common/domctl.c | 9 -
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index d6650f0..22aa634 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -288,6 +288,21 @@ static void _domain_destroy(struct domain *d)
free_domain_struct(d);
}
+static int sanitise_domain_config(struct xen_domctl_createdomain *config)
+{
+if ( config->flags & ~(XEN_DOMCTL_CDF_hvm_guest |
+ XEN_DOMCTL_CDF_hap |
+ XEN_DOMCTL_CDF_s3_integrity |
+ XEN_DOMCTL_CDF_oos_off |
+ XEN_DOMCTL_CDF_xs_domain) )
+{
+dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
+return -EINVAL;
+}
+
+return 0;
+}
+
struct domain *domain_create(domid_t domid,
struct xen_domctl_createdomain *config,
bool is_priv)
@@ -297,6 +312,9 @@ struct domain *domain_create(domid_t domid,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
int err, init_status = 0;
+if ( config && (err = sanitise_domain_config(config)) )
+return ERR_PTR(err);
+
if ( (d = alloc_domain_struct()) == NULL )
return ERR_PTR(-ENOMEM);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index b294881..d08b627 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -498,15 +498,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
domid_tdom;
static domid_t rover = 0;
-ret = -EINVAL;
-if ( (op->u.createdomain.flags &
- ~(XEN_DOMCTL_CDF_hvm_guest
- | XEN_DOMCTL_CDF_hap
- | XEN_DOMCTL_CDF_s3_integrity
- | XEN_DOMCTL_CDF_oos_off
- | XEN_DOMCTL_CDF_xs_domain)) )
-break;
-
dom = op->domain;
if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 5/5] Revert "xen/arm: vgic-v3: Delay the initialization of the domain information"
This reverts commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db. The domain
creation logic has been adjusted to set up d->max_vcpus early enough to be
usable in vgic_v3_domain_init().
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 519cc72..474be13 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1573,11 +1573,9 @@ static const struct mmio_handler_ops
vgic_distr_mmio_handler = {
.write = vgic_v3_distr_mmio_write,
};
-static int vgic_v3_real_domain_init(struct domain *d);
-
static int vgic_v3_vcpu_init(struct vcpu *v)
{
-int i, rc;
+int i;
paddr_t rdist_base;
struct vgic_rdist_region *region;
unsigned int last_cpu;
@@ -1586,19 +1584,6 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
struct domain *d = v->domain;
/*
- * This is the earliest place where the number of vCPUs is
- * known. This is required to initialize correctly the vGIC v3
- * domain structure. We only to do that when vCPU 0 is
- * initilialized.
- */
-if ( v->vcpu_id == 0 )
-{
-rc = vgic_v3_real_domain_init(d);
-if ( rc )
-return rc;
-}
-
-/*
* Find the region where the re-distributor lives. For this purpose,
* we look one region ahead as we have only the first CPU in hand.
*/
@@ -1660,7 +1645,7 @@ static inline unsigned int vgic_v3_max_rdist_count(struct
domain *d)
GUEST_GICV3_RDIST_REGIONS;
}
-static int vgic_v3_real_domain_init(struct domain *d)
+static int vgic_v3_domain_init(struct domain *d)
{
struct vgic_rdist_region *rdist_regions;
int rdist_count, i, ret;
@@ -1763,16 +1748,6 @@ static int vgic_v3_real_domain_init(struct domain *d)
return 0;
}
-static int vgic_v3_domain_init(struct domain *d)
-{
-/*
- * The domain initialization for vGIC v3 is delayed until the first vCPU
- * is created. This because the initialization may require to know the
- * number of vCPUs that is not known when creating the domain.
- */
-return 0;
-}
-
static void vgic_v3_domain_free(struct domain *d)
{
vgic_v3_its_free_domain(d);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 4/5] xen/domain: Allocate d->vcpu[] earlier during domain_create()
The ARM code has a chicken-and-egg problem. One of the vGIC_v3 emulations
wants to know d->max_vcpus to be able to size itself appropriately, but the
current order of initialisation requires the vGIC to be set up before the
requested number of vcpus can be checked.
Move the range checking of config->max_vcpus into sanitise_domain_config()
path, which allows for the allocation of d->vcpu[] and d->max_vcpus to happen
earlier during create, and in particular, before the call to
arch_domain_create().
The x86 side is fairly easy, and implements the logical equivalent of
domain_max_vcpus() but using XEN_DOMCTL_CDF_hvm_guest rather than
is_hvm_domain().
For the ARM side, re-purpose vgic_max_vcpus() to take a domctl vGIC version,
and return the maximum number of supported vCPUs, reusing 0 for "version not
supported". To avoid exporting the vgic_ops structures (which are in the
process of being replaced), hard code the upper limits.
This allows for the removal of the domain_max_vcpus() infrastructure, which is
done to prevent it being reused incorrectly in the future.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/domain.c | 18 ++
xen/arch/arm/vgic-v2.c| 1 -
xen/arch/arm/vgic-v3.c| 5 -
xen/arch/arm/vgic.c | 22 --
xen/arch/arm/vgic/vgic-init.c | 3 ---
xen/arch/arm/vgic/vgic.c | 7 ---
xen/arch/x86/domain.c | 10 ++
xen/common/domain.c | 33 -
xen/include/asm-arm/domain.h | 6 --
xen/include/asm-arm/vgic.h| 5 ++---
xen/include/asm-x86/domain.h | 2 --
11 files changed, 74 insertions(+), 38 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 08ba412..24123ff 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -601,6 +601,8 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
{
+unsigned int max_vcpus;
+
if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) ||
!(config->flags & XEN_DOMCTL_CDF_hap) )
{
@@ -627,6 +629,22 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
}
}
+/* Calculate the maximum number of vcpus from the selected GIC version. */
+max_vcpus = vgic_max_vcpus(config->arch.gic_version);
+
+if ( max_vcpus == 0 )
+{
+dprintk(XENLOG_INFO, "Unsupported GIC version\n");
+return -EINVAL;
+}
+
+if ( config->max_vcpus > max_vcpus )
+{
+dprintk(XENLOG_INFO, "Requested vCPUs (%u) exceeds max (%u)\n",
+config->max_vcpus, max_vcpus);
+return -EINVAL;
+}
+
return 0;
}
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index bf77899..64b141f 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -725,7 +725,6 @@ static const struct vgic_ops vgic_v2_ops = {
.domain_free = vgic_v2_domain_free,
.lpi_to_pending = vgic_v2_lpi_to_pending,
.lpi_get_priority = vgic_v2_lpi_get_priority,
-.max_vcpus = 8,
};
int vgic_v2_init(struct domain *d, int *mmio_count)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c14bcd8..519cc72 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1822,11 +1822,6 @@ static const struct vgic_ops v3_ops = {
.emulate_reg = vgic_v3_emulate_reg,
.lpi_to_pending = vgic_v3_lpi_to_pending,
.lpi_get_priority = vgic_v3_lpi_get_priority,
-/*
- * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
- * that can be supported is up to 4096(==256*16) in theory.
- */
-.max_vcpus = 4096,
};
int vgic_v3_init(struct domain *d, int *mmio_count)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5a4f082..892445e 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -667,9 +667,27 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
clear_bit(virq, d->arch.vgic.allocated_irqs);
}
-unsigned int vgic_max_vcpus(const struct domain *d)
+unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version)
{
-return min_t(unsigned int, MAX_VIRT_CPUS, d->arch.vgic.handler->max_vcpus);
+unsigned int max_vcpus;
+
+switch ( domctl_vgic_version )
+{
+case XEN_DOMCTL_CONFIG_GIC_V2:
+max_vcpus = 8;
+break;
+
+#ifdef CONFIG_GICV3
+case XEN_DOMCTL_CONFIG_GIC_V3:
+max_vcpus = 4092;
+break;
+#endif
+
+default:
+return 0;
+}
+
+return min_t(unsigned int, MAX_VIRT_CPUS, max_vcpus);
}
/*
diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index bfd3d09..62ae553 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -112,9 +112,6 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
BUG();
}
-if ( d->max_vcpus >
[Xen-devel] [PATCH v2 0/5] xen/domain: Allocate d->vcpu[] earlier during domain construction
To fix an order-of-construction issue with gic-v3 on ARM, arrange for d->max_vcpus to be auditied and set up prior to arch_domain_create() This is slightly-RFC because all of the interesting changes are in ARM, and therefore only compile tested by me at this point. This can be found in git tree from from: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-alloc-vcpus-v2 Andrew Cooper (5): xen/domain: Introduce a new sanitise_domain_config() helper xen/domain: Introduce a new arch_sanitise_domain_config() helper xen/domain: Stricter configuration checking xen/domain: Allocate d->vcpu[] earlier during domain_create() Revert "xen/arm: vgic-v3: Delay the initialization of the domain information" xen/arch/arm/domain.c | 70 +--- xen/arch/arm/vgic-v2.c| 1 - xen/arch/arm/vgic-v3.c| 34 ++ xen/arch/arm/vgic.c | 22 ++-- xen/arch/arm/vgic/vgic-init.c | 3 -- xen/arch/arm/vgic/vgic.c | 7 ++-- xen/arch/x86/domain.c | 55 xen/common/domain.c | 83 +-- xen/common/domctl.c | 9 - xen/include/asm-arm/domain.h | 6 xen/include/asm-arm/vgic.h| 5 ++- xen/include/asm-x86/domain.h | 2 -- xen/include/xen/sched.h | 6 13 files changed, 179 insertions(+), 124 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] guest/pvh: special case the low 1MB
On Fri, Nov 09, 2018 at 06:22:50PM +0100, Roger Pau Monne wrote: > When running as a PVH guest Xen only special cases the trampoline > code in the low 1MB, without also reserving the space used by the > relocated metadata or the trampoline stack. > > Fix this by always reserving the low 1MB regardless of whether Xen is > running as a guest or natively. > > Reported-by: Sergey Dyasli > Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for QEMU
Anthony PERARD writes ("Re: [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for
QEMU"):
> On Mon, Nov 12, 2018 at 03:14:30PM +, Ian Jackson wrote:
> > Yes, it would have to be initialised along with the other members of
> > libxl__domain_build_state.
>
> I didn't manage to findout where this might be. There is
> libxl__build_pre() but I don't know if it's always called. Is this the
> right place, or is it initialised somewhere else?
Eerrrgh.
Just went off on an absurd wild goose chase to try to answer this
question. I think libxl__domain_build_state predates the current more
rigorous approach to async functions; indeed, I think it predates any
async stuff at all.
I did git-log -G and found this
59f8f46a491c9bdc1ad3e0c5ae4f8b48068d13cd
tools: libxl: remove libxl_domain_build_state from the IDL
AFAICT in that commit it works like this:
* There is a libxl__domain_build_state as a local variable in
each of do_domain_create and libxl__create_stubdom, which are
synchronous functions.
* In each case, the struct is passed by reference into
libxl__domain_build. libxl__domain_build does not initialise it
before passing it to libxl__build_pre. It is filled in as we go.
At some point, libxl_domain_build_state became a member of various
parent state structures. Those parent state structures (and the loose
state) are all initialised to zero at allocation time.
In 50f8ba84a50ebf80dd22067a04062dbaaf2621ff
libxl: arm: Fix build after c/s 74fd984ae
libxl__domain_make started to get a pointer to the
libxl__domain_build_state.
AFAICT I think currently libxl__domain_make is actually the first
thing that touches anything in libxl__domain_build_state. So it
should initialise it.
The layering here is ... a mess.
> Also, now I would probably need to call libxl__pre_open_qmp_socket()
> from libxl__spawn_local_dm() as the d_state (libxl_domain_build_info) is
> const when passed to libxl__build_device_model_args. But that is
> probably fine.
d_state is libxl_domain_build_state isn't it ?
libxl_domain_build_info is d_info or some such.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend
Hi,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
When Dom0 finalizes its suspend procedure the suspend of Xen is
triggered by calling system_suspend(). Dom0 finalizes the suspend from
its boot core (VCPU#0), which could be mapped to any physical CPU,
i.e. the system_suspend() function could be executed by any physical
CPU. Since Xen suspend procedure has to be run by the boot CPU
(non-boot CPUs will be disabled at some point in suspend procedure),
system_suspend() execution has to continue on CPU#0.
Nothing in the domain_suspend code checks that domain_suspend is called
by vCPU0. I also can't find any restriction in the PSCI spec to run on
pCPU0. Can you provide more details why this required?
When the system_suspend() returns 0, it means that the system was
suspended and it is coming out of the resume procedure. Regardless
of the system_suspend() return value, after this function returns
Xen is fully functional, and its state, including all devices and data
structures, matches the state prior to calling system_suspend().
The status is returned by system_suspend() for debugging/logging
purposes and function prototype compatibility.
Signed-off-by: Mirela Simonovic
Signed-off-by: Saeed Nowshadi
---
xen/arch/arm/suspend.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index f2338e41db..21b45f8248 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -112,11 +112,20 @@ static void vcpu_suspend(register_t epoint, register_t
cid)
_arch_set_info_guest(v, );
}
+/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
+static long system_suspend(void *data)
+{
+BUG_ON(system_state != SYS_STATE_active);
+
+return -ENOSYS;
+}
+
int32_t domain_suspend(register_t epoint, register_t cid)
{
struct vcpu *v;
struct domain *d = current->domain;
bool is_thumb = epoint & 1;
+int status;
dprintk(XENLOG_DEBUG,
"Dom%d suspend: epoint=0x%"PRIregister", cid=0x%"PRIregister"\n",
@@ -156,6 +165,31 @@ int32_t domain_suspend(register_t epoint, register_t cid)
*/
vcpu_block_unless_event_pending(current);
+/* If this was dom0 the whole system should suspend: trigger Xen suspend */
+if ( is_hardware_domain(d) )
+{
+/*
+ * system_suspend should be called when Dom0 finalizes the suspend
+ * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0 could
+ * be mapped to any PCPU (this function could be executed by any PCPU).
+ * The suspend procedure has to be finalized by the PCPU#0 (non-boot
+ * PCPUs will be disabled during the suspend).
+ */
+status = continue_hypercall_on_cpu(0, system_suspend, NULL);
+/*
+ * If an error happened, there is nothing that needs to be done here
+ * because the system_suspend always returns in fully functional state
+ * no matter what the outcome of suspend procedure is. If the system
+ * suspended successfully the function will return 0 after the resume.
+ * Otherwise, if an error is returned it means Xen did not suspended,
+ * but it is still in the same state as if the system_suspend was never
+ * called. We dump a debug message in case of an error for debugging/
+ * logging purpose.
+ */
+if ( status )
+dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status);
+}
+
return PSCI_SUCCESS;
}
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129846: tolerable all pass - PUSHED
flight 129846 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129846/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 3b439f636ee9a9588203cf0aa0edfa18ccdc60b9 baseline version: xen 28f1c549e77144b61ef315a75b33f6cbc67a73b1 Last test of basis 129836 2018-11-12 10:00:30 Z0 days Testing same since 129846 2018-11-12 13:03:01 Z0 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Julien Grall Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm 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 : To xenbits.xen.org:/home/xen/git/xen.git 28f1c549e7..3b439f636e 3b439f636ee9a9588203cf0aa0edfa18ccdc60b9 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 129834: all pass - PUSHED
flight 129834 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/129834/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd c18ab92e2c2be1b1550a2ac5a33126bc5fc0f0ff baseline version: freebsd 93a7ff50c08a505984e4312bf8f139f6c50d725f Last test of basis 129693 2018-11-09 09:18:46 Z3 days Testing same since 129834 2018-11-12 09:19:12 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> asomers brooks cem delphij emaste eugen jhb jhibbits jilles kevans kib lwhsu manu markj mav shurd trasz vangyzen vmaffione woodsb02 wulf yuripv jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/freebsd.git 93a7ff50c08..c18ab92e2c2 c18ab92e2c2be1b1550a2ac5a33126bc5fc0f0ff -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
Hi Mirela,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
GIC and virtual timer context must be saved when the domain suspends.
Please provide the rationale for this. Is it required by the spec?
This is done by moving the respective code in ctxt_switch_from()
before the return that happens if the domain suspended.
Signed-off-by: Mirela Simonovic
Signed-off-by: Saeed Nowshadi
---
xen/arch/arm/domain.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7f8105465c..bebe3238e8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -97,6 +97,13 @@ static void ctxt_switch_from(struct vcpu *p)
if ( is_idle_vcpu(p) )
return;
+/* VGIC */
+gic_save_state(p);
+
+/* Arch timer */
+p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1);
+virt_timer_save(p);
+
/* VCPU's context should not be saved if its domain is suspended */
The GIC and timer are part of the vCPU context. So this comment looks a
bit stale.
if ( p->domain->is_shut_down &&
(p->domain->shutdown_code == SHUTDOWN_suspend) )
@@ -115,10 +122,6 @@ static void ctxt_switch_from(struct vcpu *p)
p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
-/* Arch timer */
-p->arch.cntkctl = READ_SYSREG32(CNTKCTL_EL1);
-virt_timer_save(p);
-
if ( is_32bit_domain(p->domain) && cpu_has_thumbee )
{
p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
@@ -170,9 +173,6 @@ static void ctxt_switch_from(struct vcpu *p)
/* VFP */
vfp_save_state(p);
-/* VGIC */
-gic_save_state(p);
-
isb();
}
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
