[Xen-devel] [xen-4.9-testing test] 114657: regressions - FAIL
flight 114657 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/114657/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 114543 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 114543 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 114543 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114501 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 114533 test-amd64-amd64-xl-rtds 10 debian-install fail like 114543 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-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-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail 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-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 2040ac14e4cfbae679751796266527d92d11ac78 baseline version: xen de38e28cc2cc62e6e9e4741403e4a8f6c07d8cfd Last test of basis 114543 2017-10-16 11:51:22 Z1 days Testing same since 114657 2017-10-17 20:16:17 Z0 days1 attempts People who touched revisions under test: Bernd Kuhls Thomas Petazzoni Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops
[Xen-devel] [xen-unstable test] 114644: tolerable FAIL - PUSHED
flight 114644 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/114644/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114204 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114204 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114204 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114204 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114204 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114204 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114204 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-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-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen 24fb44e971a62b345c7b6ca3c03b454a1e150abe baseline version: xen 572a78190403e5f2acbd01fa72c35fafe9700169 Last test of basis 114204 2017-10-09 19:19:08 Z8 days Failing since114288 2017-10-10 17:02:59 Z7 days7 attempts Testing same since 114644 2017-10-17 10:49:11 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andre Przywara Andrew Cooper Boris Ostrovsky George Dunlap Ian Jackson Jan Beulich Julien Grall Julien Grall Kevin Tian Konrad Rzeszutek Wilk Manish Jaggi Meng Xu Ross Lagerwall Stefano Stabellini Tim Deegan Vitaly Kuznetsov Volodymyr Babchuk Wei Liu Yi Sun jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt
[Xen-devel] [qemu-mainline test] 114651: regressions - FAIL
flight 114651 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/114651/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 114507 build-amd64-xsm 6 xen-buildfail REGR. vs. 114507 build-i386-xsm6 xen-buildfail REGR. vs. 114507 build-amd64 6 xen-buildfail REGR. vs. 114507 build-armhf-xsm 6 xen-buildfail REGR. vs. 114507 build-armhf 6 xen-buildfail REGR. vs. 114507 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 b
[Xen-devel] [xtf test] 114652: tolerable all pass - PUSHED
flight 114652 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114652/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-4 33 xtf/test-hvm32-xsa-239 fail never pass
test-xtf-amd64-amd64-2 33 xtf/test-hvm32-xsa-239 fail never pass
test-xtf-amd64-amd64-3 33 xtf/test-hvm32-xsa-239 fail never pass
test-xtf-amd64-amd64-5 33 xtf/test-hvm32-xsa-239 fail never pass
test-xtf-amd64-amd64-1 33 xtf/test-hvm32-xsa-239 fail never pass
version targeted for testing:
xtf 4d18dd4a163b7879c262ac661ca983fa9266c308
baseline version:
xtf 9a439d131fcb546d5254522e817694a2d46ffde8
Last test of basis 114351 2017-10-11 13:31:45 Z6 days
Testing same since 114652 2017-10-17 13:54:44 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64-xtf pass
build-amd64 pass
build-amd64-pvopspass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xtf
+ revision=4d18dd4a163b7879c262ac661ca983fa9266c308
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf
4d18dd4a163b7879c262ac661ca983fa9266c308
+ branch=xtf
+ revision=4d18dd4a163b7879c262ac661ca983fa9266c308
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.:.
PERLLIB=.:.:.
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x4d18dd4a163b7879c262ac661ca983fa9266c308 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osst
[Xen-devel] [PATCH] aarch64: advertise the GIC system register interface
Advertise the presence of the GIC system register interface (1<<24) according to H9.248 of the ARM ARM. This patch allows Xen to boot on QEMU aarch64. Signed-off-by: Stefano Stabellini diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 670c07a..a451763 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj) cpu->id_isar3 = 0x01112131; cpu->id_isar4 = 0x00011142; cpu->id_isar5 = 0x00011121; -cpu->id_aa64pfr0 = 0x; +cpu->id_aa64pfr0 = 0x0100; cpu->id_aa64dfr0 = 0x10305106; cpu->pmceid0 = 0x; cpu->pmceid1 = 0x; @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar3 = 0x01112131; cpu->id_isar4 = 0x00011142; cpu->id_isar5 = 0x00011121; -cpu->id_aa64pfr0 = 0x; +cpu->id_aa64pfr0 = 0x0100; cpu->id_aa64dfr0 = 0x10305106; cpu->id_aa64isar0 = 0x00011120; cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 11/13] xen/pvcalls: implement poll command
>
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> + int notify, req_id, ret;
> + struct xen_pvcalls_request *req;
> +
> + if (test_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags)) {
> + uint32_t req_id = READ_ONCE(map->passive.inflight_req_id);
> +
> + if (req_id != PVCALLS_INVALID_ID &&
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id)
> + return POLLIN | POLLRDNORM;
Same READ_ONCE() question as for an earlier patch.
-boris
> +
> + poll_wait(file, &map->passive.inflight_accept_req, wait);
> + return 0;
> + }
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 114646: regressions - FAIL
flight 114646 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/114646/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 113603 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 113603 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 17 guest-stop fail REGR. vs. 113603 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 113603 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail REGR. vs. 113603 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 113603 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113603 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113603 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113603 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 113603 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-pvhv2-amd 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-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 13 migrate-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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-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-qemut-ws16-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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxb8342068e3011832d723aa379a3180d37a4d59df baseline version: linux5fbef6af7dd9a92605bb7c426f26bd122fd0cd74 Last test of basis 113603 2017-09-19 13:21:36 Z 28 days Testing same since 114646 2017-10-17 10:48:56 Z0 days1 attempts People who touched revisions under test: Aaron Ma AL Yu-Chen Cho Alan Stern Aleksa Sarai Aleksandr Bezzubikov Alex Deucher Alexander Potapenko Andrew Morton Andrey Korolyov Andy Lutomirski Archit Taneja Arnd Bergmann Baohong Liu Bart Van Assche Bastien Nocera Ben Hutchings Ben Seri Benjamin Block Bjorn Helgaas Boris Brezillon Charles Milette Charles Milette Chris Wilson Christian Lamparter Christophe JAILLET Chuck Lever Chunyu Hu Claudiu Manoil Colin Ian King Coly Li Cong Wang Dan Carpenter Dan Priamo Daniel Mentz Dave Chinner Dave Martin David S
[Xen-devel] [PATCH v2 1/2] x86/boot: fix early error display
From: David Esler In 9180f5365524 a change was made to the send_chr function to take in C-strings and print out a character at a time until a NULL was encountered. However there is no code to increment the current character position resulting in an endless loop of the first character. This adds a simple increment. Reviewed-by: Doug Goldstein Signed-off-by: David Esler --- xen/arch/x86/boot/head.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index fd6fc337fe..9cc35da558 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -173,10 +173,11 @@ not_multiboot: .Lget_vtb: mov sym_esi(vga_text_buffer),%edi .Lsend_chr: -mov (%esi),%bl -test%bl,%bl# Terminate on '\0' sentinel +lodsb +test%al,%al# Terminate on '\0' sentinel je .Lhalt mov $0x3f8+5,%dx # UART Line Status Register +mov %al,%bl 2: in %dx,%al test$0x20,%al # Test THR Empty flag je 2b @@ -185,7 +186,7 @@ not_multiboot: out %al,%dx# Send a character over the serial line test%edi,%edi # Is the VGA text buffer available? jz .Lsend_chr -movsb # Write a character to the VGA text buffer +stosb # Write a character to the VGA text buffer mov $7,%al stosb # Write an attribute to the VGA text buffer jmp .Lsend_chr -- 2.13.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/boot: rename send_chr to print_err
From: David Esler The send_chr function sends an entire C-string and not one character and doesn't necessarily just send it over the serial UART anymore so rename it to print_err so that its closer in name to what it does. Reviewed-by: Doug Goldstein Signed-off-by: David Esler --- xen/arch/x86/boot/head.S | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 9cc35da558..475c678f2c 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -161,7 +161,7 @@ not_multiboot: */ add $sym_offs(.Lbad_ldr_nbs),%esi # Error message xor %edi,%edi # No VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lmb2_efi_ia_32: /* * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer zap is @@ -169,10 +169,10 @@ not_multiboot: */ add $sym_offs(.Lbad_efi_msg),%esi # Error message xor %edi,%edi # No VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lget_vtb: mov sym_esi(vga_text_buffer),%edi -.Lsend_chr: +.Lprint_err: lodsb test%al,%al# Terminate on '\0' sentinel je .Lhalt @@ -185,11 +185,11 @@ not_multiboot: mov %bl,%al out %al,%dx# Send a character over the serial line test%edi,%edi # Is the VGA text buffer available? -jz .Lsend_chr +jz .Lprint_err stosb # Write a character to the VGA text buffer mov $7,%al stosb # Write an attribute to the VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lhalt: hlt jmp .Lhalt -- 2.13.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm: configure interrupts to be in non-secure group1
Xen uses non-secure group1 interrupts, however it doesn't configure the GICv3 accordingly. Xen needs to set GICD_IGROUPR for SPIs and GICR_IGROUPR0 for local interrupt to "1" to specify that interrupts belong to group1. This is particularly important if the system has GICD_CTLR.DS set, also see commit 7c9b973061b03af62734f613f6abec46c0dd4a88 in Linux. Signed-off-by: Stefano Stabellini --- This is a candidate for stable backports. diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 74d00e0..196cfc5 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -569,6 +569,9 @@ static void __init gicv3_dist_init(void) for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 ) writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32) * 4); +for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 ) +writel_relaxed(0x, GICD + GICD_IGROUPR + (i / 32) * 4); + gicv3_dist_wait_for_rwp(); /* Turn on the distributor */ @@ -775,6 +778,7 @@ static int gicv3_cpu_init(void) */ writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICENABLER0); writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ISENABLER0); +writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_IGROUPR0); gicv3_redist_wait_for_rwp(); ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 10/13] xen/pvcalls: implement recvmsg
> +
> +int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t
> len,
> + int flags)
> +{
> + struct pvcalls_bedata *bedata;
> + int ret;
> + struct sock_mapping *map;
> +
> + if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
> + return -EOPNOTSUPP;
> +
> + pvcalls_enter();
> + if (!pvcalls_front_dev) {
> + pvcalls_exit();
> + return -ENOTCONN;
> + }
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> +
> + map = (struct sock_mapping *) sock->sk->sk_send_head;
> + if (!map) {
> + pvcalls_exit();
> + return -ENOTSOCK;
> + }
> +
> + mutex_lock(&map->active.in_mutex);
> + if (len > XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER))
> + len = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> +
> + while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
> + wait_event_interruptible(map->active.inflight_conn_req,
> + pvcalls_front_read_todo(map));
> + }
> + ret = __read_ring(map->active.ring, &map->active.data,
> + &msg->msg_iter, len, flags);
> +
> + if (ret > 0)
> + notify_remote_via_irq(map->active.irq);
> + if (ret == 0)
> + ret = -EAGAIN;
Why not 0? The manpage says:
EAGAIN or EWOULDBLOCK
The socket is marked nonblocking and the receive
operation would block, or a receive timeout
had been set and the timeout expired before data was
received. POSIX.1 allows either error to
be returned for this case, and does not require these
constants to have the same value, so a
portable application should check for both possibilities.
I don't think either of these conditions is true here.
(Again, should have noticed this earlier, sorry)
-boris
> + if (ret == -ENOTCONN)
> + ret = 0;
> +
> + mutex_unlock(&map->active.in_mutex);
> + pvcalls_exit();
> + return ret;
> +}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 09/13] xen/pvcalls: implement sendmsg
> +static int __write_ring(struct pvcalls_data_intf *intf,
> + struct pvcalls_data *data,
> + struct iov_iter *msg_iter,
> + int len)
> +{
> + RING_IDX cons, prod, size, masked_prod, masked_cons;
> + RING_IDX array_size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> + int32_t error;
> +
> + error = intf->out_error;
> + if (error < 0)
> + return error;
> + cons = intf->out_cons;
> + prod = intf->out_prod;
> + /* read indexes before continuing */
> + virt_mb();
> +
> + size = pvcalls_queued(prod, cons, array_size);
> + if (size >= array_size)
> + return 0;
I thought you were going to return an error here? If this can only be
due to someone messing up indexes is there a reason to continue trying
to write? What are the chances that the index will get corrected?
-boris
> + if (len > array_size - size)
> + len = array_size - size;
> +
> + masked_prod = pvcalls_mask(prod, array_size);
> + masked_cons = pvcalls_mask(cons, array_size);
> +
> + if (masked_prod < masked_cons) {
> + copy_from_iter(data->out + masked_prod, len, msg_iter);
> + } else {
> + if (len > array_size - masked_prod) {
> + copy_from_iter(data->out + masked_prod,
> +array_size - masked_prod, msg_iter);
> + copy_from_iter(data->out,
> +len - (array_size - masked_prod),
> +msg_iter);
> + } else {
> + copy_from_iter(data->out + masked_prod, len, msg_iter);
> + }
> + }
> + /* write to ring before updating pointer */
> + virt_wmb();
> + intf->out_prod += len;
> +
> + return len;
> +}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On Tue, Oct 17, 2017 at 04:59:41PM -0400, Boris Ostrovsky wrote: > On 10/17/2017 04:50 PM, Josh Poimboeuf wrote: > > On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: > >> On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > >>> On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > We'd also have to assume that the restore part of an alternative entry > is the same size as the save part. Which is true now. > >>> Why? > >>> > >> Don't you need to know the size of the instruction without save and > >> restore part? > >> > >> + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) > >> > >> Otherwise you'd need another field for the actual instruction length. > > If we know where the CALL instruction starts, and can verify that it > > starts with "ff 15", then we know the instruction length: 6 bytes. > > Right? > > > > Oh, OK. Then you shouldn't need a->replacementlen test(s?) in > apply_alternatives()? Right. Though in the above code it was needed for a different reason, to make sure it wasn't reading past the end of the buffer. -- Josh ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/17/2017 04:50 PM, Josh Poimboeuf wrote: > On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: >> On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: >>> On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > Maybe we can add a new field to the alternatives entry struct which > specifies the offset to the CALL instruction, so apply_alternatives() > can find it. We'd also have to assume that the restore part of an alternative entry is the same size as the save part. Which is true now. >>> Why? >>> >> Don't you need to know the size of the instruction without save and >> restore part? >> >> + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) >> >> Otherwise you'd need another field for the actual instruction length. > If we know where the CALL instruction starts, and can verify that it > starts with "ff 15", then we know the instruction length: 6 bytes. > Right? > Oh, OK. Then you shouldn't need a->replacementlen test(s?) in apply_alternatives()? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: > On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > > On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > >> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > >>> Maybe we can add a new field to the alternatives entry struct which > >>> specifies the offset to the CALL instruction, so apply_alternatives() > >>> can find it. > >> We'd also have to assume that the restore part of an alternative entry > >> is the same size as the save part. Which is true now. > > Why? > > > > Don't you need to know the size of the instruction without save and > restore part? > > + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) > > Otherwise you'd need another field for the actual instruction length. If we know where the CALL instruction starts, and can verify that it starts with "ff 15", then we know the instruction length: 6 bytes. Right? -- Josh ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] libxl: Change the type of console_mfn to xen_pfn_t
On Tue, Oct 17, 2017 at 10:16:30PM +0530, Bhupinder Thakur wrote:
One also explains the rationale in the commit. Perhaps also
include 'Reported-by' ..
> Signed-off-by: Bhupinder Thakur
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Stefano Stabellini
> CC: Julien Grall
>
> tools/libxl/libxl_console.c | 2 +-
> tools/libxl/libxl_dom.c | 2 +-
> tools/libxl/libxl_internal.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 6bfc0e5..f2ca689 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t
> domid,
> flexarray_append(ro_front, "port");
> flexarray_append(ro_front, GCSPRINTF("%"PRIu32,
> state->console_port));
> flexarray_append(ro_front, "ring-ref");
> -flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
> +flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn,
> state->console_mfn));
> } else {
> flexarray_append(front, "state");
> flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index ef834e6..a58e74f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -869,7 +869,7 @@ out:
> static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
> libxl_domain_build_info *info,
> int store_evtchn, unsigned long *store_mfn,
> -int console_evtchn, unsigned long
> *console_mfn,
> +int console_evtchn, xen_pfn_t *console_mfn,
> domid_t store_domid, domid_t console_domid)
> {
> struct hvm_info_table *va_hvm;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 45e6df6..f52aeb3 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1128,7 +1128,7 @@ typedef struct {
>
> uint32_t console_port;
> uint32_t console_domid;
> -unsigned long console_mfn;
> +xen_pfn_t console_mfn;
> char *console_tty;
>
> char *saved_state;
> --
> 2.7.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: >> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: >>> Maybe we can add a new field to the alternatives entry struct which >>> specifies the offset to the CALL instruction, so apply_alternatives() >>> can find it. >> We'd also have to assume that the restore part of an alternative entry >> is the same size as the save part. Which is true now. > Why? > Don't you need to know the size of the instruction without save and restore part? + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) Otherwise you'd need another field for the actual instruction length. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/public: Correct the definition of GNTTAB_CACHE_SOURCE_GREF
On Tue, Oct 17, 2017 at 03:11:51PM +0100, Andrew Cooper wrote:
> Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
>
> (d79) XSA-232 PoC
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25
> (XEN) left shift of 1 by 31 places cannot be represented in type 'int'
> (XEN) [ Xen-4.10.0-rc x86_64 debug=y Tainted:H ]
>
> Update all of the GNTTAB_CACHE_* constants to be unsigned integers.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
> CC: Julien Grall
>
> This is a trivial bugfix, and is low risk for 4.10
> ---
> xen/include/public/grant_table.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/public/grant_table.h
> b/xen/include/public/grant_table.h
> index 018036e..180d62c 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -589,9 +589,9 @@ struct gnttab_cache_flush {
> } a;
> uint16_t offset; /* offset from start of grant */
> uint16_t length; /* size within the grant */
> -#define GNTTAB_CACHE_CLEAN (1<<0)
> -#define GNTTAB_CACHE_INVAL (1<<1)
> -#define GNTTAB_CACHE_SOURCE_GREF(1<<31)
> +#define GNTTAB_CACHE_CLEAN (1u<<0)
> +#define GNTTAB_CACHE_INVAL (1u<<1)
> +#define GNTTAB_CACHE_SOURCE_GREF(1u<<31)
> uint32_t op;
> };
> typedef struct gnttab_cache_flush gnttab_cache_flush_t;
> --
> 2.1.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > > We'd also have to assume that the restore part of an alternative entry > is the same size as the save part. Which is true now. Why? -- Josh ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 114643: tolerable FAIL - PUSHED
flight 114643 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/114643/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 12 guest-start fail blocked in 114528 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail blocked in 114528 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114528 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114528 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114528 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114528 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114528 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114528 test-amd64-amd64-xl-rtds 10 debian-install fail like 114528 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114528 test-amd64-i386-libvirt-xsm 13 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-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-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-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-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install 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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux3728e6a255b50382591ee374c70e6f5276a47d0a baseline version: linuxae7df8f985f1b0445366ae6f6324cd08a218526e Last test of basis 114528 2017-10-15 14:30:42 Z2 days Failing since114541 2017-10-16 07:50:09 Z1 days2 attempts Testing same since 114643 2017-10-17 10:48:18 Z0 days1 attempts People who touched revisions under test: Colin Ian King Geert Uytterhoeven Hans Verkuil Hans Verkuil Hans Verkuil Jose Abreu Jose Abreu Laurent Pinchart Linus Torvalds Mauro Carvalho Chehab Sean Young Stanimir Varbanov Sylwester Nawrocki Todor Tomov jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops
Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator
On Tue, Oct 17, 2017 at 06:30:13PM +0100, Julien Grall wrote:
> >>On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >>>Add basic OP-TEE mediator as an example how TEE mediator framework
> >>>works.
> >>>
> >>>Currently it support only calls from Dom0. Calls from other guests
> >>>will be declined. It maps OP-TEE static shared memory region into
> >>>Dom0 address space, so Dom0 is the only domain which can work with
> >>>older versions of OP-TEE.
> >>>
> >>>Also it alters SMC requests by\ adding domain id to request. OP-TEE
> >>>can use this information to track requesters.
> >>>
> >>>Albeit being in early development stages, this mediator already can
> >>>be used on systems where only Dom0 interacts with OP-TEE.
> >>
> >>A link to the spec would be useful here to be able to fully review this
> >>patch.
> >Which spec? OP-TEE protocol? It was added in previous commit.
>
> So basically you are saying the header is the documentation of the API?
> There are not external documentation making easier to follow the version...?
There are high-level documentation at [1]. All details are covered in headers.
> >
> >>>
> >>>It was tested on RCAR Salvator-M3 board.
> >>
> >>Is it with the stock op-tee? Or an updated version?
> >Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with
> >my build. But my patches are already merged. OP-TEE 2.6.0 will support
> >dynamic SHM out of the box.
> >
> >>>
> >>>Signed-off-by: Volodymyr Babchuk
> >>>---
> >>> xen/arch/arm/tee/Kconfig | 4 ++
> >>> xen/arch/arm/tee/Makefile | 1 +
> >>> xen/arch/arm/tee/optee.c | 178
> >>> ++
> >>> 3 files changed, 183 insertions(+)
> >>> create mode 100644 xen/arch/arm/tee/optee.c
> >>>
> >>>diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
> >>>index e69de29..7c6b5c6 100644
> >>>--- a/xen/arch/arm/tee/Kconfig
> >>>+++ b/xen/arch/arm/tee/Kconfig
> >>>@@ -0,0 +1,4 @@
> >>>+config ARM_OPTEE
> >>>+ bool "Enable OP-TEE mediator"
> >>>+ default n
> >>>+ depends on ARM_TEE
> >>>diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> >>>index c54d479..9d93b42 100644
> >>>--- a/xen/arch/arm/tee/Makefile
> >>>+++ b/xen/arch/arm/tee/Makefile
> >>>@@ -1 +1,2 @@
> >>> obj-y += tee.o
> >>>+obj-$(CONFIG_ARM_OPTEE) += optee.o
> >>>diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
> >>>new file mode 100644
> >>>index 000..0220691
> >>>--- /dev/null
> >>>+++ b/xen/arch/arm/tee/optee.c
> >>>@@ -0,0 +1,178 @@
> >>>+/*
> >>>+ * xen/arch/arm/tee/optee.c
> >>>+ *
> >>>+ * OP-TEE mediator
> >>>+ *
> >>>+ * Volodymyr Babchuk
> >>>+ * Copyright (c) 2017 EPAM Systems.
> >>>+ *
> >>>+ * 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 "optee_msg.h"
> >>>+#include "optee_smc.h"
> >>>+
> >>>+/*
> >>>+ * OP-TEE violates SMCCC when it defines own UID. So we need
> >>>+ * to place bytes in correct order.
> >>
> >>Can you please point the paragraph in the spec where it says that?
> >Sure.
> >
> >>>+ */
> >>>+#define OPTEE_UID (xen_uuid_t){{
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8),
> >>> \
> >>>+(uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24),
> >>> \
> >>>+}}
> >>>+
> >>>+static int optee_init(void)
> >>>+{
> >>>+printk("OP-TEE mediator init done\n");
> >>>+return 0;
> >>>+}
> >>>+
> >>>+static void optee_domain_create(struct domain *d)
> >>>+{
> >>>+/*
> >>>+ * Do nothing at this time.
> >>>+ * In the future this function will notify that new VM is started.
> >>
> >>You already have a new client with the hardware domain. So don't you already
> >>need to notifity OP-TEE?
> >Because currently OP-TEE does not support such notification.
> >
> >>>+ */
> >>>+}
> >>>+
> >>>+static void optee_domain_destroy(struct domain *d)
> >>>+{
> >>
Re: [Xen-devel] [PATCH v5 08/13] xen/pvcalls: implement accept command
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a waitqueue to allow only one outstanding accept command at
> any given time and to implement polling on the passive socket. Introduce
> a flags field to keep track of in-flight accept and poll commands.
>
> Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
> sure that only one accept command is executed at any given time by
> setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
> inflight_accept_req waitqueue.
>
> Convert the new struct sock_mapping pointer into an uint64_t and use it
> as id for the new socket to pass to the backend.
>
> Check if the accept call is non-blocking: in that case after sending the
> ACCEPT command to the backend store the sock_mapping pointer of the new
> struct and the inflight req_id then return -EAGAIN (which will respond
> only when there is something to accept). Next time accept is called,
> we'll check if the ACCEPT command has been answered, if so we'll pick up
> where we left off, otherwise we return -EAGAIN again.
>
> Note that, differently from the other commands, we can use
> wait_event_interruptible (instead of wait_event) in the case of accept
> as we are able to track the req_id of the ACCEPT response that we are
> waiting.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/pvcalls-front.c | 146
>
> drivers/xen/pvcalls-front.h | 3 +
> 2 files changed, 149 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 5433fae..8958e74 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -77,6 +77,16 @@ struct sock_mapping {
> #define PVCALLS_STATUS_BIND 1
> #define PVCALLS_STATUS_LISTEN2
> uint8_t status;
> + /*
> + * Internal state-machine flags.
> + * Only one accept operation can be inflight for a socket.
> + * Only one poll operation can be inflight for a given socket.
> + */
> +#define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
> + uint8_t flags;
> + uint32_t inflight_req_id;
> + struct sock_mapping *accept_map;
> + wait_queue_head_t inflight_accept_req;
> } passive;
> };
> };
> @@ -392,6 +402,8 @@ int pvcalls_front_bind(struct socket *sock, struct
> sockaddr *addr, int addr_len)
> memcpy(req->u.bind.addr, addr, sizeof(*addr));
> req->u.bind.len = addr_len;
>
> + init_waitqueue_head(&map->passive.inflight_accept_req);
> +
> map->active_socket = false;
>
> bedata->ring.req_prod_pvt++;
> @@ -470,6 +482,140 @@ int pvcalls_front_listen(struct socket *sock, int
> backlog)
> return ret;
> }
>
> +int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int
> flags)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + struct sock_mapping *map2 = NULL;
> + struct xen_pvcalls_request *req;
> + int notify, req_id, ret, evtchn, nonblock;
> +
> + pvcalls_enter();
> + if (!pvcalls_front_dev) {
> + pvcalls_exit();
> + return -ENOTCONN;
> + }
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> +
> + map = (struct sock_mapping *) sock->sk->sk_send_head;
> + if (!map) {
> + pvcalls_exit();
> + return -ENOTSOCK;
> + }
> +
> + if (map->passive.status != PVCALLS_STATUS_LISTEN) {
> + pvcalls_exit();
> + return -EINVAL;
> + }
> +
> + nonblock = flags & SOCK_NONBLOCK;
> + /*
> + * Backend only supports 1 inflight accept request, will return
> + * errors for the others
> + */
> + if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags)) {
> + req_id = READ_ONCE(map->passive.inflight_req_id);
> + if (req_id != PVCALLS_INVALID_ID &&
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
READ_ONCE (especially the second one)? I know I may sound fixated on
this but I really don't understand how compiler may do anything wrong if
straight reads were used.
For the first case, I guess, theoretically the compiler may decide to
re-fetch map->passive.inflight_req_id. But even if it did, would that be
a problem? Both of these READ_ONCE targets are updated below before
PVCALLS_FLAG_ACCEPT_INFLIGHT is cleared so there should not be any
change between re-fetching, I think. (The only exception is the noblock
case, which does WRITE_ONCE that don't understand either)
> + map2 = map->passive.accept_map;
> + goto received;
> + }
> + if (nonblock) {
> + pvcalls_exit();
> + return -EAGAIN;
> + }
> +
Re: [Xen-devel] [PATCH] x86/mm: Make PV linear pagetables optional
On 17/10/17 18:10, George Dunlap wrote:
> Allowing pagetables to point to other pagetables of the same level
> (often called 'linear pagetables') has been included in Xen since its
> inception; but recently it has been the source of a number of subtle
> reference-counting bugs.
>
> It is not used by Linux or MiniOS; but it used used by NetBSD and
> Novell Netware. There are significant numbers of people who are never
> going to use the feature, along with significant numbers who need the
> feature.
>
> Add a Kconfig option for the feature (default to 'y'). Also add a
> command-line option to control whether PV linear pagetables are
> allowed (default to 'true').
>
> In order to make the code clean:
> - Introduce LPT_ASSERT(), which only exists if CONFIG_PV_LINEAR_PT is defined
> - Introduce zero_linear_entries() to set page->linear_pt_count to zero
> (or do nothing, as appropriate)
>
> Reported-by: Jann Horn
> Signed-off-by: George Dunlap
Definitely +1 to this kind of arrangement of user choices. Some notes
below.
> diff --git a/docs/misc/xen-command-line.markdown
> b/docs/misc/xen-command-line.markdown
> index eb4995e68b..952368d3be 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1422,6 +1422,22 @@ The following resources are available:
> CDP, one COS will corespond two CBMs other than one with CAT, due to the
> sum of CBMs is fixed, that means actual `cos_max` in use will
> automatically
> reduce to half when CDP is enabled.
> +
> +### pv-linear-pt
> +> `= `
> +
> +> Default: `false`
Only available if Xen is compiled with CONFIG_PV_LINEAR_PT support enabled.
> +
> +Allow PV guests to have pagetable entries pointing to other pagetables
> +of the same level (i.e., allowing L2 PTEs to point to other L2 pages).
> +This technique is often called "linear pagetables", and is sometimes
> +used to allow operating systems a simple way to consistently map the
> +current process's pagetables into its own virtual address space.
> +
> +Linux and MiniOS don't use this technique. NetBSD and Novell Netware
> +do; there may be other custom operating systems which do. If you're
> +certain you don't plan on having PV guests which use this feature,
> +turning it off can reduce the attack surface.
>
> ### rcu-idle-timer-period-ms
> > `= `
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 62d313e3f5..5881b64608 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -654,6 +660,9 @@ static void dec_linear_uses(struct page_info *pg)
> * frame if it is mapped by a different root table. This is sufficient
> and
> * also necessary to allow validation of a root table mapping itself.
> */
> +static bool __read_mostly pv_linear_pt_enable = true;
> +boolean_param("pv-linear-pt", pv_linear_pt_enable);
The _enable suffix just makes the name longer, and (semi-upheld)
convention would be for opt_pv_linear_pt, which is fine even in its used
context below.
> +
> #define define_get_linear_pagetable(level) \
> static int \
> get_##level##_linear_pagetable( \
> diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
> index 26f0153164..7825f36316 100644
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -177,10 +177,15 @@ struct page_info
> * in use.
> */
> struct {
> +#ifdef CONFIG_PV_LINEAR_PT
> u16 nr_validated_ptes:PAGETABLE_ORDER + 1;
> u16 :16 - PAGETABLE_ORDER - 1 - 2;
> s16 partial_pte:2;
> s16 linear_pt_count;
> +#else
> +u16 nr_validated_ptes;
> +s8 partial_pte;
> +#endif
I don't think this is a clever move. Having CONFIG_PV_LINEAR_PT change
the behaviour of nr_validated_ptes and partial_pte is a recipe for
subtle bugs.
An alternative would be to have the dec_linear_{uses,entries}()
BUG_ON(pg->linear_pt_count != 0) when !CONFIG_PV_LINEAR_PT
This way, you don't need LPT_ASSERT(), or play games with the existing
macros to avoid having them evaluate their parameters.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 06/13] xen/pvcalls: implement bind command
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Send PVCALLS_BIND to the backend. Introduce a new structure, part of
> struct sock_mapping, to store information specific to passive sockets.
>
> Introduce a status field to keep track of the status of the passive
> socket.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/pvcalls-front.c | 66
> +
> drivers/xen/pvcalls-front.h | 3 +++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 7c9261b..4cafd9b 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -71,6 +71,13 @@ struct sock_mapping {
>
> wait_queue_head_t inflight_conn_req;
> } active;
> + struct {
> + /* Socket status */
> +#define PVCALLS_STATUS_UNINITALIZED 0
> +#define PVCALLS_STATUS_BIND 1
> +#define PVCALLS_STATUS_LISTEN2
> + uint8_t status;
> + } passive;
> };
> };
>
> @@ -347,6 +354,65 @@ int pvcalls_front_connect(struct socket *sock, struct
> sockaddr *addr,
> return ret;
> }
>
> +int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int
> addr_len)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL;
> + struct xen_pvcalls_request *req;
> + int notify, req_id, ret;
> +
> + if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
> + return -ENOTSUPP;
> +
> + pvcalls_enter();
> + if (!pvcalls_front_dev) {
> + pvcalls_exit();
> + return -ENOTCONN;
The connect patch returns -ENETUNREACH here. Is there a deliberate
distinction between these cases?
Other than that
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework
On 17/10/17 18:22, Volodymyr Babchuk wrote:
Hi Julien,
On Tue, Oct 17, 2017 at 05:39:29PM +0100, Julien Grall wrote:
Excuse me, looks like you skipped my thoughts about how to detect
TEE if we are not sure, that we are running on SMCCC-capable platform.
How do you think, is it appropriate to rely on DT?
I didn't have any opinion as long as it covers most of the TEE and does
not make any assumption on the platform other than written in the ARM ARM.
I have no idea how Linux is doing the detection, it might be worth for
you to have a look there.
[...]
@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
goto fail;
+/* Notify TEE that new domain was created */
+tee_domain_create(d);
I am not a big fan to see this in arch_domain_create until we see how this
is going to fit with guest. For instance, will TEE be for every guests? What
would be the other necessary information to configure it?...
I think I'll call XSM in tee_domain_create() to check if this domain allowed
to work with TEE. I can't imagine what additional information will be needed.
This interface can be extended in the future, though.
You will never need to inform TEE that a new client (aka domain) is been
created, nor allocated memory for the TEE at domain creation in Xen?
Yes. You are right. But then there are another question: what to do
if tee_domain_create() failed? Prevent domain creation? Or create
domain anyways, but forbid it to call TEE?
I would expect TEE to not be enabled by default for guests. This would
be user configurable. So if it requests TEE and it is not possible to
instantiate one, then the domain creation should failed.
[...]
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
new file mode 100644
index 000..7f7a846
--- /dev/null
+++ b/xen/arch/arm/tee/tee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/tee.c
+ *
+ * Generic part of TEE mediator subsystem
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * 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
+
+/*
+ * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner
+ * for generic TEE queries is 63.
+ */
+#define TRUSTED_OS_GENERIC_API_OWNER 63
+
+#define ARM_SMCCC_FUNC_GET_TEE_UID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_CONV_32, \
+ TRUSTED_OS_GENERIC_API_OWNER,\
+ ARM_SMCCC_FUNC_CALL_UID)
This likely needs to be defined in smccc as AFAIU it is part of the SMCCC.
It only used there. I'm not sure if I should define it globally.
Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely
TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem
definition in smccc.h.
Yes, will do in this way.
[...]
+printk("No TEE found\n");
+return;
+}
+
+parse_uid(resp, &tee_uid);
+
+printk("TEE UID:
%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
+ tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ],
Please no space before ]. This is making more confusing to read.
I put it for neat formatting. Probably, I can put double space after commas.
Will be okay?
That is that really important to have them? I mean, ok it is not going to be
neat but the format string is already ugly and it would not be too difficult
to read the arguments.
Dunno. As for me, it eases parsing. For example, it is easy to see that
all indexes are correct. But if this is inappropriate, I can remove all
extra spaces.
Well, if you are going to do a different probe than via SMCCC, then this
discussion is not necessary as the printk would likely disappear.
+ tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ],
+ tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11],
+ tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]);
+
+for ( desc = _steemediator; desc != _eteemediator; desc++ )
{
+if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 )
+{
+printk("Using TEE mediator for %sp\n", desc->name);
+mediator_ops = desc->ops;
+break;
+}
}
+
+if ( !mediator_ops )
A warning here would be useful.
Why? Platform is not obligued to have any TEE.
What do you mean? You can only be here because
Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator
On 17/10/17 18:08, Volodymyr Babchuk wrote:
On Mon, Oct 16, 2017 at 03:36:38PM +0100, Julien Grall wrote:
Hi Volodymyr,
Hi Julien,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
Add basic OP-TEE mediator as an example how TEE mediator framework
works.
Currently it support only calls from Dom0. Calls from other guests
will be declined. It maps OP-TEE static shared memory region into
Dom0 address space, so Dom0 is the only domain which can work with
older versions of OP-TEE.
Also it alters SMC requests by\ adding domain id to request. OP-TEE
can use this information to track requesters.
Albeit being in early development stages, this mediator already can
be used on systems where only Dom0 interacts with OP-TEE.
A link to the spec would be useful here to be able to fully review this
patch.
Which spec? OP-TEE protocol? It was added in previous commit.
So basically you are saying the header is the documentation of the API?
There are not external documentation making easier to follow the version...?
It was tested on RCAR Salvator-M3 board.
Is it with the stock op-tee? Or an updated version?
Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with
my build. But my patches are already merged. OP-TEE 2.6.0 will support
dynamic SHM out of the box.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/Kconfig | 4 ++
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/optee.c | 178 ++
3 files changed, 183 insertions(+)
create mode 100644 xen/arch/arm/tee/optee.c
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index e69de29..7c6b5c6 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config ARM_OPTEE
+ bool "Enable OP-TEE mediator"
+ default n
+ depends on ARM_TEE
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index c54d479..9d93b42 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1 +1,2 @@
obj-y += tee.o
+obj-$(CONFIG_ARM_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
new file mode 100644
index 000..0220691
--- /dev/null
+++ b/xen/arch/arm/tee/optee.c
@@ -0,0 +1,178 @@
+/*
+ * xen/arch/arm/tee/optee.c
+ *
+ * OP-TEE mediator
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * 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 "optee_msg.h"
+#include "optee_smc.h"
+
+/*
+ * OP-TEE violates SMCCC when it defines own UID. So we need
+ * to place bytes in correct order.
Can you please point the paragraph in the spec where it says that?
Sure.
+ */
+#define OPTEE_UID (xen_uuid_t){{
\
+(uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8),
\
+(uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24),
\
+(uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8),
\
+(uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24),
\
+(uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8),
\
+(uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24),
\
+(uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8),
\
+(uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24),
\
+}}
+
+static int optee_init(void)
+{
+printk("OP-TEE mediator init done\n");
+return 0;
+}
+
+static void optee_domain_create(struct domain *d)
+{
+/*
+ * Do nothing at this time.
+ * In the future this function will notify that new VM is started.
You already have a new client with the hardware domain. So don't you already
need to notifity OP-TEE?
Because currently OP-TEE does not support such notification.
+ */
+}
+
+static void optee_domain_destroy(struct domain *d)
+{
+/*
+ * Do nothing at this time.
+ * In the future this function will notify that VM is being destroyed.
+ */
Same for the destruction?
The same answer. OP-TEE currently can work with only one domain. I selected
Dom0 for this.
+}
+
+static bool forward_call(struct cpu_user_regs *regs)
+{
+register_t resp[4];
+
+call_smccc_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg
Re: [Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework
Hi Julien,
On Tue, Oct 17, 2017 at 05:39:29PM +0100, Julien Grall wrote:
Excuse me, looks like you skipped my thoughts about how to detect
TEE if we are not sure, that we are running on SMCCC-capable platform.
How do you think, is it appropriate to rely on DT?
[...]
> >>>@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int
> >>>domcr_flags,
> >>> if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
> >>> goto fail;
> >>>+/* Notify TEE that new domain was created */
> >>>+tee_domain_create(d);
> >>
> >>I am not a big fan to see this in arch_domain_create until we see how this
> >>is going to fit with guest. For instance, will TEE be for every guests? What
> >>would be the other necessary information to configure it?...
> >I think I'll call XSM in tee_domain_create() to check if this domain allowed
> >to work with TEE. I can't imagine what additional information will be needed.
> >This interface can be extended in the future, though.
>
> You will never need to inform TEE that a new client (aka domain) is been
> created, nor allocated memory for the TEE at domain creation in Xen?
Yes. You are right. But then there are another question: what to do
if tee_domain_create() failed? Prevent domain creation? Or create
domain anyways, but forbid it to call TEE?
> [...]
>
> >>>diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
> >>>new file mode 100644
> >>>index 000..7f7a846
> >>>--- /dev/null
> >>>+++ b/xen/arch/arm/tee/tee.c
> >>>@@ -0,0 +1,134 @@
> >>>+/*
> >>>+ * xen/arch/arm/tee/tee.c
> >>>+ *
> >>>+ * Generic part of TEE mediator subsystem
> >>>+ *
> >>>+ * Volodymyr Babchuk
> >>>+ * Copyright (c) 2017 EPAM Systems.
> >>>+ *
> >>>+ * 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
> >>>+
> >>>+/*
> >>>+ * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner
> >>>+ * for generic TEE queries is 63.
> >>>+ */
> >>>+#define TRUSTED_OS_GENERIC_API_OWNER 63
> >>>+
> >>>+#define ARM_SMCCC_FUNC_GET_TEE_UID \
> >>>+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >>>+ ARM_SMCCC_CONV_32, \
> >>>+ TRUSTED_OS_GENERIC_API_OWNER,\
> >>>+ ARM_SMCCC_FUNC_CALL_UID)
> >>
> >>This likely needs to be defined in smccc as AFAIU it is part of the SMCCC.
> >It only used there. I'm not sure if I should define it globally.
>
> Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely
> TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem
> definition in smccc.h.
Yes, will do in this way.
> [...]
>
> >>>+printk("No TEE found\n");
> >>>+return;
> >>>+}
> >>>+
> >>>+parse_uid(resp, &tee_uid);
> >>>+
> >>>+printk("TEE UID:
> >>>%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
> >>>+ tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ],
> >>
> >>Please no space before ]. This is making more confusing to read.
> >I put it for neat formatting. Probably, I can put double space after commas.
> >Will be okay?
>
> That is that really important to have them? I mean, ok it is not going to be
> neat but the format string is already ugly and it would not be too difficult
> to read the arguments.
Dunno. As for me, it eases parsing. For example, it is easy to see that
all indexes are correct. But if this is inappropriate, I can remove all
extra spaces.
>
> >
> >>>+ tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ],
> >>>+ tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11],
> >>>+ tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]);
> >>>+
> >>>+for ( desc = _steemediator; desc != _eteemediator; desc++ )
> >>
> >>{
> >>
> >>>+if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 )
> >>>+{
> >>>+printk("Using TEE mediator for %sp\n", desc->name);
> >>>+mediator_ops = desc->ops;
> >>>+break;
> >>>+}
> >>
> >>}
> >>
> >>>+
> >>>+if ( !mediator_ops )
> >>
> >>A warning here would be useful.
> >Why? Platform is not obligued to have any TEE.
>
> What do you mean? You can only be here because the platform has TEE but Xen
> does not have any mediator. You actually print "no TEE found" a bit above.
> So why not printing for when Xen is unable to use it?
Ah, yes. This makes sense.
__
Re: [Xen-devel] [PATCH] tools: libxendevicemodel: Restore symbol versions for 1.0
On 17/10/17 18:06, Wei Liu wrote: > On Tue, Oct 17, 2017 at 06:05:35PM +0100, Ian Jackson wrote: >> In 1462f9ea8f4219d520a530787b80c986e050aa98 >> "tools: libxendevicemodel: Provide xendevicemodel_shutdown" >> we added a new version 1.1 to the symbol map and simply abolished >> the old one. That is quite wrong. >> >> Instead, we should have left the 1.0 map alone and added a new version >> which simply adds the new symbol. >> >> Fix this. >> >> Reported-by: Ross Lagerwall >> CC: Stefano Stabellini >> Signed-off-by: Ian Jackson > Acked-by: Wei Liu Reviewed-by: Andrew Cooper CC'ing Julien for a release ack, as this is a blocker (due to regressing the xendevicemodel ABI from Xen 4.9) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-next] x86/VT-x: Don't rewrite HOST_TR_SELECTOR on every context switch
TSS_ENTRY is a compile time constant, so HOST_TR_SELECTOR can be set up during VMCS construction and left alone thereafter, rather than rewriting it on every context switch. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/hvm/vmx/vmcs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index b5100b5..6042109 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -806,7 +806,6 @@ static void vmx_set_host_env(struct vcpu *v) (unsigned long)(this_cpu(gdt_table) - FIRST_RESERVED_GDT_ENTRY)); __vmwrite(HOST_IDTR_BASE, (unsigned long)idt_tables[cpu]); -__vmwrite(HOST_TR_SELECTOR, TSS_ENTRY << 3); __vmwrite(HOST_TR_BASE, (unsigned long)&per_cpu(init_tss, cpu)); __vmwrite(HOST_SYSENTER_ESP, get_stack_bottom()); @@ -1144,6 +1143,7 @@ static int construct_vmcs(struct vcpu *v) __vmwrite(HOST_GS_SELECTOR, 0); __vmwrite(HOST_FS_BASE, 0); __vmwrite(HOST_GS_BASE, 0); +__vmwrite(HOST_TR_SELECTOR, TSS_ENTRY << 3); /* Host control registers. */ v->arch.hvm_vmx.host_cr0 = read_cr0() | X86_CR0_TS; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/mm: Make PV linear pagetables optional
Allowing pagetables to point to other pagetables of the same level
(often called 'linear pagetables') has been included in Xen since its
inception; but recently it has been the source of a number of subtle
reference-counting bugs.
It is not used by Linux or MiniOS; but it used used by NetBSD and
Novell Netware. There are significant numbers of people who are never
going to use the feature, along with significant numbers who need the
feature.
Add a Kconfig option for the feature (default to 'y'). Also add a
command-line option to control whether PV linear pagetables are
allowed (default to 'true').
In order to make the code clean:
- Introduce LPT_ASSERT(), which only exists if CONFIG_PV_LINEAR_PT is defined
- Introduce zero_linear_entries() to set page->linear_pt_count to zero
(or do nothing, as appropriate)
Reported-by: Jann Horn
Signed-off-by: George Dunlap
---
Changes since XSA
- Add a Kconfig option
- Default to 'on' (rather than 'off').
Release justification: This was originally part of a security fix
embargoed until after the freeze date; it wasn't checked in with the
other security patches in order to allow a discussion about the
default.
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Stefano Stabellini
CC: Konrad Wilk
CC: Julien Grall
---
docs/misc/xen-command-line.markdown | 16
xen/arch/Kconfig| 1 +
xen/arch/arm/mm.c | 1 +
xen/arch/x86/Kconfig| 21
xen/arch/x86/mm.c | 38 +
xen/include/asm-x86/mm.h| 5 +
6 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index eb4995e68b..952368d3be 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1422,6 +1422,22 @@ The following resources are available:
CDP, one COS will corespond two CBMs other than one with CAT, due to the
sum of CBMs is fixed, that means actual `cos_max` in use will automatically
reduce to half when CDP is enabled.
+
+### pv-linear-pt
+> `= `
+
+> Default: `false`
+
+Allow PV guests to have pagetable entries pointing to other pagetables
+of the same level (i.e., allowing L2 PTEs to point to other L2 pages).
+This technique is often called "linear pagetables", and is sometimes
+used to allow operating systems a simple way to consistently map the
+current process's pagetables into its own virtual address space.
+
+Linux and MiniOS don't use this technique. NetBSD and Novell Netware
+do; there may be other custom operating systems which do. If you're
+certain you don't plan on having PV guests which use this feature,
+turning it off can reduce the attack surface.
### rcu-idle-timer-period-ms
> `= `
diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index cf0acb7e89..47287a4985 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -6,3 +6,4 @@ config NR_CPUS
default "128" if ARM
---help---
Specifies the maximum number of physical CPUs which Xen will support.
+
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 3c328e2df5..199155fcd8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -42,6 +42,7 @@
#include
#include
+
struct domain *dom_xen, *dom_io, *dom_cow;
/* Override macros from asm/page.h to make them work with mfn_t */
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 64955dc017..e2fcbaf5cc 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -97,6 +97,27 @@ config TBOOT
Technology (TXT)
If unsure, say Y.
+
+config PV_LINEAR_PT
+ bool "Support for PV linear pagetables"
+ depends on PV
+ default y
+ ---help---
+ Linear pagetables (also called "recursive pagetables") refers
+to the practice of a guest operating system having pagetable
+entries pointing to other pagetables of the same level (i.e.,
+allowing L2 PTEs to point to other L2 pages). Some operating
+systems use it as a simple way to consisently map the current
+process's pagetables into its own virtual address space.
+
+Linux and MiniOS don't use this technique. NetBSD and Novell
+Netware do; there may be other custom operating systems which
+do. If you're certain you don't plan on having PV guests
+which use this feature, turning it off can reduce the attack
+surface.
+
+If unsure, say Y.
+
endmenu
source "common/Kconfig"
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 62d313e3f5..5881b64608 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -587,6 +587,12 @@ static void put_data_page(
put_page(page);
}
+#ifdef CONFIG_PV_LINEAR_PT
+static void zero_linear_entries(struct page_info *pg)
+{
+pg->linear_pt_count = 0;
+}
+
static bool inc_linear_entries(struct page_info *pg)
{
Re: [Xen-devel] [PATCH] x86/mm: Make PV linear pagetables optional
On 10/17/2017 06:10 PM, George Dunlap wrote: > Allowing pagetables to point to other pagetables of the same level > (often called 'linear pagetables') has been included in Xen since its > inception; but recently it has been the source of a number of subtle > reference-counting bugs. > > It is not used by Linux or MiniOS; but it used used by NetBSD and > Novell Netware. There are significant numbers of people who are never > going to use the feature, along with significant numbers who need the > feature. > > Add a Kconfig option for the feature (default to 'y'). Also add a > command-line option to control whether PV linear pagetables are > allowed (default to 'true'). > > In order to make the code clean: > - Introduce LPT_ASSERT(), which only exists if CONFIG_PV_LINEAR_PT is defined > - Introduce zero_linear_entries() to set page->linear_pt_count to zero > (or do nothing, as appropriate) > > Reported-by: Jann Horn > Signed-off-by: George Dunlap > --- > Changes since XSA > - Add a Kconfig option > - Default to 'on' (rather than 'off'). > > Release justification: This was originally part of a security fix > embargoed until after the freeze date; it wasn't checked in with the > other security patches in order to allow a discussion about the > default. > > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Stefano Stabellini > CC: Konrad Wilk > CC: Julien Grall > --- > docs/misc/xen-command-line.markdown | 16 > xen/arch/Kconfig| 1 + > xen/arch/arm/mm.c | 1 + > xen/arch/x86/Kconfig| 21 > xen/arch/x86/mm.c | 38 > + > xen/include/asm-x86/mm.h| 5 + > 6 files changed, 78 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/xen-command-line.markdown > b/docs/misc/xen-command-line.markdown > index eb4995e68b..952368d3be 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1422,6 +1422,22 @@ The following resources are available: > CDP, one COS will corespond two CBMs other than one with CAT, due to the > sum of CBMs is fixed, that means actual `cos_max` in use will > automatically > reduce to half when CDP is enabled. > + > +### pv-linear-pt > +> `= ` > + > +> Default: `false` > + > +Allow PV guests to have pagetable entries pointing to other pagetables > +of the same level (i.e., allowing L2 PTEs to point to other L2 pages). > +This technique is often called "linear pagetables", and is sometimes > +used to allow operating systems a simple way to consistently map the > +current process's pagetables into its own virtual address space. > + > +Linux and MiniOS don't use this technique. NetBSD and Novell Netware > +do; there may be other custom operating systems which do. If you're > +certain you don't plan on having PV guests which use this feature, > +turning it off can reduce the attack surface. > > ### rcu-idle-timer-period-ms > > `= ` > diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig > index cf0acb7e89..47287a4985 100644 > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -6,3 +6,4 @@ config NR_CPUS > default "128" if ARM > ---help--- > Specifies the maximum number of physical CPUs which Xen will support. > + > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 3c328e2df5..199155fcd8 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -42,6 +42,7 @@ > #include > #include > > + Gah -- sorry about the blank lines. Should have looked over the patch better first. I'll wait for feedback on the rest of the patch before I resend. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator
On Mon, Oct 16, 2017 at 03:36:38PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >Add basic OP-TEE mediator as an example how TEE mediator framework
> >works.
> >
> >Currently it support only calls from Dom0. Calls from other guests
> >will be declined. It maps OP-TEE static shared memory region into
> >Dom0 address space, so Dom0 is the only domain which can work with
> >older versions of OP-TEE.
> >
> >Also it alters SMC requests by\ adding domain id to request. OP-TEE
> >can use this information to track requesters.
> >
> >Albeit being in early development stages, this mediator already can
> >be used on systems where only Dom0 interacts with OP-TEE.
>
> A link to the spec would be useful here to be able to fully review this
> patch.
Which spec? OP-TEE protocol? It was added in previous commit.
> >
> >It was tested on RCAR Salvator-M3 board.
>
> Is it with the stock op-tee? Or an updated version?
Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with
my build. But my patches are already merged. OP-TEE 2.6.0 will support
dynamic SHM out of the box.
> >
> >Signed-off-by: Volodymyr Babchuk
> >---
> > xen/arch/arm/tee/Kconfig | 4 ++
> > xen/arch/arm/tee/Makefile | 1 +
> > xen/arch/arm/tee/optee.c | 178
> > ++
> > 3 files changed, 183 insertions(+)
> > create mode 100644 xen/arch/arm/tee/optee.c
> >
> >diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
> >index e69de29..7c6b5c6 100644
> >--- a/xen/arch/arm/tee/Kconfig
> >+++ b/xen/arch/arm/tee/Kconfig
> >@@ -0,0 +1,4 @@
> >+config ARM_OPTEE
> >+bool "Enable OP-TEE mediator"
> >+default n
> >+depends on ARM_TEE
> >diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> >index c54d479..9d93b42 100644
> >--- a/xen/arch/arm/tee/Makefile
> >+++ b/xen/arch/arm/tee/Makefile
> >@@ -1 +1,2 @@
> > obj-y += tee.o
> >+obj-$(CONFIG_ARM_OPTEE) += optee.o
> >diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
> >new file mode 100644
> >index 000..0220691
> >--- /dev/null
> >+++ b/xen/arch/arm/tee/optee.c
> >@@ -0,0 +1,178 @@
> >+/*
> >+ * xen/arch/arm/tee/optee.c
> >+ *
> >+ * OP-TEE mediator
> >+ *
> >+ * Volodymyr Babchuk
> >+ * Copyright (c) 2017 EPAM Systems.
> >+ *
> >+ * 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 "optee_msg.h"
> >+#include "optee_smc.h"
> >+
> >+/*
> >+ * OP-TEE violates SMCCC when it defines own UID. So we need
> >+ * to place bytes in correct order.
>
> Can you please point the paragraph in the spec where it says that?
Sure.
> >+ */
> >+#define OPTEE_UID (xen_uuid_t){{
> >\
> >+(uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8),
> >\
> >+(uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24),
> >\
> >+}}
> >+
> >+static int optee_init(void)
> >+{
> >+printk("OP-TEE mediator init done\n");
> >+return 0;
> >+}
> >+
> >+static void optee_domain_create(struct domain *d)
> >+{
> >+/*
> >+ * Do nothing at this time.
> >+ * In the future this function will notify that new VM is started.
>
> You already have a new client with the hardware domain. So don't you already
> need to notifity OP-TEE?
Because currently OP-TEE does not support such notification.
> >+ */
> >+}
> >+
> >+static void optee_domain_destroy(struct domain *d)
> >+{
> >+/*
> >+ * Do nothing at this time.
> >+ * In the future this function will notify that VM is being destroyed.
> >+ */
>
> Same for the destruction?
The same answer. OP-TEE currently can work with only one domain. I selected
Dom0 for this.
> >+}
> >+
> >+static bool forward_call(struct cpu_user_regs *regs)
> >+{
> >+register_t resp[4];
> >+
> >+call_smccc_smc(get_user_reg(regs, 0),
> >+ get_user_reg(regs, 1),
> >+ get_
Re: [Xen-devel] [PATCH] tools: libxendevicemodel: Restore symbol versions for 1.0
On Tue, Oct 17, 2017 at 06:05:35PM +0100, Ian Jackson wrote: > In 1462f9ea8f4219d520a530787b80c986e050aa98 > "tools: libxendevicemodel: Provide xendevicemodel_shutdown" > we added a new version 1.1 to the symbol map and simply abolished > the old one. That is quite wrong. > > Instead, we should have left the 1.0 map alone and added a new version > which simply adds the new symbol. > > Fix this. > > Reported-by: Ross Lagerwall > CC: Stefano Stabellini > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools: libxendevicemodel: Restore symbol versions for 1.0
In 1462f9ea8f4219d520a530787b80c986e050aa98
"tools: libxendevicemodel: Provide xendevicemodel_shutdown"
we added a new version 1.1 to the symbol map and simply abolished
the old one. That is quite wrong.
Instead, we should have left the 1.0 map alone and added a new version
which simply adds the new symbol.
Fix this.
Reported-by: Ross Lagerwall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
---
tools/libs/devicemodel/libxendevicemodel.map | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/libs/devicemodel/libxendevicemodel.map
b/tools/libs/devicemodel/libxendevicemodel.map
index b0765fa..cefd32b 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -1,4 +1,4 @@
-VERS_1.1 {
+VERS_1.0 {
global:
xendevicemodel_open;
xendevicemodel_create_ioreq_server;
@@ -18,8 +18,12 @@ VERS_1.1 {
xendevicemodel_modified_memory;
xendevicemodel_set_mem_type;
xendevicemodel_inject_event;
- xendevicemodel_shutdown;
xendevicemodel_restrict;
xendevicemodel_close;
local: *; /* Do not expose anything by default */
};
+
+VERS_1.1 {
+ global:
+ xendevicemodel_shutdown;
+} VERS_1.0;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers
On Tue, Oct 17, 2017 at 04:05:23PM +0100, Andrew Cooper wrote: > Rather than opencoding it in two places. While only used in the PV emulation > code, this helper is in principle usable anywhere in the hypervisor. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 04/13] xen/pvcalls: implement socket command and handle events
On 10/06/2017 08:30 PM, Stefano Stabellini wrote: > Send a PVCALLS_SOCKET command to the backend, use the masked > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array > ready for the response, and there cannot be two outstanding responses > with the same req_id. > > Wait for the response by waiting on the inflight_req waitqueue and > check for the req_id field in rsp[req_id]. Use atomic accesses and > barriers to read the field. Note that the barriers are simple smp > barriers (as opposed to virt barriers) because they are for internal > frontend synchronization, not frontend<->backend communication. > > Once a response is received, clear the corresponding rsp slot by setting > req_id to PVCALLS_INVALID_ID. Note that PVCALLS_INVALID_ID is invalid > only from the frontend point of view. It is not part of the PVCalls > protocol. > > pvcalls_front_event_handler is in charge of copying responses from the > ring to the appropriate rsp slot. It is done by copying the body of the > response first, then by copying req_id atomically. After the copies, > wake up anybody waiting on waitqueue. > > socket_lock protects accesses to the ring. > > Create a new struct sock_mapping and convert the pointer into an > uint64_t and use it as id for the new socket to pass to the backend. The > struct will be fully initialized later on connect or bind. In this patch > the struct sock_mapping is empty, the fields will be added by the next > patch. > > sock->sk->sk_send_head is not used for ip sockets: reuse the field to > store a pointer to the struct sock_mapping corresponding to the socket. > This way, we can easily get the struct sock_mapping from the struct > socket. > > Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky with one question: > + /* > + * PVCalls only supports domain AF_INET, > + * type SOCK_STREAM and protocol 0 sockets for now. > + * > + * Check socket type here, AF_INET and protocol checks are done > + * by the caller. > + */ > + if (sock->type != SOCK_STREAM) > + return -ENOTSUPP; > + Is this ENOTSUPP or EOPNOTSUPP? I didn't know the former even existed and include/linux/errno.h suggests that this is NFSv3-specific. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] MAINTAINERS: Make Christian Lindig maintainer for ocaml tools
oxenstored is our default implementation of xenstore, for platforms that have ocaml support. We need it to be maintained. Dave Scott, the only existing maintainer, has had limited availability. Christian has been reveiwing patches and offering opinions where necessary, although activity in this area has been quiet and there has not been a great deal of new development. Christian's contributions have been sensible and I think it would be a good idea now to formally make him a maintainer. CC: Christian Lindig CC: David Scott Signed-off-by: Ian Jackson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4d70923..e30cb70 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -283,6 +283,7 @@ T: git git://xenbits.xen.org/mini-os.git F: config/MiniOS.mk OCAML TOOLS +M: Christian Lindig M: David Scott S: Supported F: tools/ocaml/ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 114653: tolerable all pass - PUSHED
flight 114653 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114653/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 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
version targeted for testing:
xen c4efa25058d3f45bf725d6ebe6429db9adf94b62
baseline version:
xen 24fb44e971a62b345c7b6ca3c03b454a1e150abe
Last test of basis 114547 2017-10-16 15:03:08 Z1 days
Testing same since 114653 2017-10-17 15:02:47 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Roger Pau Monné
Tim Deegan
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=c4efa25058d3f45bf725d6ebe6429db9adf94b62
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
c4efa25058d3f45bf725d6ebe6429db9adf94b62
+ branch=xen-unstable-smoke
+ revision=c4efa25058d3f45bf725d6ebe6429db9adf94b62
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.:.
PERLLIB=.:.:.
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xc4efa25058d3f45bf725d6ebe6429db9adf94b62 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://
[Xen-devel] xenconsole: Define and use a macro INVALID_XEN_PFN instead of -1
xenconsole will use a new macro INVALID_XEN_PFN instead of -1 for initializing
ring-ref.
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Julien Grall
tools/console/daemon/io.c | 10 +-
xen/include/public/xen.h | 2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 1839973..9129f5a 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -658,12 +658,12 @@ static void console_unmap_interface(struct console *con)
{
if (con->interface == NULL)
return;
- if (xgt_handle && con->ring_ref == -1)
+ if (xgt_handle && con->ring_ref == INVALID_XEN_PFN)
xengnttab_unmap(xgt_handle, con->interface, 1);
else
munmap(con->interface, XC_PAGE_SIZE);
con->interface = NULL;
- con->ring_ref = -1;
+ con->ring_ref = INVALID_XEN_PFN;
}
static int console_create_ring(struct console *con)
@@ -698,7 +698,7 @@ static int console_create_ring(struct console *con)
free(type);
/* If using ring_ref and it has changed, remap */
- if (ring_ref != con->ring_ref && con->ring_ref != -1)
+ if (ring_ref != con->ring_ref && con->ring_ref != INVALID_XEN_PFN)
console_unmap_interface(con);
if (!con->interface && xgt_handle && con->use_gnttab) {
@@ -706,7 +706,7 @@ static int console_create_ring(struct console *con)
con->interface = xengnttab_map_grant_ref(xgt_handle,
dom->domid, GNTTAB_RESERVED_CONSOLE,
PROT_READ|PROT_WRITE);
- con->ring_ref = -1;
+ con->ring_ref = INVALID_XEN_PFN;
}
if (!con->interface) {
/* Fall back to xc_map_foreign_range */
@@ -812,7 +812,7 @@ static int console_init(struct console *con, struct domain
*dom, void **data)
con->master_pollfd_idx = -1;
con->slave_fd = -1;
con->log_fd = -1;
- con->ring_ref = -1;
+ con->ring_ref = INVALID_XEN_PFN;
con->local_port = -1;
con->remote_port = -1;
con->xce_pollfd_idx = -1;
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 308109f..fc383ca 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -37,6 +37,8 @@
#error "Unsupported architecture"
#endif
+#define INVALID_XEN_PFN (~(xen_pfn_t)0)
+
#ifndef __ASSEMBLY__
/* Guest handles for primitive C types. */
DEFINE_XEN_GUEST_HANDLE(char);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] libxl: Change the type of console_mfn to xen_pfn_t
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
tools/libxl/libxl_console.c | 2 +-
tools/libxl/libxl_dom.c | 2 +-
tools/libxl/libxl_internal.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 6bfc0e5..f2ca689 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
flexarray_append(ro_front, "port");
flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->console_port));
flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn,
state->console_mfn));
} else {
flexarray_append(front, "state");
flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ef834e6..a58e74f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -869,7 +869,7 @@ out:
static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
libxl_domain_build_info *info,
int store_evtchn, unsigned long *store_mfn,
-int console_evtchn, unsigned long *console_mfn,
+int console_evtchn, xen_pfn_t *console_mfn,
domid_t store_domid, domid_t console_domid)
{
struct hvm_info_table *va_hvm;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 45e6df6..f52aeb3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,7 +1128,7 @@ typedef struct {
uint32_t console_port;
uint32_t console_domid;
-unsigned long console_mfn;
+xen_pfn_t console_mfn;
char *console_tty;
char *saved_state;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.
This patch introduces a new format specifier "PRIu_xen_pfn" which formats the
value as a
decimal value.
Signed-off-by: Bhupinder Thakur
Acked-by: Wei Liu
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Andrew Cooper
tools/libxl/libxl_console.c | 2 +-
xen/include/public/arch-arm.h | 1 +
xen/include/public/arch-x86/xen.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index c05dc28..6bfc0e5 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
flexarray_append(ro_front, "port");
flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, state->vuart_gfn));
flexarray_append(ro_front, "limit");
flexarray_append(ro_front, GCSPRINTF("%d", LIBXL_XENCONSOLE_LIMIT));
flexarray_append(ro_front, "type");
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 5708cd2..05fd11c 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -274,6 +274,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
typedef uint64_t xen_pfn_t;
#define PRI_xen_pfn PRIx64
+#define PRIu_xen_pfn PRIu64
/* Maximum number of virtual CPUs in legacy multi-processor guests. */
/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index ff91831..3b0b1d6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -75,6 +75,7 @@ __DeFiNe__ __DECL_REG_LO16(name) e ## name
#ifndef __ASSEMBLY__
typedef unsigned long xen_pfn_t;
#define PRI_xen_pfn "lx"
+#define PRIu_xen_pfn "lu"
#endif
#define XEN_HAVE_PV_GUEST_ENTRY 1
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] xenconsole: Change the type of ring_ref to xen_pfn_t in console_create_ring
Currently, ring_ref is read as an integer in console_create_ring which could
lead to
truncation of the value as it is reading a 64-bit value.
The fix is to modify the type of ring_ref to xen_pfn_t and use the correct
format
specifier to read the value correctly for all architectures.
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
tools/console/daemon/io.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009a..1839973 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -19,6 +19,7 @@
#define _GNU_SOURCE
+#include
#include "utils.h"
#include "io.h"
#include
@@ -81,6 +82,12 @@ static unsigned int nr_fds;
#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
+#if defined(CONFIG_ARM)
+# define SCNi_xen_pfn SCNi64
+#else
+# define SCNi_xen_pfn "li"
+#endif
+
struct buffer {
char *data;
size_t consumed;
@@ -98,7 +105,7 @@ struct console {
struct buffer buffer;
char *xspath;
char *log_suffix;
- int ring_ref;
+ xen_pfn_t ring_ref;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
int event_count;
@@ -661,12 +668,13 @@ static void console_unmap_interface(struct console *con)
static int console_create_ring(struct console *con)
{
- int err, remote_port, ring_ref, rc;
+ int err, remote_port, rc;
+ xen_pfn_t ring_ref;
char *type, path[PATH_MAX];
struct domain *dom = con->d;
err = xs_gather(xs, con->xspath,
- "ring-ref", "%u", &ring_ref,
+ "ring-ref", "%"SCNi_xen_pfn, &ring_ref,
"port", "%i", &remote_port,
NULL);
@@ -705,7 +713,7 @@ static int console_create_ring(struct console *con)
con->interface = xc_map_foreign_range(
xc, dom->domid, XC_PAGE_SIZE,
PROT_READ|PROT_WRITE,
- (unsigned long)ring_ref);
+ ring_ref);
if (con->interface == NULL) {
err = EINVAL;
goto out;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] libxc: Fix the data type of mfn parameter passed to xc_map_foreign_range()
Currently the data type of mfn paramter passed to xc_map_foreign_range() is
unsigned
long. This could be problem for 32-bit arm architectures where the lengh of
long is
32 bits while mfn happens to be a 64-bit value.
To avoid truncating a 64-bit value, the type of mfn is changed from "unsigned
long" to
xen_pfn_t. Also the parameter name "mfn" is changed to "pfn" which is a more
accurate
indication of what this parameter represents.
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
tools/libxc/include/xenctrl_compat.h | 2 +-
tools/libxc/xc_foreign_memory.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl_compat.h
b/tools/libxc/include/xenctrl_compat.h
index a655e47..5ee72bf 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -26,7 +26,7 @@
*/
void *xc_map_foreign_range(xc_interface *xch, uint32_t dom,
int size, int prot,
-unsigned long mfn );
+xen_pfn_t pfn);
void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, int prot,
const xen_pfn_t *arr, int num );
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 4053d26..c1f114a 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -33,7 +33,7 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom,
int prot,
void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom, int size, int prot,
- unsigned long mfn)
+ xen_pfn_t pfn)
{
xen_pfn_t *arr;
int num;
@@ -46,7 +46,7 @@ void *xc_map_foreign_range(xc_interface *xch,
return NULL;
for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
+arr[i] = pfn + i;
ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
free(arr);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] ipxe: update to newer commit
Wei Liu writes ("Re: [Xen-devel] [PATCH] ipxe: update to newer commit"):
> Ian is away. I don't know who else has permission to generate and
> upload that tarball. :-)
I have done it now. The permission required is the ability to become
xen@xenbits.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/4] arm: tee: add OP-TEE header files
Hi, On 17/10/17 17:24, Volodymyr Babchuk wrote: On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote: Hi Volodymyr, Hi Julien, On 11/10/17 20:01, Volodymyr Babchuk wrote: This header files describe protocol between OP-TEE and OP-TEE client driver in Linux. They are needed for upcomient OP-TEE mediator, which is added in the next patch. Reason to add those headers in separate patch is to ease up review. Those files were taken from linux tree (drivers/tee/optee/) and mangled a bit to compile with XEN. Signed-off-by: Volodymyr Babchuk --- xen/arch/arm/tee/optee_msg.h | 444 + xen/arch/arm/tee/optee_smc.h | 457 +++ Headers should go in include/asm-arm/tee and not arch/arm. This headers are used only by optee.c in the same folder. Do I need to make them public? They are not going to be public, just internal to Xen. But not in arch/arm, I know we did in some occasions but I would rather keep all the headers in include/asm-arm. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework
On 17/10/17 17:22, Volodymyr Babchuk wrote:
On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote:
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..e1f112a 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,14 @@ config HAS_ITS
prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
depends on HAS_GICV3
+config ARM_TEE
The ARM in the title is a bit pointless. This Kconfig is only used for Arm
architecture.
Just plain TEE then?
Yes please.
+ bool "Enable TEE mediators support"
+ default n
+ depends on ARM
No need for that.
Right.
+ help
+ This option enables generic TEE mediators support. It allows guests
+ to access real TEE via one of TEE mediators implemented in XEN
Missing full stop.
+
endmenu
menu "ARM errata workaround via the alternative framework"
@@ -167,3 +175,5 @@ endmenu
source "common/Kconfig"
source "drivers/Kconfig"
+
+source "arch/arm/tee/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ede21fd..2710e0e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64
subdir-y += platforms
subdir-$(CONFIG_ARM_64) += efi
subdir-$(CONFIG_ACPI) += acpi
+subdir-$(CONFIG_ARM_TEE) += tee
obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
obj-y += bootfdt.init.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 784ae39..3290d39 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
goto fail;
+/* Notify TEE that new domain was created */
+tee_domain_create(d);
I am not a big fan to see this in arch_domain_create until we see how this
is going to fit with guest. For instance, will TEE be for every guests? What
would be the other necessary information to configure it?...
I think I'll call XSM in tee_domain_create() to check if this domain allowed
to work with TEE. I can't imagine what additional information will be needed.
This interface can be extended in the future, though.
You will never need to inform TEE that a new client (aka domain) is been
created, nor allocated memory for the TEE at domain creation in Xen?
[...]
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
new file mode 100644
index 000..7f7a846
--- /dev/null
+++ b/xen/arch/arm/tee/tee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/tee.c
+ *
+ * Generic part of TEE mediator subsystem
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * 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
+
+/*
+ * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner
+ * for generic TEE queries is 63.
+ */
+#define TRUSTED_OS_GENERIC_API_OWNER 63
+
+#define ARM_SMCCC_FUNC_GET_TEE_UID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_CONV_32, \
+ TRUSTED_OS_GENERIC_API_OWNER,\
+ ARM_SMCCC_FUNC_CALL_UID)
This likely needs to be defined in smccc as AFAIU it is part of the SMCCC.
It only used there. I'm not sure if I should define it globally.
Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely
TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem
definition in smccc.h.
[...]
+printk("No TEE found\n");
+return;
+}
+
+parse_uid(resp, &tee_uid);
+
+printk("TEE UID:
%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
+ tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ],
Please no space before ]. This is making more confusing to read.
I put it for neat formatting. Probably, I can put double space after commas.
Will be okay?
That is that really important to have them? I mean, ok it is not going
to be neat but the format string is already ugly and it would not be too
difficult to read the arguments.
+ tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ],
+ tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11],
+ tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]);
+
+for ( desc = _steemediator; desc != _eteemediator; desc++ )
{
+
Re: [Xen-devel] [RFC 3/4] arm: tee: add OP-TEE header files
On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >This header files describe protocol between OP-TEE and OP-TEE client > >driver in Linux. They are needed for upcomient OP-TEE mediator, which > >is added in the next patch. > >Reason to add those headers in separate patch is to ease up review. > >Those files were taken from linux tree (drivers/tee/optee/) and mangled > >a bit to compile with XEN. > > > >Signed-off-by: Volodymyr Babchuk > >--- > > xen/arch/arm/tee/optee_msg.h | 444 > > + > > xen/arch/arm/tee/optee_smc.h | 457 > > +++ > > Headers should go in include/asm-arm/tee and not arch/arm. This headers are used only by optee.c in the same folder. Do I need to make them public? WBR, Volodymyr ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework
On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, [...] > >This is how it works: user can build XEN with multiple TEE mediators > >(see the next patches, where OP-TEE mediator is introduced). > >TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the > >same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END() > >macros. > >In runtime, during initialization, XEN issues standard SMC to read > >TEE UID. Using this UID it selects and initializes one of built-in > >mediators. Then generic vSMC handler will call selected mediator > >when it intercept SMC that belongs to TEE OS or TEE application. > > As you may remember the discussion on the SMCCC support for guests, there > are currently no way to know the SMCCC is present on the platform. Ah, yes. Device tree, then. > I don't think you can rely on the platform support SMCC nor fully > implementing it. This also bring the question of does every TEE are > supporting SMCCC? Honestly, I don't know. I suppose that there can be TEEs the are not compatible with SMCCC. Okay, instead of UID comparison in generic framework, I can introduce probe() functions for each mediator. On other hand, DT bindings, can work even better. How about this: TEE mediator registers with DT_DEVICE_START() as any other driver. If, during init() it finds compatible TEE, then TEE mediator registers itself in TEE framework. During registration it provides supported SMC fn ranges. This is for case when TEE is not SMCCC-compatible and uses function numbers outside ARM_SMCCC_OWNER_TRUSTED_OS range. > > > >Also, there are hooks for domain construction and destruction, so > >TEE mediator can inform TEE about VM lifecycle. > > > >Signed-off-by: Volodymyr Babchuk > >--- > > MAINTAINERS | 5 ++ > > xen/arch/arm/Kconfig | 10 > > xen/arch/arm/Makefile | 1 + > > xen/arch/arm/domain.c | 7 +++ > > xen/arch/arm/setup.c | 4 ++ > > xen/arch/arm/tee/Kconfig | 0 > > xen/arch/arm/tee/Makefile | 1 + > > xen/arch/arm/tee/tee.c| 134 > > ++ > > xen/arch/arm/vsmc.c | 5 ++ > > xen/arch/arm/xen.lds.S| 7 +++ > > xen/include/asm-arm/tee.h | 79 +++ > > 11 files changed, 253 insertions(+) > > create mode 100644 xen/arch/arm/tee/Kconfig > > create mode 100644 xen/arch/arm/tee/Makefile > > create mode 100644 xen/arch/arm/tee/tee.c > > create mode 100644 xen/include/asm-arm/tee.h > > > >diff --git a/MAINTAINERS b/MAINTAINERS > >index 77b1e11..ede00c5 100644 > >--- a/MAINTAINERS > >+++ b/MAINTAINERS > >@@ -357,6 +357,11 @@ F: config/Stubdom.mk.in > > F: m4/stubdom.m4 > > F: stubdom/ > >+TEE MEDIATORS > >+M: Volodymyr Babchuk > >+S: Supported > >+F: xen/arch/arm/tee/* > >+ > > TOOLSTACK > > M: Ian Jackson > > M: Wei Liu > >diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > >index d46b98c..e1f112a 100644 > >--- a/xen/arch/arm/Kconfig > >+++ b/xen/arch/arm/Kconfig > >@@ -50,6 +50,14 @@ config HAS_ITS > > prompt "GICv3 ITS MSI controller support" if EXPERT = "y" > > depends on HAS_GICV3 > >+config ARM_TEE > > The ARM in the title is a bit pointless. This Kconfig is only used for Arm > architecture. Just plain TEE then? > >+bool "Enable TEE mediators support" > >+default n > >+depends on ARM > > No need for that. Right. > >+help > >+ This option enables generic TEE mediators support. It allows guests > >+ to access real TEE via one of TEE mediators implemented in XEN > > Missing full stop. > > >+ > > endmenu > > menu "ARM errata workaround via the alternative framework" > >@@ -167,3 +175,5 @@ endmenu > > source "common/Kconfig" > > source "drivers/Kconfig" > >+ > >+source "arch/arm/tee/Kconfig" > >diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > >index ede21fd..2710e0e 100644 > >--- a/xen/arch/arm/Makefile > >+++ b/xen/arch/arm/Makefile > >@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 > > subdir-y += platforms > > subdir-$(CONFIG_ARM_64) += efi > > subdir-$(CONFIG_ACPI) += acpi > >+subdir-$(CONFIG_ARM_TEE) += tee > > obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o > > obj-y += bootfdt.init.o > >diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > >index 784ae39..3290d39 100644 > >--- a/xen/arch/arm/domain.c > >+++ b/xen/arch/arm/domain.c > >@@ -31,6 +31,7 @@ > > #include > > #include > > #include > >+#include > > #include > > #include > > #include > >@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int > >domcr_flags, > > if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) > > goto fail; > >+/* Notify TEE that new domain was created */ > >+tee_domain_create(d); > > I am not a big fan to see this in arch_domain_create until we see how this > is going to fit with guest. For instance, will TEE be for every guests? What > would be the other necessary
Re: [Xen-devel] [PATCH v5 02/13] xen/pvcalls: implement frontend disconnect
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to allow waiting for a response on commands sent
> to the backend.
>
> Introduce an array of struct xen_pvcalls_response to store commands
> responses.
>
> pvcalls_refcount is used to keep count of the outstanding pvcalls users.
> Only remove connections once the refcount is zero.
>
> Implement pvcalls frontend removal function. Go through the list of
> active and passive sockets and free them all, one at a time.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/pvcalls-front.c | 67
> +
> 1 file changed, 67 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index a8d38c2..d8b7a04 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -20,6 +20,46 @@
> #include
> #include
>
> +#define PVCALLS_INVALID_ID UINT_MAX
> +#define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
> +#define PVCALLS_NR_REQ_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
> +
> +struct pvcalls_bedata {
> + struct xen_pvcalls_front_ring ring;
> + grant_ref_t ref;
> + int irq;
> +
> + struct list_head socket_mappings;
> + struct list_head socketpass_mappings;
> + spinlock_t socket_lock;
> +
> + wait_queue_head_t inflight_req;
> + struct xen_pvcalls_response rsp[PVCALLS_NR_REQ_PER_RING];
Did you mean _REQ_ or _RSP_ in the macro name?
> +};
> +/* Only one front/back connection supported. */
> +static struct xenbus_device *pvcalls_front_dev;
> +static atomic_t pvcalls_refcount;
> +
> +/* first increment refcount, then proceed */
> +#define pvcalls_enter() { \
> + atomic_inc(&pvcalls_refcount); \
> +}
> +
> +/* first complete other operations, then decrement refcount */
> +#define pvcalls_exit() {\
> + atomic_dec(&pvcalls_refcount); \
> +}
> +
> +static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
> +{
> + return IRQ_HANDLED;
> +}
> +
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map)
> +{
> +}
> +
> static const struct xenbus_device_id pvcalls_front_ids[] = {
> { "pvcalls" },
> { "" }
> @@ -27,6 +67,33 @@
>
> static int pvcalls_front_remove(struct xenbus_device *dev)
> {
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL, *n;
> +
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> + dev_set_drvdata(&dev->dev, NULL);
> + pvcalls_front_dev = NULL;
> + if (bedata->irq >= 0)
> + unbind_from_irqhandler(bedata->irq, dev);
> +
> + smp_mb();
> + while (atomic_read(&pvcalls_refcount) > 0)
> + cpu_relax();
> + list_for_each_entry_safe(map, n, &bedata->socket_mappings, list) {
> + pvcalls_front_free_map(bedata, map);
> + kfree(map);
> + }
> + list_for_each_entry_safe(map, n, &bedata->socketpass_mappings, list) {
> + spin_lock(&bedata->socket_lock);
> + list_del_init(&map->list);
> + spin_unlock(&bedata->socket_lock);
> + kfree(map);
Why do you re-init the entry if you are freeing it? And do you really
need the locks around it? This looks similar to the case we've discussed
for other patches --- if we are concerned that someone may grab this
entry then something must be wrong.
(Sorry, this must have been here in earlier versions but I only now
noticed it.)
-boris
> + }
> + if (bedata->ref >= 0)
> + gnttab_end_foreign_access(bedata->ref, 0, 0);
> + kfree(bedata->ring.sring);
> + kfree(bedata);
> + xenbus_switch_state(dev, XenbusStateClosed);
> return 0;
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator
On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > > > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >Hello all, > > Hi Volodymyr, Hi Julien > > > > >I want to present TEE mediator, that was discussed earlier ([1]). > > > >I selected design with built-in mediators. This is easiest way, > >it removes many questions, it is easy to implement and maintain > >(at least I hope so). > > Well, it may close the technical questions but still leave the security > impact unanswered. I would have appreciated a summary of each approach and > explain the pros/cons. This is the most secure way also. In terms of trust between guests and Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about "security", my first thoughts are "Can TEE OS trust to XEN as a mediator? Can TEE client trust to XEN as a mediator?". And with current approach answer is "yes, they can, especially if XEN is a part of a chain of trust". But you probably wanted to ask "Can guest compromise whole system by using TEE mediator or TEE OS?". This is an interesting question. First let's discuss requirements for a TEE mediator. So, mediator should be able to: * Receive request to handle trapped SMC. This request should include user registers + some information about guest (at least domain id). * Pin/unpin domain memory pages. * Map domain memory pages into own address space with RW access. * Issue real SMC to a TEE. * Receive information about guest creation and destruction. * (Probably) inject IRQs into a domain (this can be not a requester domain, but some other domain, that also called to TEE). This is a minimal list of requirements. I think, this should be enough to implement mediator for OP-TEE. But I can't say for sure for other TEEs. Let's consider possible approaches: 1. Mediator right in XEN, works at EL2. Pros: * Mediator can use all XEN APIs * As mediator resides in XEN, it can be checked together with XEN for a validity (trusted boot). * Mediator is initialized before Dom0. Dom0 can work with a TEE. * No extra context switches, no special ABI between XEN and mediator. Cons: * Because it lives in EL2, it can compromise whole hypervisor, if there is a security bug in mediator code. * No support for closed source TEEs. 2. Mediator in a stubdomain. Works at EL1. Pros: * Mediator is isolated from hypervisor (but it still can do potentially dangerous things like mapping domain memory or pining pages). * One can legally create and use mediator for a closed-source TEE. Cons: * Overhead in XEN<->Mediator communication. * XEN needs to be modified to boot mediator domain before Dom0. * Some extra entity required to check validity of a mediator. 3. Mediator in an EL0 app. The same pros and cons as for mediator in a stubdomain + extra code for EL0 apps, which is needed to be supported and maintained. Now, back to security questions. There are two possible attacks: attack at XEN and attack at TEE itself. If your TEE is vulnerable, then your whole system is compromised anyways. AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's TZ implementation. If your TEE mediator is vulnerable, then your hypervisor and all guests are compromised. Yes TEE mediator increases attack surface, but the same does any other XEN<->Guest interface. TEE mediators are expected to be simple and straightforward, without complex logic. So, I think that they are not more dangerous than vGIC driver or PL011 emulator. And yes, it seems obvious, but I want to say this explicitly: generic TEE mediator framework should and will use XSM to control which domain can work with TEE. So, if you don't trust your guest - don't let it to call TEE at all. This feature is not implemented in this RFC only because currently only Dom0 calls are supported. > This would help to understand that maybe it is an easy way but also still > secure... In previous discussion we considered only two variants: in XEN or outside XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. Such stubdomain will need access to all guests memory. If you managed to gain control on mediator stubdomain, you can do anything you want with all guests. > To be clear, this series don't look controversial at least for OP-TEE. What > I am more concerned is about DomU supports. Your concern is that rogue DomU can compromise whole system, right? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/26] tools: libxendevicemodel: Provide xendevicemodel_shutdown
Ross Lagerwall writes ("Re: [PATCH 03/26] tools: libxendevicemodel: Provide
xendevicemodel_shutdown"):
> On 10/09/2017 04:57 PM, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
> > Acked-by: Wei Liu
...
> Why did all the symbols get moved to VERS_1.1 rather than adding only
> the new one to VERS_1.1 and keeping the rest at VERS_1.0 (like has been
> done with libxenforeignmemory)?
I think that was a mistake. We should undo it.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > Maybe we can add a new field to the alternatives entry struct which > specifies the offset to the CALL instruction, so apply_alternatives() > can find it. We'd also have to assume that the restore part of an alternative entry is the same size as the save part. Which is true now. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/4] x86/pvclock: add setter for pvclock_pvti_cpu0_va
On 10/03/2017 12:55 PM, Joao Martins wrote:
> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> on kvmclock since:
>
> commit dac16fba6fc5
> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>
> The only user of this interface so far is kvm. This commit adds a
> setter function for the pvti page and moves pvclock_pvti_cpu0_va
> to pvclock, which is a more generic place to have it; and would
> allow other PV clocksources to use it, such as Xen.
>
> Signed-off-by: Joao Martins
> Acked-by: Andy Lutomirski
Ping?
While the rest of series has been acked, I think that this patch (per
maintainers file) still misses x86 and (or?) kvm ack/review.
Joao
> ---
> Changes since v1:
> * Rebased: the only conflict was that I had move the export
> pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
> * Do not initialize pvti_cpu0_va to NULL (checkpatch error)
> ( Comments from Andy Lutomirski )
> * Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
> for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
> * Add his Acked-by (provided the previous adjustment was made)
>
> Changes since RFC:
> (Comments from Andy Lutomirski)
> * Add __init to pvclock_set_pvti_cpu0_va
> * Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
> pvclock_set_pvti_cpu0_va
> ---
> arch/x86/include/asm/pvclock.h | 19 ++-
> arch/x86/kernel/kvmclock.c | 7 +--
> arch/x86/kernel/pvclock.c | 14 ++
> 3 files changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
> index 448cfe1b48cf..6f228f90cdd7 100644
> --- a/arch/x86/include/asm/pvclock.h
> +++ b/arch/x86/include/asm/pvclock.h
> @@ -4,15 +4,6 @@
> #include
> #include
>
> -#ifdef CONFIG_KVM_GUEST
> -extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
> -#else
> -static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> -{
> - return NULL;
> -}
> -#endif
> -
> /* some helper functions for xen and kvm pv clock sources */
> u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
> u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
> @@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
>
> #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
>
> +#ifdef CONFIG_PARAVIRT_CLOCK
> +void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
> +struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
> +#else
> +static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> +{
> + return NULL;
> +}
> +#endif
> +
> #endif /* _ASM_X86_PVCLOCK_H */
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index d88967659098..538738047ff5 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
> static struct pvclock_vsyscall_time_info *hv_clock;
> static struct pvclock_wall_clock wall_clock;
>
> -struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> -{
> - return hv_clock;
> -}
> -EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
> -
> /*
> * The wallclock is the time of day when we booted. Since then, some time may
> * have elapsed since the hypervisor wrote the data. So we try to account for
> @@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
> return 1;
> }
>
> + pvclock_set_pvti_cpu0_va(hv_clock);
> put_cpu();
>
> kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
> index 5c3f6d6a5078..cb7d6d9c9c2d 100644
> --- a/arch/x86/kernel/pvclock.c
> +++ b/arch/x86/kernel/pvclock.c
> @@ -25,8 +25,10 @@
>
> #include
> #include
> +#include
>
> static u8 valid_flags __read_mostly = 0;
> +static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
>
> void pvclock_set_flags(u8 flags)
> {
> @@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
> *wall_clock,
>
> set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
> }
> +
> +void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
> +{
> + WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
> + pvti_cpu0_va = pvti;
> +}
> +
> +struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> +{
> + return pvti_cpu0_va;
> +}
> +EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/26] tools: libxendevicemodel: Provide xendevicemodel_shutdown
On 10/09/2017 04:57 PM, Ian Jackson wrote:
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: Bump library minor version, as this is a new function
---
snip
diff --git a/tools/libs/devicemodel/libxendevicemodel.map
b/tools/libs/devicemodel/libxendevicemodel.map
index 130222c..b0765fa 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -1,4 +1,4 @@
-VERS_1.0 {
+VERS_1.1 {
global:
xendevicemodel_open;
xendevicemodel_create_ioreq_server;
@@ -18,6 +18,7 @@ VERS_1.0 {
xendevicemodel_modified_memory;
xendevicemodel_set_mem_type;
xendevicemodel_inject_event;
+ xendevicemodel_shutdown;
xendevicemodel_restrict;
xendevicemodel_close;
local: *; /* Do not expose anything by default */
Why did all the symbols get moved to VERS_1.1 rather than adding only
the new one to VERS_1.1 and keeping the rest at VERS_1.0 (like has been
done with libxenforeignmemory)?
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers
Rather than opencoding it in two places. While only used in the PV emulation
code, this helper is in principle usable anywhere in the hypervisor.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/pv/emul-gate-op.c | 5 +
xen/arch/x86/pv/emulate.c | 6 +-
xen/arch/x86/pv/emulate.h | 11 +++
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/pv/emul-gate-op.c b/xen/arch/x86/pv/emul-gate-op.c
index 0f89c91..14ce95e 100644
--- a/xen/arch/x86/pv/emul-gate-op.c
+++ b/xen/arch/x86/pv/emul-gate-op.c
@@ -54,11 +54,8 @@ static int read_gate_descriptor(unsigned int gate_sel,
unsigned int *ar)
{
struct desc_struct desc;
-const struct desc_struct *pdesc;
+const struct desc_struct *pdesc = gdt_ldt_desc_ptr(gate_sel);
-pdesc = (const struct desc_struct *)
-(!(gate_sel & 4) ? GDT_VIRT_START(v) : LDT_VIRT_START(v))
-+ (gate_sel >> 3);
if ( (gate_sel < 4) ||
((gate_sel >= FIRST_RESERVED_GDT_BYTE) && !(gate_sel & 4)) ||
__get_user(desc, pdesc) )
diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index 5750c76..1b60911 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -33,11 +33,7 @@ int pv_emul_read_descriptor(unsigned int sel, const struct
vcpu *v,
if ( sel < 4)
desc.b = desc.a = 0;
-else if ( __get_user(desc,
- (const struct desc_struct *)(!(sel & 4)
- ? GDT_VIRT_START(v)
- : LDT_VIRT_START(v))
- + (sel >> 3)) )
+else if ( __get_user(desc, gdt_ldt_desc_ptr(sel)) )
return 0;
if ( !insn_fetch )
desc.b &= ~_SEGMENT_L;
diff --git a/xen/arch/x86/pv/emulate.h b/xen/arch/x86/pv/emulate.h
index 656c12f..9d58794 100644
--- a/xen/arch/x86/pv/emulate.h
+++ b/xen/arch/x86/pv/emulate.h
@@ -1,6 +1,7 @@
#ifndef __PV_EMULATE_H__
#define __PV_EMULATE_H__
+#include
#include
int pv_emul_read_descriptor(unsigned int sel, const struct vcpu *v,
@@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct
x86_emulate_state *state,
: X86EMUL_UNHANDLEABLE;
}
+/* Return a pointer to the GDT/LDT descriptor referenced by sel. */
+static inline const struct desc_struct *gdt_ldt_desc_ptr(unsigned int sel)
+{
+const struct vcpu *curr = current;
+const struct desc_struct *tbl = (void *)
+((sel & X86_XEC_TI) ? LDT_VIRT_START(curr) : GDT_VIRT_START(curr));
+
+return &tbl[sel >> 3];
+}
+
#endif /* __PV_EMULATE_H__ */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output
On Tue, Oct 17, 2017 at 03:03:02PM +0100, Russell King - ARM Linux wrote: > On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote: > > arch/arm/kernel/debug.S: > > > > ENTRY(printascii) > > addruart_current r3, r1, r2 > > b 2f > > 1: waituart r2, r3 > > senduart r1, r3 > > busyuart r2, r3 > > teq r1, #'\n' > > moveq r1, #'\r' > > beq 1b > > 2: teq r0, #0 > > ldrneb r1, [r0], #1 > > teqne r1, #0 > > bne 1b > > ret lr > > ENDPROC(printascii) > > > > ENTRY(printch) > > addruart_current r3, r1, r2 > > mov r1, r0 > > mov r0, #0 > > b 1b > > ENDPROC(printch) > > > > > > > > Russell, do you know why we wait for the UART transmitter to go > > completely idle before queueing a new char? > > It's the only way the /debug/ (and I stress /debug/) functions know > that the character has actually been sent before allowing control to > continue. This is important for early-crashy-debug situations, but > probably less so for early_printk. > > > For an individual printch this can makes sense, but it also introduces > > delay for every char in printascii. > > > > This seems to interact interestingly with virtualised UARTs, because we > > may thrash between the guest and hypervisor per-char, though there > > may be a way to reduce the impact of this on the emulation side. > > Well, I guess re-using the early /debugging/ code for early printk is > showing more and more issues - and reusing this code in this way is > something that I've never really been a fan of. > > I'd personally like to see the coupling between the two things gone - > I never really wanted that coupling in the first place. Agreed. I'll propose a patch for the amba-pl011 earlycon code so that the flush is only per each write() call, which should at least mitigate the impact. For low-level debug, it makes more sense to be as conservative as possible though: I don't see a need to change arm printch/printascii: as you point out, these two bits of code have different purposes, even if they have common ancestry. Cheers ---Dave IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
On 10/17/2017 09:24 AM, Paul Durrant wrote: Certain memory resources associated with a guest are not necessarily present in the guest P2M. This patch adds the boilerplate for new memory op to allow such a resource to be priv-mapped directly, by either a PV or HVM tools domain. NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture, I have no means to test it on an ARM platform and so cannot verify that it functions correctly. Signed-off-by: Paul Durrant Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On Tue, Oct 17, 2017 at 09:58:59AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 01:24 AM, Josh Poimboeuf wrote: > > On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote: > >> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > >>> On 10/12/2017 03:27 PM, Andrew Cooper wrote: > On 12/10/17 20:11, Boris Ostrovsky wrote: > > There is also another problem: > > > > [1.312425] general protection fault: [#1] SMP > > [1.312901] Modules linked in: > > [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 > > [1.313878] task: 88003e2c task.stack: c938c000 > > [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5 > > [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046 > > [1.315336] RAX: 000c RBX: 55f550168040 RCX: > > 7fcfc959f59a > > [1.315827] RDX: RSI: RDI: > > > > [1.316315] RBP: 000a R08: 037f R09: > > 0064 > > [1.316805] R10: 1f89cbf5 R11: 88003e2c R12: > > 7fcfc958ad60 > > [1.317300] R13: R14: 55f550185954 R15: > > 1000 > > [1.317801] FS: () GS:88003f80() > > knlGS: > > [1.318267] CS: e033 DS: ES: CR0: 80050033 > > [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4: > > 00042660 > > [1.319235] Call Trace: > > [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 > > 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 > > 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 > > [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: > > c938ff50 > > [1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- > > [1.345009] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x000b > > > > > > All code > > > >0:51 push %rcx > >1:50 push %rax > >2:57 push %rdi > >3:56 push %rsi > >4:52 push %rdx > >5:51 push %rcx > >6:6a dapushq $0xffda > >8:41 50push %r8 > >a:41 51push %r9 > >c:41 52push %r10 > >e:41 53push %r11 > > 10:48 83 ec 30 sub$0x30,%rsp > > 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11 > > 1b:00 00 > > 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11) > > 24:0f 85 a5 00 00 00jne0xcf > > 2a:50 push %rax > > 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)# > > 0xffd095cd<-- trapping instruction > > 31:58 pop%rax > > 32:48 3d 4c 01 00 00cmp$0x14c,%rax > > 38:77 0fja 0x49 > > 3a:4c 89 d1 mov%r10,%rcx > > 3d:ff .byte 0xff > > 3e:14 c5adc$0xc5,%al > > > > > > so the original 'cli' was replaced with the pv call but to me the offset > > looks a bit off, no? Shouldn't it always be positive? > callq takes a 32bit signed displacement, so jumping back by up to 2G is > perfectly legitimate. > >>> Yes, but > >>> > >>> ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > >>> 817365dd t entry_SYSCALL_64_fastpath > >>> ostr@workbase> nm vmlinux | grep " pv_irq_ops" > >>> 81c2dbc0 D pv_irq_ops > >>> ostr@workbase> > >>> > >>> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I > >>> didn't mean that x86 instruction set doesn't allow negative > >>> displacement, I was trying to say that pv_irq_ops always live further > >>> down) > >> I believe the problem is this: > >> > >> #define PV_INDIRECT(addr) *addr(%rip) > >> > >> The displacement that the linker computes will be relative to the where > >> this instruction is placed at the time of linking, which is in > >> .pv_altinstructions (and not .text). So when we copy it into .text the > >> displacement becomes bogus. > > apply_alternatives() is supposed to adjust that displacement based on > > the new IP, though it could be messing that up somehow. (See patch > > 10/13.) > > > > That patch doesn't take into account the fact that replacement > instructions may have to save/restore registers. So, for example, > > > -if (a->replacementlen && is_jmp(replacement[0])) > +} e
Re: [Xen-devel] Build issues since XSA 240
On Tue, 17 Oct 2017 06:57:45 -0600 "Jan Beulich" wrote: > >>> On 17.10.17 at 14:44, wrote: > > We are seeing some build issues since XSA 240 was released, since I > > didn't know if it was related to our build job I've isolated everything > > so anybody could recreate the test. > > We use Xen 4.8.2 and build it on debian 9 (9.1 to be exact) and since > > XSA 240 we have xen crashing on some servers (mostly dev machine so > > it's ok but still ...). > > As said to be sure that everyone can recreate the problem I've created > > a script that ~do what our jenkins job is doing : > > https://gist.github.com/evadot/40f92fb5320121fd8ee3b6d0d9c256c1 > > I've set the bits for reproducible build since it makes it easier to > > test on multiple machines. > > With this script runned on a debian 9.1 machine (either vm or > > physical) from /root/ directly (I didn't found the variable that remove > > build path for repro build if one exists) I get the build id > > 0764c6f6d385feed46c4b18803dabc282a50ae8b and when starting this binary > > on a Dell C6100 (Xeon L5640) I have this : > > https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_gcc-0764c6f6d > > > > 385feed46c4b18803dabc282a50ae8b.txt > > > > If I switch to clang (just added clang=y to make defconfig and make > > build) I have this : > > https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_clang-2261d6a > > > > d42adef475fa638b87f7364df155919a9.txt > > There seems to be some memory corruption on this last one (where the > > ram map is printed). > > > > But if I build it on my FreeBSD machine (12-CURRENT, clang 5.0.0) or a > > FreeBSD 11.1 VM (clang 4.0.0) I can boot my dom0 and start VMs. > > Wasn't it you who (under email address emmanuel.va...@gandi.net) > reported this same or a pretty similar problem to the discussion list > already during the embargo, finding out later that this was due to > flawed hardware on the build system of yours? > > Jan Yes, since then I've run test on multiple VM and physical machines to be sure that this wasn't our build system fault. -- Emmanuel Vadot ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/public: Correct the definition of GNTTAB_CACHE_SOURCE_GREF
On Tue, Oct 17, 2017 at 03:11:51PM +0100, Andrew Cooper wrote: > Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor. > > (d79) XSA-232 PoC > (XEN) > > (XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25 > (XEN) left shift of 1 by 31 places cannot be represented in type 'int' > (XEN) [ Xen-4.10.0-rc x86_64 debug=y Tainted:H ] > > Update all of the GNTTAB_CACHE_* constants to be unsigned integers. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/public: Correct the definition of GNTTAB_CACHE_SOURCE_GREF
Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
(d79) XSA-232 PoC
(XEN)
(XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25
(XEN) left shift of 1 by 31 places cannot be represented in type 'int'
(XEN) [ Xen-4.10.0-rc x86_64 debug=y Tainted:H ]
Update all of the GNTTAB_CACHE_* constants to be unsigned integers.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
This is a trivial bugfix, and is low risk for 4.10
---
xen/include/public/grant_table.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 018036e..180d62c 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -589,9 +589,9 @@ struct gnttab_cache_flush {
} a;
uint16_t offset; /* offset from start of grant */
uint16_t length; /* size within the grant */
-#define GNTTAB_CACHE_CLEAN (1<<0)
-#define GNTTAB_CACHE_INVAL (1<<1)
-#define GNTTAB_CACHE_SOURCE_GREF(1<<31)
+#define GNTTAB_CACHE_CLEAN (1u<<0)
+#define GNTTAB_CACHE_INVAL (1u<<1)
+#define GNTTAB_CACHE_SOURCE_GREF(1u<<31)
uint32_t op;
};
typedef struct gnttab_cache_flush gnttab_cache_flush_t;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/17/2017 09:10 AM, Brian Gerst wrote: > On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky > wrote: >> >> Replacing the macro with >> >> #define PV_INDIRECT(addr) *addr // well, it's not so much >> indirect anymore >> >> makes things work. Or maybe it can be adjusted top be kept truly indirect. > That is still an indirect call, just using absolute addressing for the > pointer instead of RIP-relative. Oh, right, I've got my terminology all wrong. -boris > Alternatives has very limited > relocation capabilities. It will only handle a single call or jmp > replacement. Using absolute addressing is slightly less efficient > (takes one extra byte to encode, and needs a relocation for KASLR), > but it works just as well. You could also relocate the instruction > manually by adding the delta between the original and replacement code > to the displacement. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output
On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote: > arch/arm/kernel/debug.S: > > ENTRY(printascii) > addruart_current r3, r1, r2 > b 2f > 1: waituart r2, r3 > senduart r1, r3 > busyuart r2, r3 > teq r1, #'\n' > moveq r1, #'\r' > beq 1b > 2: teq r0, #0 > ldrneb r1, [r0], #1 > teqne r1, #0 > bne 1b > ret lr > ENDPROC(printascii) > > ENTRY(printch) > addruart_current r3, r1, r2 > mov r1, r0 > mov r0, #0 > b 1b > ENDPROC(printch) > > > > Russell, do you know why we wait for the UART transmitter to go > completely idle before queueing a new char? It's the only way the /debug/ (and I stress /debug/) functions know that the character has actually been sent before allowing control to continue. This is important for early-crashy-debug situations, but probably less so for early_printk. > For an individual printch this can makes sense, but it also introduces > delay for every char in printascii. > > This seems to interact interestingly with virtualised UARTs, because we > may thrash between the guest and hypervisor per-char, though there > may be a way to reduce the impact of this on the emulation side. Well, I guess re-using the early /debugging/ code for early printk is showing more and more issues - and reusing this code in this way is something that I've never really been a fan of. I'd personally like to see the coupling between the two things gone - I never really wanted that coupling in the first place. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/17/2017 01:24 AM, Josh Poimboeuf wrote:
> On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
>> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
>>> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
On 12/10/17 20:11, Boris Ostrovsky wrote:
> There is also another problem:
>
> [1.312425] general protection fault: [#1] SMP
> [1.312901] Modules linked in:
> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
> [1.313878] task: 88003e2c task.stack: c938c000
> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
> [1.315336] RAX: 000c RBX: 55f550168040 RCX:
> 7fcfc959f59a
> [1.315827] RDX: RSI: RDI:
>
> [1.316315] RBP: 000a R08: 037f R09:
> 0064
> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
> 7fcfc958ad60
> [1.317300] R13: R14: 55f550185954 R15:
> 1000
> [1.317801] FS: () GS:88003f80()
> knlGS:
> [1.318267] CS: e033 DS: ES: CR0: 80050033
> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
> 00042660
> [1.319235] Call Trace:
> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
> 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP:
> c938ff50
> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
> [1.345009] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
>
>
> All code
>
>0:51 push %rcx
>1:50 push %rax
>2:57 push %rdi
>3:56 push %rsi
>4:52 push %rdx
>5:51 push %rcx
>6:6a dapushq $0xffda
>8:41 50push %r8
>a:41 51push %r9
>c:41 52push %r10
>e:41 53push %r11
> 10:48 83 ec 30 sub$0x30,%rsp
> 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
> 1b:00 00
> 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11)
> 24:0f 85 a5 00 00 00jne0xcf
> 2a:50 push %rax
> 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)#
> 0xffd095cd<-- trapping instruction
> 31:58 pop%rax
> 32:48 3d 4c 01 00 00cmp$0x14c,%rax
> 38:77 0fja 0x49
> 3a:4c 89 d1 mov%r10,%rcx
> 3d:ff .byte 0xff
> 3e:14 c5adc$0xc5,%al
>
>
> so the original 'cli' was replaced with the pv call but to me the offset
> looks a bit off, no? Shouldn't it always be positive?
callq takes a 32bit signed displacement, so jumping back by up to 2G is
perfectly legitimate.
>>> Yes, but
>>>
>>> ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath
>>> 817365dd t entry_SYSCALL_64_fastpath
>>> ostr@workbase> nm vmlinux | grep " pv_irq_ops"
>>> 81c2dbc0 D pv_irq_ops
>>> ostr@workbase>
>>>
>>> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I
>>> didn't mean that x86 instruction set doesn't allow negative
>>> displacement, I was trying to say that pv_irq_ops always live further down)
>> I believe the problem is this:
>>
>> #define PV_INDIRECT(addr) *addr(%rip)
>>
>> The displacement that the linker computes will be relative to the where
>> this instruction is placed at the time of linking, which is in
>> .pv_altinstructions (and not .text). So when we copy it into .text the
>> displacement becomes bogus.
> apply_alternatives() is supposed to adjust that displacement based on
> the new IP, though it could be messing that up somehow. (See patch
> 10/13.)
>
That patch doesn't take into account the fact that replacement
instructions may have to save/restore registers. So, for example,
-if (a->replacementlen && is_jmp(replacement[0]))
+} else if (a->replacementlen == 6 && *insnbuf == 0xff &&
+ *(insnbuf+1) == 0x15) {
+/* indirect call */
+*(s32 *)(insnbuf + 2) += replacement - instr;
+DPRINTK("Fix indirect CALL offset: 0x%x, CALL *0x%lx",
+*(s32
Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output
On Tue, Oct 17, 2017 at 07:53:36AM -0500, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 6:19 AM, Dave Martin wrote:
> > On Tue, Oct 17, 2017 at 10:51:07AM +0100, Andre Przywara wrote:
> >> Hi Bhupinder,
> >>
> >> first thing: As the bulk of the series has been merged now, please
> >> restart your patch and version numbering, so a (potential) next post
> >> should be prefixed [PATCH v3 1/2]. And please have a cover letter giving
> >> a brief overview what this series fixes.
> >>
> >> On 13/10/17 11:40, Bhupinder Thakur wrote:
> >> > The early console output uses pl011_early_write() to write data. This
> >> > function waits for BUSY bit to get cleared before writing the next byte.
> >>
> >> ... which is questionable given the actual definition of the BUSY bit in
> >> the PL011 TRM:
> >>
> >>
> >> The BUSY signal goes HIGH as soon as data is written to the
> >> transmit FIFO (that is, the FIFO is non-empty) and remains asserted
> >> HIGH while data is being transmitted. BUSY is negated only when the
> >> transmit FIFO is empty, and the last character has been transmitted from
> >> the shift register,
> >>
> >>
> >> (I take it you are talking about the Linux driver in a guest here).
> >> I think the early_write routine tries to (deliberately?) ignore the
> >> FIFO, possibly to make sure characters really get pushed out before a
> >> system crashes, maybe.
> >>
> >> >
> >> > In the SBSA UART emulation logic, the BUSY bit was set as soon one
> >> > byte was written in the FIFO and it remained set until the FIFO was
> >> > emptied.
> >>
> >> Which is correct behaviour, as this matches the PL011 TRM as quoted above.
> >>
> >> > This meant that the output was delayed as each character needed
> >> > the BUSY to get cleared.
> >>
> >> But this is true as well!
> >>
> >> > Since the SBSA UART is getting emulated in Xen using ring buffers, it
> >> > ensures that once the data is enqueued in the FIFO, it will be received
> >> > by xenconsole so it is safe to set the BUSY bit only when FIFO becomes
> >> > full. This will ensure that pl011_early_write() is not delayed unduly
> >> > to write the data.
> >>
> >> So I can confirm that this patch fixes the very slow earlycon output
> >> observed with the current staging HEAD.
> >>
> >> So while this is somewhat deviating from the spec, I can see the benefit
> >> for an emulation scenario. I believe that emulations in general might
> >> choose implementing things a bit differently, to cope with the
> >> fundamental differences in their environment, like the virtually endless
> >> "FIFO" and the lack of any timing restrictions on the emulated "wire".
> >>
> >> So unless someone comes up with a better solution, I would support
> >> taking this patch, as this fixes a real problem.
> >
> > I think you get away with this, but it does violate the spec in order
> > to work around a feature of a correctly implemented driver.
> >
> > Software can now see this, for example:
> >
> > uart_write(ch, UARTDR);
> > busy = uart_read(UARTFR) & UARTFR_BUSY;
> > BUG_ON(!(uart_read(UARTFR) & UARTFR_TXFE) && !busy);
> >
> > which violates the spec, though I can't currently think of a good reason
> > for software to rely on that.
> >
> >
> > [+Rob, who wrote the original earlycon code in the amba-pl011 driver:
> > 0d3c673e7881 ("tty/serial: pl011: add generic earlycon support")
> >
> > Is there any actualy reason why we poll for !BUSY after each char in
> > pl011_putc()? pl011_putc() is not exposed at all: it's only called by
> > pl011_console_write().
> >
> > This will result in stuttering output even on hardware, though this
> > doesn't typically matter.
> >
> > I think if the poll for !BUSY were moved to the end of
> > pl011_console_write(), the effect would be much less bad.]
>
> I just copied the code from the arm64 earlyprintk code... Maybe it was
> because on simulation (which was the main platform at the time) folks
> wanted the character "on the wire". It seems to be that you could just
> drop it.
Hmmm, the arm64 earlyprintk code
2475ff9d2c6e ("arm64: Add simple earlyprintk support")
looks to have been derived by Catalin from arm's assembly printch/
printascii implementation, which predates git AFACT:
(Catalin, pleaes put me right if I misunderstood the history.)
arch/arm/kernel/debug.S:
ENTRY(printascii)
addruart_current r3, r1, r2
b 2f
1: waituart r2, r3
senduart r1, r3
busyuart r2, r3
teq r1, #'\n'
moveq r1, #'\r'
beq 1b
2: teq r0, #0
ldrneb r1, [r0], #1
teqne r1, #0
bne 1b
ret lr
ENDPROC(printascii)
ENTRY(printch)
addruart_current r3, r1, r2
mov r1, r0
mov r0, #0
b 1b
ENDPROC(printch)
Russell, do you k
Re: [Xen-devel] [PATCH for-4.10] fuzz/x86_emulate: Fix afl-harness batch mode file pointer leak
Hi George, On 13/10/17 10:00, George Dunlap wrote: Changeset introduced "batch mode" to afl-harness, which allowed the handling of several inputs in sequence. Unfortunately, it introduced a file pointer leak when the file was larger than the maximum size. Restructure the code to always close fp if we opened it. Signed-off-by: George Dunlap --- Release exception justification: - This is a bug fix. The problem is relatively minor, but the fix is relatively minor too. I agree here: Release-acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] mm/shadow: fix declaration of fetch_type_names
At 11:23 +0100 on 17 Oct (1508239433), Roger Pau Monne wrote: > fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in > SHADOW_DEBUG, fix the declaration so it's also guarded by > SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP. > > Signed-off-by: Roger Pau Monné Acked-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/2] tools/libs/evtchn: Add support for restricting a handle
Hi,
On 16/10/17 13:16, Ross Lagerwall wrote:
On 10/16/2017 12:29 PM, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH v1 1/2] tools/libs/evtchn: Add
support for restricting a handle"):
No. As far as I can see, it can only be used to bind new interdomain
events, not other events.
OK, good, thanks.
This entire file (including the description) is copied directly from
Linux's include/uapi/xen/evtchn.h so the description shouldn't be
changed here anyway.
Acked-by: Ian Jackson
Not sure if you are targeting this at 4.9. If you are you should have
CC'd the RM - doing that now. From an upstream pov these changes
would make some difference to qemu depriv, improving it somewhat, and
they seem very low risk.
I wasn't targeting them at 4.10 since it bumps the version number of
libxenevtchn and I thought it would be too late to submit a v1 of a
patch which does that _after_ code freeze. I do agree that the change
would be low risk.
Release-acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v12 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.
NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
actually unnecessary, as the grant table has already been seeded
by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
Signed-off-by: Paul Durrant
Acked-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v10:
- Use new id constant for grant table.
v4:
- Minor cosmetic fix suggested by Roger.
v3:
- Introduced xc_dom_set_gnttab_entry() to avoid duplicated code.
---
tools/libxc/include/xc_dom.h| 8 +--
tools/libxc/xc_dom_boot.c | 114 +---
tools/libxc/xc_sr_restore_x86_hvm.c | 10 ++--
tools/libxc/xc_sr_restore_x86_pv.c | 2 +-
tools/libxl/libxl_dom.c | 1 -
tools/python/xen/lowlevel/xc/xc.c | 6 +-
6 files changed, 92 insertions(+), 49 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6e06ef1dec..4216d63462 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -325,12 +325,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom,
xen_pfn_t pfn,
int xc_dom_boot_image(struct xc_dom_image *dom);
int xc_dom_compat_check(struct xc_dom_image *dom);
int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
- xen_pfn_t console_gmfn,
- xen_pfn_t xenstore_gmfn,
- domid_t console_domid,
- domid_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+ bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 8a376d097c..0fe94aa255 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -282,11 +282,29 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch,
domid_t domid)
return gmfn;
}
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
- xen_pfn_t console_gmfn,
- xen_pfn_t xenstore_gmfn,
- domid_t console_domid,
- domid_t xenstore_domid)
+static void xc_dom_set_gnttab_entry(xc_interface *xch,
+grant_entry_v1_t *gnttab,
+unsigned int idx,
+domid_t guest_domid,
+domid_t backend_domid,
+xen_pfn_t backend_gmfn)
+{
+if ( guest_domid == backend_domid || backend_gmfn == -1)
+return;
+
+xc_dom_printf(xch, "%s: [%u] -> 0x%"PRI_xen_pfn,
+ __FUNCTION__, idx, backend_gmfn);
+
+gnttab[idx].flags = GTF_permit_access;
+gnttab[idx].domid = backend_domid;
+gnttab[idx].frame = backend_gmfn;
+}
+
+static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
+ xen_pfn_t console_gmfn,
+ xen_pfn_t xenstore_gmfn,
+ domid_t console_domid,
+ domid_t xenstore_domid)
{
xen_pfn_t gnttab_gmfn;
@@ -310,18 +328,10 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
return -1;
}
-if ( domid != console_domid && console_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
-gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
-}
-if ( domid != xenstore_domid && xenstore_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
-gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
-}
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_CONSOLE,
+domid, console_domid, console_gmfn);
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_XENSTORE,
+domid, xenstore_domid, xenstore_gmfn);
if ( munmap(gnttab, PAGE_SIZE) == -1 )
{
@@ -339,11 +349,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
return 0;
}
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
- xen_pfn_t console_gpfn,
- xen_pfn_t xenstore_gpfn,
-
[Xen-devel] [PATCH v12 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v12:
- Dropped limit checks as requested by Jan.
v10:
- Addressed comments from Jan.
v8:
- The functionality was originally incorporated into the earlier patch
"x86/mm: add HYPERVISOR_memory_op to acquire guest resources".
---
xen/common/grant_table.c | 49 ++-
xen/common/memory.c | 45 ++-
xen/include/public/memory.h | 6 ++
xen/include/xen/grant_table.h | 4
4 files changed, 98 insertions(+), 6 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 6d20b17739..886579a7b0 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3756,13 +3756,12 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt,
grant_ref_t ref,
}
#endif
-int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
- mfn_t *mfn)
+/* Caller must hold write lock as version may change and table may grow */
+static int gnttab_get_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
{
-int rc = 0;
struct grant_table *gt = d->grant_table;
-
-grant_write_lock(gt);
+int rc = 0;
if ( gt->gt_version == 0 )
gt->gt_version = 1;
@@ -3787,6 +3786,18 @@ int gnttab_map_frame(struct domain *d, unsigned long
idx, gfn_t gfn,
rc = -EINVAL;
}
+return rc;
+}
+
+int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
+ mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+grant_write_lock(gt);
+
+rc = gnttab_get_frame(d, idx, mfn);
if ( !rc )
gnttab_set_frame_gfn(gt, idx, gfn);
@@ -3795,6 +3806,34 @@ int gnttab_map_frame(struct domain *d, unsigned long
idx, gfn_t gfn,
return rc;
}
+int gnttab_get_grant_frame(struct domain *d, unsigned long idx,
+ mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+rc = gnttab_get_frame(d, idx, mfn);
+grant_write_unlock(gt);
+
+return rc;
+}
+
+int gnttab_get_status_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+rc = gnttab_get_frame(d, idx | XENMAPIDX_grant_table_status, mfn);
+grant_write_unlock(gt);
+
+return rc;
+}
+
static void gnttab_usage_print(struct domain *rd)
{
int first = 1;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b27a71c4f1..ae46d95885 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -965,12 +966,49 @@ static long xatp_permission_check(struct domain *d,
unsigned int space)
return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
}
+static int acquire_grant_table(struct domain *d, unsigned int id,
+ unsigned long frame,
+ unsigned int nr_frames,
+ unsigned long mfn_list[])
+{
+unsigned int i = nr_frames;
+
+/* Iterate backwards in case table needs to grow */
+while ( i-- != 0 )
+{
+mfn_t mfn = INVALID_MFN;
+int rc;
+
+switch ( id )
+{
+case XENMEM_resource_grant_table_id_grant:
+rc = gnttab_get_grant_frame(d, frame + i, &mfn);
+break;
+
+case XENMEM_resource_grant_table_id_status:
+rc = gnttab_get_status_frame(d, frame + i, &mfn);
+break;
+
+default:
+rc = -EINVAL;
+break;
+}
+
+if ( rc )
+return rc;
+
+mfn_list[i] = mfn_x(mfn);
+}
+
+return 0;
+}
+
static int acquire_resource(
XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg)
{
struct domain *d, *currd = current->domain;
xen_mem_acquire_resource_t xmar;
-unsigned long mfn_list[2];
+unsigned long mfn_list[32];
int rc;
if ( copy_from_guest(&xmar, arg, 1) )
@@ -1016,6 +1054,11 @@ static int acquire_resource(
xmar.nr_frames, mfn_list);
break;
+case XENMEM_resource_grant_table:
+rc = acquire_grant_table(d, xmar.id, xmar.frame, xmar.nr_frames,
+ mfn_list);
+break;
+
default:
rc = -EOPNOTSUPP;
break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
i
[Xen-devel] [qemu-mainline test] 114645: regressions - FAIL
flight 114645 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/114645/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 114507 build-amd64 6 xen-buildfail REGR. vs. 114507 build-amd64-xsm 6 xen-buildfail REGR. vs. 114507 build-i386-xsm6 xen-buildfail REGR. vs. 114507 build-armhf-xsm 6 xen-buildfail REGR. vs. 114507 build-armhf 6 xen-buildfail REGR. vs. 114507 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 b
[Xen-devel] [PATCH v12 02/11] x86/hvm/ioreq: simplify code and use consistent naming
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
to determine whether they need to act. This means can be safely called
for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
to mirror the existing hvm_ioreq_server_unmap_pages().
All of this significantly shortens the code.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
v3:
- Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes.
- Minor updates in response to review comments from Roger.
---
xen/arch/x86/hvm/ioreq.c | 182 ++-
1 file changed, 69 insertions(+), 113 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e6ccc7572a..6d81018369 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,63 +210,75 @@ bool handle_hvm_io_completion(struct vcpu *v)
return true;
}
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
{
+struct domain *d = s->domain;
unsigned int i;
-int rc;
-rc = -ENOMEM;
+ASSERT(!IS_DEFAULT(s));
+
for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
{
if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) )
-{
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
-}
+return d->arch.hvm_domain.ioreq_gfn.base + i;
}
-return rc;
+return gfn_x(INVALID_GFN);
}
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+ unsigned long gfn)
{
+struct domain *d = s->domain;
unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!IS_DEFAULT(s));
+ASSERT(gfn != gfn_x(INVALID_GFN));
+
+set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
}
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
{
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
destroy_ring_for_helper(&iorp->va, iorp->page);
+iorp->page = NULL;
+
+if ( !IS_DEFAULT(s) )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
}
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
{
struct domain *d = s->domain;
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
-struct page_info *page;
-void *va;
int rc;
-if ( (rc = prepare_ring_for_helper(d, gfn, &page, &va)) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(&va, page);
+if ( d->is_dying )
return -EINVAL;
-}
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( IS_DEFAULT(s) )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
-return 0;
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
+
+rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
}
bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -279,8 +291,7 @@ bool is_ioreq_server_page(struct domain *d, const struct
page_info *page)
FOR_EACH_IOREQ_SERVER(d, id, s)
{
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
{
found = true;
break;
@@ -292,20 +303,30 @@ bool is_ioreq_server_page(struct domain *d, const struct
page_info *page)
return found;
}
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
{
+struct domain *d = s->domain;
+struct hvm_ioreq_page *iorp = buf
[Xen-devel] [PATCH v12 00/11] x86: guest resource mapping
This series introduces support for direct mapping of guest resources. The resources are: - IOREQ server pages - Grant tables v12: - Responded to more comments from Jan. v11: - Responded to more comments from Jan. v10: - Responded to comments from Jan. v9: - Change to patch #1 only. v8: - Re-ordered series and dropped two patches that have already been committed. v7: - Fixed assertion failure hit during domain destroy. v6: - Responded to missed comments from Roger. v5: - Responded to review comments from Wei. v4: - Responded to further review comments from Roger. v3: - Dropped original patch #1 since it is covered by Juergen's patch. - Added new xenforeignmemorycleanup patch (#4). - Replaced the patch introducing the ioreq server 'is_default' flag with one that changes the ioreq server list into an array (#8). Paul Durrant (11): x86/hvm/ioreq: maintain an array of ioreq servers rather than a list x86/hvm/ioreq: simplify code and use consistent naming x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page x86/hvm/ioreq: defer mapping gfns until they are actually requsted x86/mm: add HYPERVISOR_memory_op to acquire guest resources x86/hvm/ioreq: add a new mappable resource type... x86/mm: add an extra command to HYPERVISOR_mmu_update... tools/libxenforeignmemory: add support for resource mapping tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint common: add a new mappable resource type: XENMEM_resource_grant_table tools/libxenctrl: use new xenforeignmemory API to seed grant table tools/flask/policy/modules/xen.if | 4 +- tools/include/xen-sys/Linux/privcmd.h | 11 + tools/libs/devicemodel/core.c | 8 + tools/libs/devicemodel/include/xendevicemodel.h| 6 +- tools/libs/foreignmemory/Makefile | 2 +- tools/libs/foreignmemory/core.c| 53 ++ tools/libs/foreignmemory/freebsd.c | 7 - .../libs/foreignmemory/include/xenforeignmemory.h | 41 + tools/libs/foreignmemory/libxenforeignmemory.map | 5 + tools/libs/foreignmemory/linux.c | 45 ++ tools/libs/foreignmemory/minios.c | 7 - tools/libs/foreignmemory/netbsd.c | 7 - tools/libs/foreignmemory/private.h | 43 +- tools/libs/foreignmemory/solaris.c | 7 - tools/libxc/include/xc_dom.h | 8 +- tools/libxc/xc_dom_boot.c | 114 ++- tools/libxc/xc_sr_restore_x86_hvm.c| 10 +- tools/libxc/xc_sr_restore_x86_pv.c | 2 +- tools/libxl/libxl_dom.c| 1 - tools/python/xen/lowlevel/xc/xc.c | 6 +- xen/arch/x86/hvm/dm.c | 9 +- xen/arch/x86/hvm/ioreq.c | 831 - xen/arch/x86/mm.c | 39 +- xen/arch/x86/mm/p2m.c | 3 +- xen/common/compat/memory.c | 95 +++ xen/common/grant_table.c | 49 +- xen/common/memory.c| 142 xen/include/asm-arm/p2m.h | 6 + xen/include/asm-x86/hvm/domain.h | 14 +- xen/include/asm-x86/hvm/ioreq.h| 2 + xen/include/asm-x86/mm.h | 5 + xen/include/asm-x86/p2m.h | 3 + xen/include/public/hvm/dm_op.h | 36 +- xen/include/public/memory.h| 58 +- xen/include/public/xen.h | 12 +- xen/include/xen/grant_table.h | 4 + xen/include/xlat.lst | 1 + xen/include/xsm/dummy.h| 6 + xen/include/xsm/xsm.h | 6 + xen/xsm/dummy.c| 1 + xen/xsm/flask/hooks.c | 6 + xen/xsm/flask/policy/access_vectors| 2 + 42 files changed, 1223 insertions(+), 494 deletions(-) --- Cc: Daniel De Graaf Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: "Marek Marczykowski-Górecki" Cc: Paul Durrant Cc: George Dunlap Cc: Julien Grall -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
I have no means to test it on an ARM platform and so cannot verify
that it functions correctly.
Signed-off-by: Paul Durrant
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Daniel De Graaf
Cc: Julien Grall
v12:
- Addressed more comments form Jan.
- Removed #ifdef CONFIG_X86 from common code and instead introduced a
stub set_foreign_p2m_entry() in asm-arm/p2m.h returning -EOPNOTSUPP.
- Restricted mechanism for querying implementation limit on nr_frames
and simplified compat code.
v11:
- Addressed more comments from Jan.
v9:
- Addressed more comments from Jan.
v8:
- Move the code into common as requested by Jan.
- Make the gmfn_list handle a 64-bit type to avoid limiting the MFN
range for a 32-bit tools domain.
- Add missing pad.
- Add compat code.
- Make this patch deal with purely boilerplate.
- Drop George's A-b and Wei's R-b because the changes are non-trivial,
and update Cc list now the boilerplate is common.
v5:
- Switched __copy_to/from_guest_offset() to copy_to/from_guest_offset().
---
tools/flask/policy/modules/xen.if | 4 +-
xen/arch/x86/mm/p2m.c | 3 +-
xen/common/compat/memory.c | 95 +
xen/common/memory.c | 94
xen/include/asm-arm/p2m.h | 6 +++
xen/include/asm-x86/p2m.h | 3 ++
xen/include/public/memory.h | 43 -
xen/include/xlat.lst| 1 +
xen/include/xsm/dummy.h | 6 +++
xen/include/xsm/xsm.h | 6 +++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 6 +++
xen/xsm/flask/policy/access_vectors | 2 +
13 files changed, 266 insertions(+), 4 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 55437496f6..07cba8a15d 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,8 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext set_misc_info };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
- psr_cmt_op psr_cat_op soft_reset set_gnttab_limits };
+ psr_cmt_op psr_cat_op soft_reset set_gnttab_limits
+ resource_map };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
@@ -152,6 +153,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
+ allow $1 $2_target:domain2 resource_map;
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c72a3cdebb..71bb9b4f93 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1132,8 +1132,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned
long gfn_l,
}
/* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
{
return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_hostp2m(d)->default_access);
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 35bb259808..7f2e2e3107 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -71,6 +71,7 @@ int compat_memory_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void) compat)
struct xen_remove_from_physmap *xrfp;
struct xen_vnuma_topology_info *vnuma;
struct xen_mem_access_op *mao;
+struct xen_mem_acquire_resource *mar;
} nat;
union {
struct compat_memory_reservation rsrv;
@@ -79,6 +80,7 @@ int compat_memory_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void) compat)
struct compat_add_to_physmap_batch atpb;
struct compat_vnuma_topology_info vnuma;
struct compat_mem_access_op mao;
+struct compat_mem_acquire_resource mar;
} cmp;
set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLA
[Xen-devel] [PATCH v12 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous freebsd code.
v3:
- Patch added in response to review comments.
---
tools/libs/foreignmemory/freebsd.c | 7 ---
tools/libs/foreignmemory/minios.c | 7 ---
tools/libs/foreignmemory/netbsd.c | 7 ---
tools/libs/foreignmemory/private.h | 12 +---
tools/libs/foreignmemory/solaris.c | 7 ---
5 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/tools/libs/foreignmemory/freebsd.c
b/tools/libs/foreignmemory/freebsd.c
index dec447485a..6e6bc4b11f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -95,13 +95,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle
*fmem,
return munmap(addr, num << PAGE_SHIFT);
}
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/minios.c
b/tools/libs/foreignmemory/minios.c
index 75f340122e..43341ca301 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -58,13 +58,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle
*fmem,
return munmap(addr, num << PAGE_SHIFT);
}
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c
b/tools/libs/foreignmemory/netbsd.c
index 9bf95ef4f0..54a418ebd6 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -100,13 +100,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle
*fmem,
return munmap(addr, num*XC_PAGE_SIZE);
}
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/private.h
b/tools/libs/foreignmemory/private.h
index 80b22bdbfc..b5d5f0a354 100644
--- a/tools/libs/foreignmemory/private.h
+++ b/tools/libs/foreignmemory/private.h
@@ -32,9 +32,6 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
void *addr, size_t num);
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid);
-
#if defined(__NetBSD__) || defined(__sun__)
/* Strictly compat for those two only only */
void *compat_mapforeign_batch(xenforeignmem_handle *fmem, uint32_t dom,
@@ -54,6 +51,13 @@ struct xenforeignmemory_resource_handle {
};
#ifndef __linux__
+static inline int osdep_xenforeignmemory_restrict(xenforeignmemory_handle
*fmem,
+ domid_t domid)
+{
+errno = EOPNOTSUPP;
+return -1;
+}
+
static inline int osdep_xenforeignmemory_map_resource(
xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
{
@@ -67,6 +71,8 @@ static inline int osdep_xenforeignmemory_unmap_resource(
return 0;
}
#else
+int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
+domid_t domid);
int osdep_xenforeignmemory_map_resource(
xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres);
int osdep_xenforeignmemory_unmap_resource(
diff --git a/tools/libs/foreignmemory/solaris.c
b/tools/libs/foreignmemory/solaris.c
index a33decb4ae..ee8aae4fbd 100644
--- a/tools/libs/foreignmemory/solaris.c
+++ b/tools/libs/foreignmemory/solaris.c
@@ -97,13 +97,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle
*fmem,
return munmap(addr, num*XC_PAGE_SIZE);
}
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
/*
* Local variables:
* mode: C
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v12 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.
Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.
Some function return values are changed by this patch: Specifically, in
the case where the id of the default ioreq server is passed in, -EOPNOTSUPP
is now returned rather than -ENOENT.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
v10:
- modified FOR_EACH... macro as suggested by Jan.
- check for NULL in IS_DEFAULT macro as suggested by Jan.
v9:
- modified FOR_EACH... macro as requested by Andrew.
v8:
- Addressed various comments from Jan.
v7:
- Fixed assertion failure found in testing.
v6:
- Updated according to comments made by Roger on v4 that I'd missed.
v5:
- Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server()
functions to avoid possible double-evaluation issues.
v4:
- Introduced more helper macros and relocated them to the top of the
code.
v3:
- New patch (replacing "move is_default into struct hvm_ioreq_server") in
response to review comments.
---
xen/arch/x86/hvm/ioreq.c | 502 +++
xen/include/asm-x86/hvm/domain.h | 10 +-
2 files changed, 245 insertions(+), 267 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index f2e0b3f74a..e6ccc7572a 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -33,6 +33,37 @@
#include
+static void set_ioreq_server(struct domain *d, unsigned int id,
+ struct hvm_ioreq_server *s)
+{
+ASSERT(id < MAX_NR_IOREQ_SERVERS);
+ASSERT(!s || !d->arch.hvm_domain.ioreq_server.server[id]);
+
+d->arch.hvm_domain.ioreq_server.server[id] = s;
+}
+
+#define GET_IOREQ_SERVER(d, id) \
+(d)->arch.hvm_domain.ioreq_server.server[id]
+
+static struct hvm_ioreq_server *get_ioreq_server(const struct domain *d,
+ unsigned int id)
+{
+if ( id >= MAX_NR_IOREQ_SERVERS )
+return NULL;
+
+return GET_IOREQ_SERVER(d, id);
+}
+
+#define IS_DEFAULT(s) \
+((s) && (s) == GET_IOREQ_SERVER((s)->domain, DEFAULT_IOSERVID))
+
+/* Iterate over all possible ioreq servers */
+#define FOR_EACH_IOREQ_SERVER(d, id, s) \
+for ( (id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \
+if ( !(s = GET_IOREQ_SERVER(d, id)) ) \
+continue; \
+else
+
static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v)
{
shared_iopage_t *p = s->ioreq.va;
@@ -47,10 +78,9 @@ bool hvm_io_pending(struct vcpu *v)
{
struct domain *d = v->domain;
struct hvm_ioreq_server *s;
+unsigned int id;
-list_for_each_entry ( s,
- &d->arch.hvm_domain.ioreq_server.list,
- list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
{
struct hvm_ioreq_vcpu *sv;
@@ -127,10 +157,9 @@ bool handle_hvm_io_completion(struct vcpu *v)
struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io;
struct hvm_ioreq_server *s;
enum hvm_io_completion io_completion;
+unsigned int id;
- list_for_each_entry ( s,
- &d->arch.hvm_domain.ioreq_server.list,
- list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
{
struct hvm_ioreq_vcpu *sv;
@@ -243,13 +272,12 @@ static int hvm_map_ioreq_page(
bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
{
const struct hvm_ioreq_server *s;
+unsigned int id;
bool found = false;
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
-list_for_each_entry ( s,
- &d->arch.hvm_domain.ioreq_server.list,
- list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
{
if ( (s->ioreq.va && s->ioreq.page == page) ||
(s->bufioreq.va && s->bufioreq.page == page) )
@@ -302,7 +330,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server
*s,
}
static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
{
struct hvm_ioreq_vcpu *sv;
int rc;
@@ -331,7 +359,7 @@ static int hvm_ioreq_server_add_vcpu(struct
hvm_ioreq_server *s,
goto fail3;
s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( IS_DEFAULT(s) )
d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] =
s->bufioreq_evtchn;
[Xen-devel] [PATCH v12 08/11] tools/libxenforeignmemory: add support for resource mapping
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Fixed errno and removed single-use label
- The unmap call now returns a status
- Use C99 initialization for ioctl struct
v2:
- Bump minor version up to 3.
---
tools/include/xen-sys/Linux/privcmd.h | 11 +
tools/libs/foreignmemory/Makefile | 2 +-
tools/libs/foreignmemory/core.c| 53 ++
.../libs/foreignmemory/include/xenforeignmemory.h | 41 +
tools/libs/foreignmemory/libxenforeignmemory.map | 5 ++
tools/libs/foreignmemory/linux.c | 45 ++
tools/libs/foreignmemory/private.h | 31 +
7 files changed, 187 insertions(+), 1 deletion(-)
diff --git a/tools/include/xen-sys/Linux/privcmd.h
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
} privcmd_dm_op_t;
+typedef struct privcmd_mmap_resource {
+ domid_t dom;
+ __u32 type;
+ __u32 id;
+ __u32 idx;
+ __u64 num;
+ __u64 addr;
+} privcmd_mmap_resource_t;
+
/*
* @cmd: IOCTL_PRIVCMD_HYPERCALL
* @arg: &privcmd_hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
#define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+ _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
#endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile
b/tools/libs/foreignmemory/Makefile
index ab7f873f26..5c7f78f61d 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/Rules.mk
MAJOR= 1
-MINOR= 2
+MINOR= 3
SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
CFLAGS += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index a6897dc561..8d3f9f178f 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -17,6 +17,8 @@
#include
#include
+#include
+
#include "private.h"
xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
@@ -120,6 +122,57 @@ int xenforeignmemory_restrict(xenforeignmemory_handle
*fmem,
return osdep_xenforeignmemory_restrict(fmem, domid);
}
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+/* Check flags only contains POSIX defined values */
+if ( flags & ~(MAP_SHARED | MAP_PRIVATE) )
+{
+errno = EINVAL;
+return NULL;
+}
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+{
+errno = ENOMEM;
+return NULL;
+}
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+{
+free(fres);
+fres = NULL;
+} else
+*paddr = fres->addr;
+
+return fres;
+}
+
+int xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+int rc = osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+return rc;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..d594be8df0 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,47 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
domid_t domid);
+typedef struct xenforeignmemory_resource_handle
xenforeignmemory_resource_handle;
+
+/**
+ * This function maps a guest resource.
+ *
+ * @parm fmem handle to the open foreignmemory interfac
[Xen-devel] [PATCH v12 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_translate set in its paging mode and, if it does, assumes that the
the pfn value in the l1e is a gfn rather than an mfn.
To allow PV tools domain to map mfn values from a previously issued
HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way
to tell HYPERVISOR_mmu_update that the specific l1e value does not
require translation regardless of the paging mode of foreign_dom. This
patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE,
which has the same semantics as MMU_NORMAL_PT_UPDATE except that the
paging mode of foreign_dom is ignored and the l1e value is used verbatim.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v8:
- New in this version, replacing "allow a privileged PV domain to map
guest mfns".
---
xen/arch/x86/mm.c| 17 ++---
xen/include/public/xen.h | 12 +---
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 1d15ae2a15..63539d5d0b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1619,9 +1619,10 @@ void page_unlock(struct page_info *page)
/* Update the L1 entry at pl1e to new value nl1e. */
static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
-unsigned long gl1mfn, int preserve_ad,
+unsigned long gl1mfn, unsigned int cmd,
struct vcpu *pt_vcpu, struct domain *pg_dom)
{
+bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD);
l1_pgentry_t ol1e;
struct domain *pt_dom = pt_vcpu->domain;
int rc = 0;
@@ -1643,7 +1644,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t
nl1e,
return -EINVAL;
}
-if ( paging_mode_translate(pg_dom) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_dom) )
{
page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL,
P2M_ALLOC);
if ( !page )
@@ -3258,6 +3260,7 @@ long do_mmu_update(
*/
case MMU_NORMAL_PT_UPDATE:
case MMU_PT_UPDATE_PRESERVE_AD:
+case MMU_PT_UPDATE_NO_TRANSLATE:
{
p2m_type_t p2mt;
@@ -3323,7 +3326,8 @@ long do_mmu_update(
p2m_query_t q = (l1e_get_flags(l1e) & _PAGE_RW) ?
P2M_UNSHARE : P2M_ALLOC;
-if ( paging_mode_translate(pg_owner) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_owner) )
target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
&l1e_p2mt, q);
@@ -3350,9 +3354,7 @@ long do_mmu_update(
break;
}
-rc = mod_l1_entry(va, l1e, mfn,
- cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
- pg_owner);
+rc = mod_l1_entry(va, l1e, mfn, cmd, v, pg_owner);
if ( target )
put_page(target);
}
@@ -3630,7 +3632,8 @@ static int __do_update_va_mapping(
goto out;
}
-rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), 0, v, pg_owner);
+rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), MMU_NORMAL_PT_UPDATE, v,
+ pg_owner);
page_unlock(gl1pg);
put_page(gl1pg);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 2ac6b1e24d..d2014a39eb 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -268,6 +268,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
* As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
* with those in @val.
*
+ * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
+ * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
+ * page tables.
+ *
* @val is usually the machine frame number along with some attributes.
* The attributes by default follow the architecture defined bits. Meaning that
* if this is a X86_64 machine and four page table layout is used, the layout
@@ -334,9 +338,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
*
* PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
*/
-#define MMU_NORMAL_PT_UPDATE 0 /* checked '*ptr = val'. ptr is MA. */
-#define MMU_MACHPHYS_UPDATE 1 /* ptr = MA of frame to modify entry for */
-#define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */
+#define MMU_NORMAL_PT_UPDATE 0
[Xen-devel] [PATCH v12 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44
xen/include/asm-x86/hvm/domain.h | 2 +-
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 6d81018369..64bb13cec9 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,7 +210,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
return true;
}
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
{
struct domain *d = s->domain;
unsigned int i;
@@ -220,20 +220,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct
hvm_ioreq_server *s)
for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
{
if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) )
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
}
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
}
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
- unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
{
struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
ASSERT(!IS_DEFAULT(s));
-ASSERT(gfn != gfn_x(INVALID_GFN));
+ASSERT(!gfn_eq(gfn, INVALID_GFN));
set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
}
@@ -242,7 +241,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
{
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
return;
destroy_ring_for_helper(&iorp->va, iorp->page);
@@ -251,7 +250,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
if ( !IS_DEFAULT(s) )
hvm_free_ioreq_gfn(s, iorp->gfn);
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
}
static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -264,16 +263,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
return -EINVAL;
if ( IS_DEFAULT(s) )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
else
iorp->gfn = hvm_alloc_ioreq_gfn(s);
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
return -ENOMEM;
-rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page,
+ &iorp->va);
if ( rc )
hvm_unmap_ioreq_gfn(s, buf);
@@ -309,10 +309,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server
*s, bool buf)
struct domain *d = s->domain;
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
return;
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
domain_crash(d);
clear_page(iorp->va);
@@ -324,12 +324,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
int rc;
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
return 0;
clear_page(iorp->va);
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0);
if ( rc == 0 )
paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -590,8 +590,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
INIT_LIST_HEAD(&s->ioreq_vcpu_list);
spin_lock_init(&s->bufioreq_lock);
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
rc = hvm_ioreq_server_alloc_rangesets(s, id);
if ( rc )
@@ -757,11 +757,11 @@ int hvm_get_ioreq_server_info(struct domain *d,
ioservid_t id,
[Xen-devel] [PATCH v12 06/11] x86/hvm/ioreq: add a new mappable resource type...
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never be present in the P2M of the guest at any point and so are
not vulnerable to any direct attack by the guest. They are only ever
accessible by Xen and any domain that has mapping privilege over the
guest (which may or may not be limited to the domain running the emulator).
NOTE: Use of the new resource type is not compatible with use of
XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
set.
Signed-off-by: Paul Durrant
---
Cc: George Dunlap
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
v12:
- Addressed more comments from Jan.
- Dropped George's A-b and Wei's R-b because of material change.
v11:
- Addressed more comments from Jan.
v10:
- Addressed comments from Jan.
v8:
- Re-base on new boilerplate.
- Adjust function signature of hvm_get_ioreq_server_frame(), and test
whether the bufioreq page is present.
v5:
- Use get_ioreq_server() function rather than indexing array directly.
- Add more explanation into comments to state than mapping guest frames
and allocation of pages for ioreq servers are not simultaneously
permitted.
- Add a comment into asm/ioreq.h stating the meaning of the index
value passed to hvm_get_ioreq_server_frame().
---
xen/arch/x86/hvm/ioreq.c| 156
xen/arch/x86/mm.c | 22 ++
xen/common/memory.c | 5 ++
xen/include/asm-x86/hvm/ioreq.h | 2 +
xen/include/asm-x86/mm.h| 5 ++
xen/include/public/hvm/dm_op.h | 4 ++
xen/include/public/memory.h | 9 +++
7 files changed, 203 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index f654e7796c..2c611fbffa 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -259,6 +259,19 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
int rc;
+if ( iorp->page )
+{
+/*
+ * If a page has already been allocated (which will happen on
+ * demand if hvm_get_ioreq_server_frame() is called), then
+ * mapping a guest frame is not permitted.
+ */
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
if ( d->is_dying )
return -EINVAL;
@@ -281,6 +294,70 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s,
bool buf)
return rc;
}
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct domain *currd = current->domain;
+struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
+
+if ( iorp->page )
+{
+/*
+ * If a guest frame has already been mapped (which may happen
+ * on demand if hvm_get_ioreq_server_info() is called), then
+ * allocating a page is not permitted.
+ */
+if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
+/*
+ * Allocated IOREQ server pages are assigned to the emulating
+ * domain, not the target domain. This is because the emulator is
+ * likely to be destroyed after the target domain has been torn
+ * down, and we must use MEMF_no_refcount otherwise page allocation
+ * could fail if the emulating domain has already reached its
+ * maximum allocation.
+ */
+iorp->page = alloc_domheap_page(currd, MEMF_no_refcount);
+if ( !iorp->page )
+return -ENOMEM;
+
+if ( !get_page_type(iorp->page, PGT_writable_page) )
+{
+ASSERT_UNREACHABLE();
+put_page(iorp->page);
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+iorp->va = __map_domain_page_global(iorp->page);
+if ( !iorp->va )
+{
+put_page_and_type(iorp->page);
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+clear_page(iorp->va);
+return 0;
+}
+
+static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
+
+if ( !iorp->page )
+return;
+
+unmap_domain_page_global(iorp->va);
+iorp->va = NULL;
+
+put_page_and_type(iorp->page);
+iorp->page = NULL;
+}
+
bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
{
const struct hvm_ioreq_server *s;
@@ -484,6 +561,27 @@ static void hvm_ioreq_server_unmap_pages(struct
hvm_ioreq_server *s)
hvm_unmap_ioreq_gfn(s, false);
}
+static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
+{
+int rc;
+
+rc = hvm_alloc_ioreq_mfn(s, false);
+
+if ( !rc && (s->bu
[Xen-devel] [PATCH v12 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
v8:
- For safety make all of the pointers passed to
hvm_get_ioreq_server_info() optional.
- Shrink bufioreq_handling down to a uint8_t.
v3:
- Updated in response to review comments from Wei and Roger.
- Added a HANDLE_BUFIOREQ macro to make the code neater.
- This patch no longer introduces a security vulnerability since there
is now an explicit limit on the number of ioreq servers that may be
created for any one domain.
---
tools/libs/devicemodel/core.c | 8 +
tools/libs/devicemodel/include/xendevicemodel.h | 6 ++--
xen/arch/x86/hvm/dm.c | 9 +++--
xen/arch/x86/hvm/ioreq.c| 47 ++---
xen/include/asm-x86/hvm/domain.h| 2 +-
xen/include/public/hvm/dm_op.h | 32 ++---
6 files changed, 63 insertions(+), 41 deletions(-)
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 0f2c1a791f..91c69d103b 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
data->id = id;
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags |= XEN_DMOP_no_gfns;
+
rc = xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
if (rc)
return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h
b/tools/libs/devicemodel/include/xendevicemodel.h
index 13216db04a..d73a76da35 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
* @parm domid the domain id to be serviced
* @parm id the IOREQ Server id.
* @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- * gfn
+ * gfn. (May be NULL if not required)
* @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gfn. (May be NULL if not required)
* @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
* @return 0 on success, -1 on failure.
*/
int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 9cf53b551c..22fa5b51e3 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args)
{
struct xen_dm_op_get_ioreq_server_info *data =
&op.u.get_ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
const_op = false;
rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
break;
rc = hvm_get_ioreq_server_info(d, data->id,
- &data->ioreq_gfn,
- &data->bufioreq_gfn,
+ (data->flags & XEN_DMOP_no_gfns) ?
+ NULL : &data->ioreq_gfn,
+ (data->flags & XEN_DMOP_no_gfns) ?
+ NULL : &data->bufioreq_gfn,
&data->bufioreq_port);
break;
}
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 64bb13cec9..f654e7796c 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -350,6 +350,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server
*s,
}
}
+#define HANDLE_BUFIOREQ(s) \
+((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
+
static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
struct vcpu *v)
{
@@ -371,7 +374,7 @@ static int hvm_ioreq_server_add_vcpu(struct
hvm_ioreq_server *s,
sv->ioreq_evtchn = rc;
-if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
+if ( v->vcpu_id
Re: [Xen-devel] [PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS
On Tue, Oct 17, 2017 at 4:10 AM, Dario Faggioli wrote: > On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote: >> Change repl_budget event output for xentrace formats and xenalyze >> >> Signed-off-by: Meng Xu >> > I'd say: > > Reviewed-by: Dario Faggioli > > However... > >> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c >> index 79bdba7..19e050f 100644 >> --- a/tools/xentrace/xenalyze.c >> +++ b/tools/xentrace/xenalyze.c >> @@ -7935,23 +7935,29 @@ void sched_process(struct pcpu_info *p) >> unsigned int vcpuid:16, domid:16; >> uint64_t cur_bg; >> int delta; >> +unsigned priority_level; >> +unsigned has_extratime; >> > ...this last field is 'bool' in Xen. > > I appreciate that xenalyze does not build if you just make this bool as > well. But it does build for me, if you do that, and also include > stdbool.h, which I think is a fine thing to do. Right. I'm not sure about this. If including the stdbool.h is preferred, I can resend this one with that change. > > Anyway, I'll leave this to George and tools' maintainers. Sure! Thanks, Meng -- Meng Xu Ph.D. Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/5] Towards work-conserving RTDS
On Tue, Oct 17, 2017 at 3:29 AM, Dario Faggioli wrote: > On Tue, 2017-10-17 at 09:26 +0200, Dario Faggioli wrote: > > On Thu, 2017-10-12 at 10:34 -0400, Meng Xu wrote: > > > On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu > > > wrote: > > > > > > > > FYI all patches except the xentrace one were committed yesterday. > > > > > > Thank you very much, Wei! > > > > > > > Hey Meng, > > > > Any update on that missing patch, though? > > > No, wait... Posted on Wednesday, mmmhh... Ah, so "this" is you posting > the missing patch! > Yes. :) I didn't repost the patch. I made the changes and tested it once I got the feedback. > > Ok, my bad, sorry. I was fooled by the fact that you resent the whole > series, and that I did not get a copy of it (extra-list, I mean) as > you're still using my old email address. > > Lemme have a look... > Ah, I neglected the email address. I was also wondering maybe you were busy with something else. So I didn't send a reminder. Thanks! Best Regards, Meng > > Regards, > Dario > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > -- Meng Xu Ph.D. Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] mm/shadow: fix declaration of fetch_type_names
Hi,
On 17/10/17 11:29, Andrew Cooper wrote:
On 17/10/17 11:23, Roger Pau Monne wrote:
fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
SHADOW_DEBUG, fix the declaration so it's also guarded by
SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
Signed-off-by: Roger Pau Monné
Possibly worth noting that this is exposed by Clang when building with
UBSAN ?
Either way, thanks for getting to the bottom of this issue. (It's been
on my TODO list to figure out for a rather long time.)
Acked-by: Andrew Cooper , and I agree that
this should go into 4.10.
Release-acked-by: Julien Grall
Cheers,
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Julien Grall
---
IMHO, this is a simple compile-time fix, so it should be accepted for
4.10. Any breaking caused by this commit will be spotted at compile
time.
---
xen/arch/x86/mm/shadow/multi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index d540af11d7..9156382056 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -77,7 +77,7 @@ typedef enum {
extern const char *const fetch_type_names[];
-#if defined(DEBUG_TRACE_DUMP) && CONFIG_PAGING_LEVELS == GUEST_PAGING_LEVELS
+#if SHADOW_DEBUG_PROPAGATE && CONFIG_PAGING_LEVELS == GUEST_PAGING_LEVELS
const char *const fetch_type_names[] = {
[ft_prefetch] = "prefetch",
[ft_demand_read] = "demand read",
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 2/2] ubsan: disable unaligned access checks
On 17/10/17 13:58, Roger Pau Monné wrote: > On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote: >> On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote: >>> Currently there are many offenders of the unaligned access checks, >>> which makes booting with the unaligned check a PVH Dom0 impossible. >>> >>> The main offenders seem to be the ACPI code, the VMX code and >>> specially the intremap code (set_ire_sid). >>> >>> Signed-off-by: Roger Pau Monné >>> --- >>> Cc: Andrew Cooper >>> Cc: George Dunlap >>> Cc: Ian Jackson >>> Cc: Jan Beulich >>> Cc: Konrad Rzeszutek Wilk >>> Cc: Stefano Stabellini >>> Cc: Tim Deegan >>> Cc: Wei Liu >>> Cc: Julien Grall >>> --- >>> I'm not sure whether we prefer to fix the offenders, or just disable >>> the alignment wholesale. In any case if we decide to disable the >>> check, the patch should have vary low impact, and hence should be >>> committed to 4.10 on the base that it only affects ubsan, which is not >>> enabled by default and not to be used on production systems. >> I would very much like to fix the offenders but if the fixes turn out to >> be cumbersome, so be it. >> >> What is wrong to leave this enabled? Each location is reported once, >> right? > With clang it's reported every time it's hit AFAICT (certainly more > than once). suppress_report() is supposed to take care of this. Is Clang feeding in different ->location information each time through? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures
Hi Andrew,
On 16/10/17 15:38, Andrew Cooper wrote:
* x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
all state is actually set up. As it currently stands, d0v0 is eligible for
scheduling before its registers have been set. This is latent as we also
hold a systemcontroller pause reference at the time which prevents d0 from
being scheduled.
* x86 PVH dom0's must set v->is_initialised on d0v0, to prevent another vcpu
being able to call VCPUOP_initialise and modify state under the feet of the
running vcpu. This is latent as PVH dom0 construction don't yet function.
Signed-off-by: Andrew Cooper
Release-acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/arm/domain_build.c | 6 +++---
xen/arch/x86/dom0_build.c | 13 +++--
xen/arch/x86/hvm/dom0_build.c | 1 +
xen/arch/x86/pv/dom0_build.c | 6 +++---
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4636b17..bf29299 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2197,9 +2197,6 @@ int construct_dom0(struct domain *d)
discard_initial_modules();
-v->is_initialised = 1;
-clear_bit(_VPF_down, &v->pause_flags);
-
memset(regs, 0, sizeof(*regs));
regs->pc = (register_t)kinfo.entry;
@@ -2247,6 +2244,9 @@ int construct_dom0(struct domain *d)
vcpu_switch_to_aarch64_mode(d->vcpu[i]);
}
+v->is_initialised = 1;
+clear_bit(_VPF_down, &v->pause_flags);
+
return 0;
}
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index e4bffd5..bf992fe 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -466,6 +466,8 @@ int __init construct_dom0(struct domain *d, const module_t
*image,
void *(*bootstrap_map)(const module_t *),
char *cmdline)
{
+int rc;
+
/* Sanity! */
BUG_ON(d->domain_id != 0);
BUG_ON(d->vcpu[0] == NULL);
@@ -481,8 +483,15 @@ int __init construct_dom0(struct domain *d, const module_t
*image,
}
#endif
-return (is_hvm_domain(d) ? dom0_construct_pvh : dom0_construct_pv)
- (d, image, image_headroom, initrd,bootstrap_map, cmdline);
+rc = (is_hvm_domain(d) ? dom0_construct_pvh : dom0_construct_pv)
+ (d, image, image_headroom, initrd, bootstrap_map, cmdline);
+if ( rc )
+return rc;
+
+/* Sanity! */
+BUG_ON(!d->vcpu[0]->is_initialised);
+
+return 0;
}
/*
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index e8f746c..a67071c 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -614,6 +614,7 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t
entry,
update_domain_wallclock_time(d);
+v->is_initialised = 1;
clear_bit(_VPF_down, &v->pause_flags);
return 0;
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index dcbee43..8ad7e3d 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -847,9 +847,6 @@ int __init dom0_construct_pv(struct domain *d,
update_domain_wallclock_time(d);
-v->is_initialised = 1;
-clear_bit(_VPF_down, &v->pause_flags);
-
/*
* Initial register values:
* DS,ES,FS,GS = FLAT_KERNEL_DS
@@ -883,6 +880,9 @@ int __init dom0_construct_pv(struct domain *d,
if ( d->domain_id == hardware_domid )
iommu_hwdom_init(d);
+v->is_initialised = 1;
+clear_bit(_VPF_down, &v->pause_flags);
+
return 0;
out:
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky wrote: > On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: >> On 10/12/2017 03:27 PM, Andrew Cooper wrote: >>> On 12/10/17 20:11, Boris Ostrovsky wrote: There is also another problem: [1.312425] general protection fault: [#1] SMP [1.312901] Modules linked in: [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 [1.313878] task: 88003e2c task.stack: c938c000 [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5 [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046 [1.315336] RAX: 000c RBX: 55f550168040 RCX: 7fcfc959f59a [1.315827] RDX: RSI: RDI: [1.316315] RBP: 000a R08: 037f R09: 0064 [1.316805] R10: 1f89cbf5 R11: 88003e2c R12: 7fcfc958ad60 [1.317300] R13: R14: 55f550185954 R15: 1000 [1.317801] FS: () GS:88003f80() knlGS: [1.318267] CS: e033 DS: ES: CR0: 80050033 [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4: 00042660 [1.319235] Call Trace: [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50 [1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- [1.345009] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b All code 0:51 push %rcx 1:50 push %rax 2:57 push %rdi 3:56 push %rsi 4:52 push %rdx 5:51 push %rcx 6:6a dapushq $0xffda 8:41 50push %r8 a:41 51push %r9 c:41 52push %r10 e:41 53push %r11 10:48 83 ec 30 sub$0x30,%rsp 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11 1b:00 00 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11) 24:0f 85 a5 00 00 00jne0xcf 2a:50 push %rax 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)# 0xffd095cd<-- trapping instruction 31:58 pop%rax 32:48 3d 4c 01 00 00cmp$0x14c,%rax 38:77 0fja 0x49 3a:4c 89 d1 mov%r10,%rcx 3d:ff .byte 0xff 3e:14 c5adc$0xc5,%al so the original 'cli' was replaced with the pv call but to me the offset looks a bit off, no? Shouldn't it always be positive? >>> callq takes a 32bit signed displacement, so jumping back by up to 2G is >>> perfectly legitimate. >> Yes, but >> >> ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath >> 817365dd t entry_SYSCALL_64_fastpath >> ostr@workbase> nm vmlinux | grep " pv_irq_ops" >> 81c2dbc0 D pv_irq_ops >> ostr@workbase> >> >> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I >> didn't mean that x86 instruction set doesn't allow negative >> displacement, I was trying to say that pv_irq_ops always live further down) > > I believe the problem is this: > > #define PV_INDIRECT(addr) *addr(%rip) > > The displacement that the linker computes will be relative to the where > this instruction is placed at the time of linking, which is in > .pv_altinstructions (and not .text). So when we copy it into .text the > displacement becomes bogus. > > Replacing the macro with > > #define PV_INDIRECT(addr) *addr // well, it's not so much > indirect anymore > > makes things work. Or maybe it can be adjusted top be kept truly indirect. That is still an indirect call, just using absolute addressing for the pointer instead of RIP-relative. Alternatives has very limited relocation capabilities. It will only handle a single call or jmp replacement. Using absolute addressing is slightly less efficient (takes one extra byte to encode, and needs a relocation for KASLR), but it works just as well. You could also relocate the instruction manually by adding the delta between the original and replacement code to the displacement. -- Brian Gerst ___ Xen-devel mailing
Re: [Xen-devel] [PATCH for-4.10 1/2] ubsan: add clang 5.0 support
>>> On 17.10.17 at 14:57, wrote:
> On Tue, Oct 17, 2017 at 06:43:28AM -0600, Jan Beulich wrote:
>> >>> On 17.10.17 at 13:36, wrote:
>> > clang 5.0 changed the layout of the type_mismatch_data structure and
>> > introduced __ubsan_handle_type_mismatch_v1 and
>> > __ubsan_handle_pointer_overflow.
>> >
>> > This commit adds support for the new structure layout, adds the
>> > missing handlers and the new types for type_check_kinds.
>> >
>> > Signed-off-by: Roger Pau Monné
>>
>> Acked-by: Jan Beulich
>> with a remark:
>>
>> > +void __ubsan_handle_pointer_overflow(struct pointer_overflow_data *data,
>> > + unsigned long base, unsigned long result)
>> > +{
>> > + unsigned long flags;
>> > +
>> > + if (suppress_report(&data->location))
>> > + return;
>> > +
>> > + ubsan_prologue(&data->location, &flags);
>> > +
>> > + pr_err("pointer overflow:\n");
>> > +
>> > + if (((long)base >= 0) == ((long)result >= 0))
>> > + pr_err("%s of unsigned offset to %p overflowed to %p\n",
>> > + base > result ? "addition" : "subtraction",
>>
>> Strictly speaking you also want to make "to" conditional upon this
>> being an add; for subtract it ought to be "from". Or perhaps just
>> say overflow and underflow?
>>
>> And then - is "base > result" really a valid determination of
>> add/subtract (or overflow/underflow)? If the pointed to type is
>> wider than one byte, an addition may wrap one or more times
>> and still yield a value larger than the starting pointer.
>
> That code is mostly adapted from upstream llvm:
>
> https://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/ubsan/ubsan_handler
>
> s.cc?revision=313572&view=markup
>
> But I see your point, if the types have different widths that check
> won't work properly. In any case, I don't see a better way to deal
> with this.
Well, as said - perhaps simply use
pr_err("pointer operation %s %p to %p\n",
base > result ? "underflowed" : "overflowed",
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 2/2] ubsan: disable unaligned access checks
On Tue, Oct 17, 2017 at 01:58:47PM +0100, Roger Pau Monné wrote: > On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote: > > On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote: > > > Currently there are many offenders of the unaligned access checks, > > > which makes booting with the unaligned check a PVH Dom0 impossible. > > > > > > The main offenders seem to be the ACPI code, the VMX code and > > > specially the intremap code (set_ire_sid). > > > > > > Signed-off-by: Roger Pau Monné > > > --- > > > Cc: Andrew Cooper > > > Cc: George Dunlap > > > Cc: Ian Jackson > > > Cc: Jan Beulich > > > Cc: Konrad Rzeszutek Wilk > > > Cc: Stefano Stabellini > > > Cc: Tim Deegan > > > Cc: Wei Liu > > > Cc: Julien Grall > > > --- > > > I'm not sure whether we prefer to fix the offenders, or just disable > > > the alignment wholesale. In any case if we decide to disable the > > > check, the patch should have vary low impact, and hence should be > > > committed to 4.10 on the base that it only affects ubsan, which is not > > > enabled by default and not to be used on production systems. > > > > I would very much like to fix the offenders but if the fixes turn out to > > be cumbersome, so be it. > > > > What is wrong to leave this enabled? Each location is reported once, > > right? > > With clang it's reported every time it's hit AFAICT (certainly more > than once). > It could also be the case that some functions are inlined so they could appear multiple times, i.e. they have different instances of struct location? I've also seen something like that before. The code in ubsan.c already deals with setting the reported bit so I suspect after all the instances have been marked reported Xen should run fine? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] string: fix memmove when size is 0
>>> On 17.10.17 at 14:52, wrote: > On Tue, Oct 17, 2017 at 01:41:35PM +0100, Andrew Cooper wrote: >> There are many passed values which could trigger this warning. Does >> >> diff --git a/xen/arch/x86/string.c b/xen/arch/x86/string.c >> index cd85a38..4f55856 100644 >> --- a/xen/arch/x86/string.c >> +++ b/xen/arch/x86/string.c >> @@ -47,7 +47,7 @@ void *(memmove)(void *dest, const void *src, size_t n) >> " rep movsb ; " >> " cld " >> : "=&c" (d0), "=&S" (d1), "=&D" (d2) >> -: "0" (n), "1" (n-1+(const char *)src), "2" (n-1+(char *)dest) >> +: "0" (n), "1" ((uintptr_t)src + n - 1), "2" ((uintptr_t)dest + n - >> 1) >> : "memory"); >> >> return dest; >> >> work any better? > > That does indeed work, but I'm not sure if it would mask legitimate > pointer overflows by casting them into integers. It certainly would, as the tool can't possibly know that the asm() itself then effectively casts the integers back to pointers (i.e. it has no basis to try to "look through" the cast and continue analysis). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 2/2] ubsan: disable unaligned access checks
On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote: > On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote: > > Currently there are many offenders of the unaligned access checks, > > which makes booting with the unaligned check a PVH Dom0 impossible. > > > > The main offenders seem to be the ACPI code, the VMX code and > > specially the intremap code (set_ire_sid). > > > > Signed-off-by: Roger Pau Monné > > --- > > Cc: Andrew Cooper > > Cc: George Dunlap > > Cc: Ian Jackson > > Cc: Jan Beulich > > Cc: Konrad Rzeszutek Wilk > > Cc: Stefano Stabellini > > Cc: Tim Deegan > > Cc: Wei Liu > > Cc: Julien Grall > > --- > > I'm not sure whether we prefer to fix the offenders, or just disable > > the alignment wholesale. In any case if we decide to disable the > > check, the patch should have vary low impact, and hence should be > > committed to 4.10 on the base that it only affects ubsan, which is not > > enabled by default and not to be used on production systems. > > I would very much like to fix the offenders but if the fixes turn out to > be cumbersome, so be it. > > What is wrong to leave this enabled? Each location is reported once, > right? With clang it's reported every time it's hit AFAICT (certainly more than once). Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 1/2] ubsan: add clang 5.0 support
On Tue, Oct 17, 2017 at 06:43:28AM -0600, Jan Beulich wrote:
> >>> On 17.10.17 at 13:36, wrote:
> > clang 5.0 changed the layout of the type_mismatch_data structure and
> > introduced __ubsan_handle_type_mismatch_v1 and
> > __ubsan_handle_pointer_overflow.
> >
> > This commit adds support for the new structure layout, adds the
> > missing handlers and the new types for type_check_kinds.
> >
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Jan Beulich
> with a remark:
>
> > +void __ubsan_handle_pointer_overflow(struct pointer_overflow_data *data,
> > + unsigned long base, unsigned long result)
> > +{
> > + unsigned long flags;
> > +
> > + if (suppress_report(&data->location))
> > + return;
> > +
> > + ubsan_prologue(&data->location, &flags);
> > +
> > + pr_err("pointer overflow:\n");
> > +
> > + if (((long)base >= 0) == ((long)result >= 0))
> > + pr_err("%s of unsigned offset to %p overflowed to %p\n",
> > + base > result ? "addition" : "subtraction",
>
> Strictly speaking you also want to make "to" conditional upon this
> being an add; for subtract it ought to be "from". Or perhaps just
> say overflow and underflow?
>
> And then - is "base > result" really a valid determination of
> add/subtract (or overflow/underflow)? If the pointed to type is
> wider than one byte, an addition may wrap one or more times
> and still yield a value larger than the starting pointer.
That code is mostly adapted from upstream llvm:
https://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/ubsan/ubsan_handlers.cc?revision=313572&view=markup
But I see your point, if the types have different widths that check
won't work properly. In any case, I don't see a better way to deal
with this.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Build issues since XSA 240
>>> On 17.10.17 at 14:44, wrote: > We are seeing some build issues since XSA 240 was released, since I > didn't know if it was related to our build job I've isolated everything > so anybody could recreate the test. > We use Xen 4.8.2 and build it on debian 9 (9.1 to be exact) and since > XSA 240 we have xen crashing on some servers (mostly dev machine so > it's ok but still ...). > As said to be sure that everyone can recreate the problem I've created > a script that ~do what our jenkins job is doing : > https://gist.github.com/evadot/40f92fb5320121fd8ee3b6d0d9c256c1 > I've set the bits for reproducible build since it makes it easier to > test on multiple machines. > With this script runned on a debian 9.1 machine (either vm or > physical) from /root/ directly (I didn't found the variable that remove > build path for repro build if one exists) I get the build id > 0764c6f6d385feed46c4b18803dabc282a50ae8b and when starting this binary > on a Dell C6100 (Xeon L5640) I have this : > https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_gcc-0764c6f6d > 385feed46c4b18803dabc282a50ae8b.txt > > If I switch to clang (just added clang=y to make defconfig and make > build) I have this : > https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_clang-2261d6a > d42adef475fa638b87f7364df155919a9.txt > There seems to be some memory corruption on this last one (where the > ram map is printed). > > But if I build it on my FreeBSD machine (12-CURRENT, clang 5.0.0) or a > FreeBSD 11.1 VM (clang 4.0.0) I can boot my dom0 and start VMs. Wasn't it you who (under email address emmanuel.va...@gandi.net) reported this same or a pretty similar problem to the discussion list already during the embargo, finding out later that this was due to flawed hardware on the build system of yours? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 2/2] ubsan: disable unaligned access checks
On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote: > Currently there are many offenders of the unaligned access checks, > which makes booting with the unaligned check a PVH Dom0 impossible. > > The main offenders seem to be the ACPI code, the VMX code and > specially the intremap code (set_ire_sid). > > Signed-off-by: Roger Pau Monné > --- > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > Cc: Julien Grall > --- > I'm not sure whether we prefer to fix the offenders, or just disable > the alignment wholesale. In any case if we decide to disable the > check, the patch should have vary low impact, and hence should be > committed to 4.10 on the base that it only affects ubsan, which is not > enabled by default and not to be used on production systems. I would very much like to fix the offenders but if the fixes turn out to be cumbersome, so be it. What is wrong to leave this enabled? Each location is reported once, right? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output
On Tue, Oct 17, 2017 at 6:19 AM, Dave Martin wrote:
> On Tue, Oct 17, 2017 at 10:51:07AM +0100, Andre Przywara wrote:
>> Hi Bhupinder,
>>
>> first thing: As the bulk of the series has been merged now, please
>> restart your patch and version numbering, so a (potential) next post
>> should be prefixed [PATCH v3 1/2]. And please have a cover letter giving
>> a brief overview what this series fixes.
>>
>> On 13/10/17 11:40, Bhupinder Thakur wrote:
>> > The early console output uses pl011_early_write() to write data. This
>> > function waits for BUSY bit to get cleared before writing the next byte.
>>
>> ... which is questionable given the actual definition of the BUSY bit in
>> the PL011 TRM:
>>
>>
>> The BUSY signal goes HIGH as soon as data is written to the
>> transmit FIFO (that is, the FIFO is non-empty) and remains asserted
>> HIGH while data is being transmitted. BUSY is negated only when the
>> transmit FIFO is empty, and the last character has been transmitted from
>> the shift register,
>>
>>
>> (I take it you are talking about the Linux driver in a guest here).
>> I think the early_write routine tries to (deliberately?) ignore the
>> FIFO, possibly to make sure characters really get pushed out before a
>> system crashes, maybe.
>>
>> >
>> > In the SBSA UART emulation logic, the BUSY bit was set as soon one
>> > byte was written in the FIFO and it remained set until the FIFO was
>> > emptied.
>>
>> Which is correct behaviour, as this matches the PL011 TRM as quoted above.
>>
>> > This meant that the output was delayed as each character needed
>> > the BUSY to get cleared.
>>
>> But this is true as well!
>>
>> > Since the SBSA UART is getting emulated in Xen using ring buffers, it
>> > ensures that once the data is enqueued in the FIFO, it will be received
>> > by xenconsole so it is safe to set the BUSY bit only when FIFO becomes
>> > full. This will ensure that pl011_early_write() is not delayed unduly
>> > to write the data.
>>
>> So I can confirm that this patch fixes the very slow earlycon output
>> observed with the current staging HEAD.
>>
>> So while this is somewhat deviating from the spec, I can see the benefit
>> for an emulation scenario. I believe that emulations in general might
>> choose implementing things a bit differently, to cope with the
>> fundamental differences in their environment, like the virtually endless
>> "FIFO" and the lack of any timing restrictions on the emulated "wire".
>>
>> So unless someone comes up with a better solution, I would support
>> taking this patch, as this fixes a real problem.
>
> I think you get away with this, but it does violate the spec in order
> to work around a feature of a correctly implemented driver.
>
> Software can now see this, for example:
>
> uart_write(ch, UARTDR);
> busy = uart_read(UARTFR) & UARTFR_BUSY;
> BUG_ON(!(uart_read(UARTFR) & UARTFR_TXFE) && !busy);
>
> which violates the spec, though I can't currently think of a good reason
> for software to rely on that.
>
>
> [+Rob, who wrote the original earlycon code in the amba-pl011 driver:
> 0d3c673e7881 ("tty/serial: pl011: add generic earlycon support")
>
> Is there any actualy reason why we poll for !BUSY after each char in
> pl011_putc()? pl011_putc() is not exposed at all: it's only called by
> pl011_console_write().
>
> This will result in stuttering output even on hardware, though this
> doesn't typically matter.
>
> I think if the poll for !BUSY were moved to the end of
> pl011_console_write(), the effect would be much less bad.]
I just copied the code from the arm64 earlyprintk code... Maybe it was
because on simulation (which was the main platform at the time) folks
wanted the character "on the wire". It seems to be that you could just
drop it.
Rob
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] string: fix memmove when size is 0
On Tue, Oct 17, 2017 at 01:41:35PM +0100, Andrew Cooper wrote: > On 17/10/17 13:03, Roger Pau Monne wrote: > > ubsan in clang 5.0 complains with: > > > > (XEN) UBSAN: Undefined behaviour in string.c:50:28 > > (XEN) pointer overflow: > > (XEN) addition of unsigned offset to 8310 overflowed to > > 830f > > [...] > > (XEN) Xen call trace: > > (XEN)[] ubsan.c#ubsan_epilogue+0xd/0xc0 > > (XEN)[] __ubsan_handle_pointer_overflow+0xa5/0xe0 > > (XEN)[] memmove+0x67/0x80 > > (XEN)[] page_alloc.c#bootmem_region_add+0x157/0x220 > > (XEN)[] init_boot_pages+0x56/0x220 > > (XEN)[] __start_xen+0x2c2d/0x4b50 > > (XEN)[] __high_start+0x53/0x60 > > > > This is due to memmove doing a n-1+addr when n is 0. This is harmless > > because the loop is bounded to 0. Fix this by returning earlier when n > > is 0. > > > > Signed-off-by: Roger Pau Monné > > There are many passed values which could trigger this warning. Does > > diff --git a/xen/arch/x86/string.c b/xen/arch/x86/string.c > index cd85a38..4f55856 100644 > --- a/xen/arch/x86/string.c > +++ b/xen/arch/x86/string.c > @@ -47,7 +47,7 @@ void *(memmove)(void *dest, const void *src, size_t n) > " rep movsb ; " > " cld " > : "=&c" (d0), "=&S" (d1), "=&D" (d2) > -: "0" (n), "1" (n-1+(const char *)src), "2" (n-1+(char *)dest) > +: "0" (n), "1" ((uintptr_t)src + n - 1), "2" ((uintptr_t)dest + n - > 1) > : "memory"); > > return dest; > > work any better? That does indeed work, but I'm not sure if it would mask legitimate pointer overflows by casting them into integers. In any case, as said on IRC the only problematic case ATM is when n == 0. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 October 2017 13:53
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; KonradRzeszutek Wilk
> ; Daniel de Graaf ; Tim
> (Xen.org)
> Subject: RE: [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to
> acquire guest resources
>
> >>> On 17.10.17 at 14:28, wrote:
> >> -Original Message-
> >>
> >> > --- a/xen/include/xsm/dummy.h
> >> > +++ b/xen/include/xsm/dummy.h
> >> > @@ -724,3 +724,9 @@ static XSM_INLINE int xsm_xen_version
> >> (XSM_DEFAULT_ARG uint32_t op)
> >> > return xsm_default_action(XSM_PRIV, current->domain, NULL);
> >> > }
> >> > }
> >> > +
> >> > +static XSM_INLINE int
> xsm_domain_resource_map(XSM_DEFAULT_ARG
> >> struct domain *d)
> >> > +{
> >> > +XSM_ASSERT_ACTION(XSM_DM_PRIV);
> >> > +return xsm_default_action(action, current->domain, d);
> >> > +}
> >>
> >> Perhaps better place this near something similar/related (also for
> >> some of the other additions further down)?
> >
> > Looking at this again it seems that various related things, e.g.
> > domain_memory_map, are x86 only so adding at the end seems like the
> best
> > thing to do.
>
> Well, okay then (unless Daniel, whom it looks like you forgot to Cc,
> has a better suggestion).
>
Yes, I realised that I forgot to cc him in since the code was added. He's on
the v12 list.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
>>> On 17.10.17 at 14:28, wrote:
>> -Original Message-
>>
>> > --- a/xen/include/xsm/dummy.h
>> > +++ b/xen/include/xsm/dummy.h
>> > @@ -724,3 +724,9 @@ static XSM_INLINE int xsm_xen_version
>> (XSM_DEFAULT_ARG uint32_t op)
>> > return xsm_default_action(XSM_PRIV, current->domain, NULL);
>> > }
>> > }
>> > +
>> > +static XSM_INLINE int xsm_domain_resource_map(XSM_DEFAULT_ARG
>> struct domain *d)
>> > +{
>> > +XSM_ASSERT_ACTION(XSM_DM_PRIV);
>> > +return xsm_default_action(action, current->domain, d);
>> > +}
>>
>> Perhaps better place this near something similar/related (also for
>> some of the other additions further down)?
>
> Looking at this again it seems that various related things, e.g.
> domain_memory_map, are x86 only so adding at the end seems like the best
> thing to do.
Well, okay then (unless Daniel, whom it looks like you forgot to Cc,
has a better suggestion).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 2/2] ubsan: disable unaligned access checks
>>> On 17.10.17 at 13:36, wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -120,7 +120,7 @@ $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) > $(extra-y)): CFLAGS += - > endif > > ifeq ($(CONFIG_UBSAN),y) > -$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS > += -fsanitize=undefined > +$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS > += -fsanitize=undefined -fno-sanitize=alignment > endif As was said by I think Andrew on irc, this is fine for x86 but not fine for ARM. Even if we enable UBSAN for x86 only right now, I think such option additions should be done in an arch-specific way. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Build issues since XSA 240
Hello, We are seeing some build issues since XSA 240 was released, since I didn't know if it was related to our build job I've isolated everything so anybody could recreate the test. We use Xen 4.8.2 and build it on debian 9 (9.1 to be exact) and since XSA 240 we have xen crashing on some servers (mostly dev machine so it's ok but still ...). As said to be sure that everyone can recreate the problem I've created a script that ~do what our jenkins job is doing : https://gist.github.com/evadot/40f92fb5320121fd8ee3b6d0d9c256c1 I've set the bits for reproducible build since it makes it easier to test on multiple machines. With this script runned on a debian 9.1 machine (either vm or physical) from /root/ directly (I didn't found the variable that remove build path for repro build if one exists) I get the build id 0764c6f6d385feed46c4b18803dabc282a50ae8b and when starting this binary on a Dell C6100 (Xeon L5640) I have this : https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_gcc-0764c6f6d385feed46c4b18803dabc282a50ae8b.txt If I switch to clang (just added clang=y to make defconfig and make build) I have this : https://www.bidouilliste.com/xen/log_xen_4.8.2_xsa_231-xsa-245_clang-2261d6ad42adef475fa638b87f7364df155919a9.txt There seems to be some memory corruption on this last one (where the ram map is printed). But if I build it on my FreeBSD machine (12-CURRENT, clang 5.0.0) or a FreeBSD 11.1 VM (clang 4.0.0) I can boot my dom0 and start VMs. I really don't know what's happening and if someone have any idea how to debug this I'll be very happy. I've also put the xen-syms binary here : https://www.bidouilliste.com/xen/xen-syms-0764c6f6d385feed46c4b18803dabc282a50ae8b https://www.bidouilliste.com/xen/xen-syms-2261d6ad42adef475fa638b87f7364df155919a9 Thanks, -- Emmanuel Vadot ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
