[ovmf test] 162659: regressions - FAIL
flight 162659 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162659/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf b8649cf2a3e673a4a8cb6c255e394b354b771550 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z8 days Failing since162368 2021-06-04 15:42:59 Z7 days9 attempts Testing same since 162583 2021-06-09 23:44:58 Z2 days4 attempts People who touched revisions under test: Ard Biesheuvel Kaaira Gupta Laszlo Ersek Leif Lindholm Liming Gao Ni, Ray Ray Ni Rebecca Cran jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1717 lines long.)
[xen-unstable-smoke test] 162674: tolerable all pass - PUSHED
flight 162674 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/162674/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 93031fbe9f4c341a2e7950a088025ea550291433 baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z2 days Failing since162584 2021-06-10 00:00:27 Z2 days 14 attempts Testing same since 162674 2021-06-12 02:01:29 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Ian Jackson Jan Beulich Juergen Gross Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 3e09045991..93031fbe9f 93031fbe9f4c341a2e7950a088025ea550291433 -> smoke
[qemu-mainline test] 162650: regressions - FAIL
flight 162650 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162650/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass
[xen-unstable-smoke test] 162665: regressions - FAIL
flight 162665 xen-unstable-smoke real [real] flight 162671 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162665/ http://logs.test-lab.xenproject.org/osstest/logs/162671/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen d2cad41defe4e0e9987549fbc8ebdf9ae138f90f baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z2 days Failing since162584 2021-06-10 00:00:27 Z2 days 13 attempts Testing same since 162642 2021-06-11 10:00:31 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Ian Jackson Jan Beulich Juergen Gross Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit d2cad41defe4e0e9987549fbc8ebdf9ae138f90f Author: Juergen Gross Date: Wed May 12 16:48:32 2021 +0200 tools/libs/store: cleanup libxenstore interface There are some internals in the libxenstore interface which should be removed. Move those functions into xs_lib.c and the related definitions into xs_lib.h. Remove the functions from the mapfile. Add xs_lib.o to xenstore_client as some of the internal functions are needed there. Bump the libxenstore version to 4.0 as the change is incompatible. Note that the removed functions should not result in any problem as they ought to be used by xenstored or xenstore_client only. Avoid an enum as part of a structure as the size of an enum is compiler implementation dependent. Signed-off-by: Juergen Gross Acked-by: Ian Jackson commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a
[linux-linus test] 162643: regressions - FAIL
flight 162643 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162643/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-freebsd11-amd64 17 guest-localmigrate fail REGR. vs. 152332 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail
Re: [PATCH v2] Arm32: MSR to SPSR needs qualification
On Fri, 11 Jun 2021, Jan Beulich wrote:
> The Arm ARM's description of MSR (ARM DDI 0406C.d section B9.3.12)
> doesn't even allow for plain "SPSR" here, and while gas accepts this, it
> takes it to mean SPSR_cf. Yet surely all of SPSR wants updating on this
> path, not just the lowest and highest 8 bits.
>
> Fixes: dfcffb128be4 ("xen/arm32: SPSR_hyp/SPSR")
> Signed-off-by: Jan Beulich
Thanks for the patch! I disassembled the instruction in the bad Xen
binary and confirmed that 2 of the mask bits are off.
Rebuilding the binary with your patch applied solves the issue: now are
4 bits are set.
Thank you so much!
Reviewed-by: Stefano Stabellini
> ---
> v2: Add doc ref.
>
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -395,7 +395,7 @@ return_to_hypervisor:
> ldr r11, [sp, #UREGS_pc]
> msr ELR_hyp, r11
> ldr r11, [sp, #UREGS_cpsr]
> -msr SPSR, r11
> +msr SPSR_cxsf, r11
> #ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> /*
> * Hardening branch predictor may require to setup a different
>
[xen-unstable-smoke test] 162656: regressions - FAIL
flight 162656 xen-unstable-smoke real [real] flight 162663 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162656/ http://logs.test-lab.xenproject.org/osstest/logs/162663/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen d2cad41defe4e0e9987549fbc8ebdf9ae138f90f baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z2 days Failing since162584 2021-06-10 00:00:27 Z1 days 12 attempts Testing same since 162642 2021-06-11 10:00:31 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Ian Jackson Jan Beulich Juergen Gross Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit d2cad41defe4e0e9987549fbc8ebdf9ae138f90f Author: Juergen Gross Date: Wed May 12 16:48:32 2021 +0200 tools/libs/store: cleanup libxenstore interface There are some internals in the libxenstore interface which should be removed. Move those functions into xs_lib.c and the related definitions into xs_lib.h. Remove the functions from the mapfile. Add xs_lib.o to xenstore_client as some of the internal functions are needed there. Bump the libxenstore version to 4.0 as the change is incompatible. Note that the removed functions should not result in any problem as they ought to be used by xenstored or xenstore_client only. Avoid an enum as part of a structure as the size of an enum is compiler implementation dependent. Signed-off-by: Juergen Gross Acked-by: Ian Jackson commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a
[xen-unstable test] 162633: regressions - FAIL
flight 162633 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/162633/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 162533 test-xtf-amd64-amd64-4 19 xtf/test-pv32pae-selftest fail REGR. vs. 162533 test-amd64-i386-examine 8 reboot fail REGR. vs. 162533 test-amd64-i386-migrupgrade 13 xen-boot/dst_hostfail REGR. vs. 162533 test-amd64-i386-xl-shadow 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 8 xen-boot fail REGR. vs. 162533 test-xtf-amd64-amd64-5 19 xtf/test-pv32pae-selftest fail REGR. vs. 162533 test-xtf-amd64-amd64-2 19 xtf/test-pv32pae-selftest fail REGR. vs. 162533 test-xtf-amd64-amd64-1 19 xtf/test-pv32pae-selftest fail REGR. vs. 162533 test-xtf-amd64-amd64-3 19 xtf/test-pv32pae-selftest fail REGR. vs. 162533 test-amd64-i386-xl-raw8 xen-boot fail REGR. vs. 162533 test-amd64-i386-libvirt 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-qemuu-rhel6hvm-intel 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-qemut-rhel6hvm-amd 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-pair 12 xen-boot/src_hostfail REGR. vs. 162533 test-amd64-i386-pair 13 xen-boot/dst_hostfail REGR. vs. 162533 test-amd64-coresched-i386-xl 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemut-win7-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-freebsd10-i386 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemut-debianhvm-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-freebsd10-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-libvirt-xsm 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-qemut-rhel6hvm-intel 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-xsm8 xen-boot fail REGR. vs. 162533 test-amd64-i386-livepatch 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-pvshim 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-libvirt-pair 12 xen-boot/src_hostfail REGR. vs. 162533 test-amd64-i386-libvirt-pair 13 xen-boot/dst_hostfail REGR. vs. 162533 test-amd64-amd64-i386-pvgrub 17 guest-localmigrate fail REGR. vs. 162533 test-amd64-amd64-amd64-pvgrub 17 guest-localmigrate fail REGR. vs. 162533 test-amd64-i386-qemuu-rhel6hvm-amd 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-debianhvm-amd64 8 xen-boot fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-win7-amd64 8 xen-boot fail REGR. vs. 162533 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit2 8 xen-boot fail in 162600 pass in 162633 test-amd64-amd64-examine4 memdisk-try-append fail in 162600 pass in 162633 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail in 162600 pass in 162633 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 162600 pass in 162633 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail pass in 162600 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 162422 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162533 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 162533 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 162533 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162533 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 162533 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 162533 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162533 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never
[ovmf test] 162637: regressions - FAIL
flight 162637 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162637/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf b8649cf2a3e673a4a8cb6c255e394b354b771550 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z7 days Failing since162368 2021-06-04 15:42:59 Z7 days8 attempts Testing same since 162583 2021-06-09 23:44:58 Z1 days3 attempts People who touched revisions under test: Ard Biesheuvel Kaaira Gupta Laszlo Ersek Leif Lindholm Liming Gao Ni, Ray Ray Ni Rebecca Cran jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1717 lines long.)
Re: simplify gendisk and request_queue allocation for blk-mq based drivers
On 6/2/21 12:53 AM, Christoph Hellwig wrote: > Hi all, > > this series is the scond part of cleaning up lifetimes and allocation of > the gendisk and request_queue structure. It adds a new interface to > allocate the disk and queue together for blk based drivers, and uses that > in all drivers that do not have any caveats in their gendisk and > request_queue lifetime rules. Applied, thanks. -- Jens Axboe
[xen-unstable bisection] complete test-amd64-i386-examine
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-examine testid reboot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 1a0f2fe2297d122a08fee2b26de5de995fdeca13 Bug not present: 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/162653/ commit 1a0f2fe2297d122a08fee2b26de5de995fdeca13 Author: George Dunlap Date: Thu May 6 13:38:02 2021 +0100 SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported The support status of 32-bit guests doesn't seem particularly useful. With it changed to fully unsupported outside of PV-shim, adjust the PV32 Kconfig default accordingly. Reported-by: Jann Horn Signed-off-by: George Dunlap Signed-off-by: Jan Beulich For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-examine.reboot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-examine.reboot --summary-out=tmp/162653.bisection-summary --basis-template=162533 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-examine reboot Searching for failure / basis pass: 162600 fail [host=huxelrebe1] / 162533 [host=albana1] 162475 [host=elbling0] 162422 [host=chardonnay0] 162385 [host=fiano1] 162343 [host=huxelrebe0] 162337 [host=elbling0] 162330 [host=chardonnay1] 162325 [host=pinot1] 162282 ok. Failure / basis pass flights: 162600 / 162282 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3e09045991cde360432bc7437103f8f8a6699359 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 57f68dfd2d111a2ad381df740543c901b41f2299 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#7ea428895af2840d85c524f0bd11a38\ aac308308-7ea428895af2840d85c524f0bd11a38aac308308 git://xenbits.xen.org/xen.git#57f68dfd2d111a2ad381df740543c901b41f2299-3e09045991cde360432bc7437103f8f8a6699359 Loaded 5001 nodes in revision graph Searching for test results: 162276 [host=elbling1] 162282 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 57f68dfd2d111a2ad381df740543c901b41f2299 162325 [host=pinot1] 162330 [host=chardonnay1] 162337 [host=elbling0] 162343 [host=huxelrebe0] 162385 [host=fiano1] 162422 [host=chardonnay0] 162475 [host=elbling0] 162533 [host=albana1] 162556 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 e4fee66043120c954fc309bbb37813604c1c0eb7 162649 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 1a0f2fe2297d122a08fee2b26de5de995fdeca13 162629 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 57f68dfd2d111a2ad381df740543c901b41f2299 162600 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3e09045991cde360432bc7437103f8f8a6699359 162631 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
[xen-unstable-smoke test] 162647: regressions - FAIL
flight 162647 xen-unstable-smoke real [real] flight 162652 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162647/ http://logs.test-lab.xenproject.org/osstest/logs/162652/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen d2cad41defe4e0e9987549fbc8ebdf9ae138f90f baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z2 days Failing since162584 2021-06-10 00:00:27 Z1 days 11 attempts Testing same since 162642 2021-06-11 10:00:31 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Ian Jackson Jan Beulich Juergen Gross Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit d2cad41defe4e0e9987549fbc8ebdf9ae138f90f Author: Juergen Gross Date: Wed May 12 16:48:32 2021 +0200 tools/libs/store: cleanup libxenstore interface There are some internals in the libxenstore interface which should be removed. Move those functions into xs_lib.c and the related definitions into xs_lib.h. Remove the functions from the mapfile. Add xs_lib.o to xenstore_client as some of the internal functions are needed there. Bump the libxenstore version to 4.0 as the change is incompatible. Note that the removed functions should not result in any problem as they ought to be used by xenstored or xenstore_client only. Avoid an enum as part of a structure as the size of an enum is compiler implementation dependent. Signed-off-by: Juergen Gross Acked-by: Ian Jackson commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a
[OSSTEST PATCH] ts-xen-build: Turn on CONFIG_PV32 again
CC: George Dunlap Suggested-by: Jan Beulich Signed-off-by: Ian Jackson --- ts-xen-build | 4 1 file changed, 4 insertions(+) diff --git a/ts-xen-build b/ts-xen-build index deec52b2..af0dd894 100755 --- a/ts-xen-build +++ b/ts-xen-build @@ -132,6 +132,10 @@ END # on Xen. For now (Xen 4.10/4.11 at at least), # will be not built by default and gated by expert mode echo >>xen/.config CONFIG_HAS_ITS=y + + # PV32 is disabled by default but we still want to test + # it, for now at least until everything is updated. + echo >>xen/.config CONFIG_PV32=y fi END ); -- 2.20.1
[PATCH 5/5] tests: Introduce a TSX test
See the comment at the top of test-tsx.c for details.
This covers various complexities encountered while trying to address the
recent TSX deprecation on client parts.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/tests/Makefile | 1 +
tools/tests/tsx/.gitignore | 1 +
tools/tests/tsx/Makefile | 43
tools/tests/tsx/test-tsx.c | 474 +
4 files changed, 519 insertions(+)
create mode 100644 tools/tests/tsx/.gitignore
create mode 100644 tools/tests/tsx/Makefile
create mode 100644 tools/tests/tsx/test-tsx.c
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 8746aabe6b..25531a984a 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -5,6 +5,7 @@ SUBDIRS-y :=
SUBDIRS-y += resource
SUBDIRS-$(CONFIG_X86) += cpu-policy
SUBDIRS-$(CONFIG_X86) += mce-test
+SUBDIRS-$(CONFIG_X86) += tsx
ifneq ($(clang),y)
SUBDIRS-$(CONFIG_X86) += x86_emulator
endif
diff --git a/tools/tests/tsx/.gitignore b/tools/tests/tsx/.gitignore
new file mode 100644
index 00..97ec4db7ff
--- /dev/null
+++ b/tools/tests/tsx/.gitignore
@@ -0,0 +1 @@
+test-tsx
diff --git a/tools/tests/tsx/Makefile b/tools/tests/tsx/Makefile
new file mode 100644
index 00..7381a4f5a4
--- /dev/null
+++ b/tools/tests/tsx/Makefile
@@ -0,0 +1,43 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+TARGET := test-tsx
+
+.PHONY: all
+all: $(TARGET)
+
+.PHONY: run
+run: $(TARGET)
+ ./$(TARGET)
+
+.PHONY: clean
+clean:
+ $(RM) -f -- *.o $(TARGET) $(DEPS_RM)
+
+.PHONY: distclean
+distclean: clean
+ $(RM) -f -- *~
+
+.PHONY: install
+install: all
+
+.PHONY: uninstall
+uninstall:
+
+CFLAGS += -Werror -std=gnu11
+CFLAGS += $(CFLAGS_xeninclude)
+CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenguest)
+CFLAGS += -I$(XEN_ROOT)/tools/libs/ctrl -I$(XEN_ROOT)/tools/libs/guest
+CFLAGS += $(APPEND_CFLAGS)
+
+LDFLAGS += $(LDLIBS_libxenctrl)
+LDFLAGS += $(LDLIBS_libxenguest)
+LDFLAGS += $(APPEND_LDFLAGS)
+
+test-tsx.o: Makefile
+
+test-tsx: test-tsx.o
+ $(CC) -o $@ $< $(LDFLAGS)
+
+-include $(DEPS_INCLUDE)
diff --git a/tools/tests/tsx/test-tsx.c b/tools/tests/tsx/test-tsx.c
new file mode 100644
index 00..2bf22cea81
--- /dev/null
+++ b/tools/tests/tsx/test-tsx.c
@@ -0,0 +1,474 @@
+/*
+ * TSX settings and consistency tests
+ *
+ * This tests various behaviours and invariants with regards to TSX. It
+ * ideally wants running for several microcode versions, and all applicable
+ * tsx= commandline settings, on a single CPU, including after an S3
+ * suspend/resume event.
+ *
+ * It tests specifically:
+ * - The consistency of MSR_TSX_CTRL/MSR_TSX_FORCE_ABORT values across the
+ *system, and their accessibility WRT data in the host CPU policy.
+ * - The actual behaviour of RTM on the system.
+ *
+ * -
+ */
+
+#define _GNU_SOURCE
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "xg_private.h"
+
+enum {
+#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
+#include
+};
+#define bitmaskof(idx) (1u << ((idx) & 31))
+
+#define MSR_ARCH_CAPABILITIES 0x010a
+#define ARCH_CAPS_TSX_CTRL (1 << 7)
+#define MSR_TSX_FORCE_ABORT 0x010f
+#define MSR_TSX_CTRL0x0122
+
+static unsigned int nr_failures;
+#define fail(fmt, ...) \
+({ \
+nr_failures++; \
+(void)printf(fmt, ##__VA_ARGS__); \
+})
+
+static xc_interface *xch;
+
+/*
+ * Policies, arranged as an array for easy collection of all of them. We
+ * don't care about the raw policy (index 0) so reuse that for the guest
+ * policy.
+ */
+static struct xc_cpu_policy policies[6];
+#define guest_policy policies[0]
+#define host policies[XEN_SYSCTL_cpu_policy_host]
+#define pv_max policies[XEN_SYSCTL_cpu_policy_pv_max]
+#define hvm_max policies[XEN_SYSCTL_cpu_policy_hvm_max]
+#define pv_default policies[XEN_SYSCTL_cpu_policy_pv_default]
+#define hvm_default policies[XEN_SYSCTL_cpu_policy_hvm_default]
+
+static bool xen_has_pv = true, xen_has_hvm = true;
+
+static unsigned int nr_cpus;
+static enum rtm_behaviour {
+RTM_UD,
+RTM_OK,
+RTM_ABORT,
+} rtm_behaviour;
+
+/*
+ * Test a specific TSX MSR for consistency across the system, taking into
+ * account whether it ought to be accessable or not.
+ *
+ * We can't query offline CPUs, so skip those if encountered. We don't care
+ * particularly for the exact MSR value, but we do care that it is the same
+ * everywhere.
+ */
+static void test_tsx_msr_consistency(unsigned int msr, bool accessable)
+{
+uint64_t cpu0_val = ~0;
+
+for ( unsigned int cpu = 0; cpu < nr_cpus; ++cpu )
+{
+xc_resource_entry_t ent = {
+.u.cmd =
[PATCH 4/5] libs/guest: Move struct xc_cpu_policy into xg_private.h
... so tests can peek at the internals, without the structure being generally
available to users of the library.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/libs/guest/xg_cpuid_x86.c | 11 +--
tools/libs/guest/xg_private.h | 9 +
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
index ec5a47fde4..e01d657e03 100644
--- a/tools/libs/guest/xg_cpuid_x86.c
+++ b/tools/libs/guest/xg_cpuid_x86.c
@@ -22,7 +22,7 @@
#include
#include
#include
-#include "xc_private.h"
+#include "xg_private.h"
#include "xc_bitops.h"
#include
#include
@@ -34,18 +34,9 @@ enum {
#include
-#include
-
#define bitmaskof(idx) (1u << ((idx) & 31))
#define featureword_of(idx) ((idx) >> 5)
-struct xc_cpu_policy {
-struct cpuid_policy cpuid;
-struct msr_policy msr;
-xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES];
-xen_msr_entry_t entries[MSR_MAX_SERIALISED_ENTRIES];
-};
-
int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps)
{
DECLARE_SYSCTL;
diff --git a/tools/libs/guest/xg_private.h b/tools/libs/guest/xg_private.h
index 03d765da21..59909d2a2c 100644
--- a/tools/libs/guest/xg_private.h
+++ b/tools/libs/guest/xg_private.h
@@ -33,6 +33,8 @@
#include
#include
+#include
+
#ifndef ELFSIZE
#include
#if UINT_MAX == ULONG_MAX
@@ -168,4 +170,11 @@ int pin_table(xc_interface *xch, unsigned int type,
unsigned long mfn,
#define M2P_SIZE(_m)ROUNDUP(((_m) * sizeof(xen_pfn_t)), M2P_SHIFT)
#define M2P_CHUNKS(_m) (M2P_SIZE((_m)) >> M2P_SHIFT)
+struct xc_cpu_policy {
+struct cpuid_policy cpuid;
+struct msr_policy msr;
+xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES];
+xen_msr_entry_t entries[MSR_MAX_SERIALISED_ENTRIES];
+};
+
#endif /* XG_PRIVATE_H */
--
2.11.0
[PATCH 1/5] x86/platform: Improve MSR permission handling for XENPF_resource_op
The logic to disallow writes to the TSC is out-of-place, and should be in
check_resource_access() rather than in resource_access().
Split the existing allow_access_msr() into two - msr_{read,write}_allowed() -
and move all permissions checks here.
Furthermore, guard access to MSR_IA32_CMT_{EVTSEL,CTR} to prohibit their use
on hardware which is lacking the QoS Monitoring feature. Introduce
cpu_has_pqe to help with the logic.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/platform_hypercall.c | 41 ---
xen/arch/x86/psr.c| 2 +-
xen/include/asm-x86/cpufeature.h | 1 +
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/platform_hypercall.c
b/xen/arch/x86/platform_hypercall.c
index 23fadbc782..41d8e59563 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -64,17 +64,33 @@ long cpu_frequency_change_helper(void *data)
return cpu_frequency_change((uint64_t)data);
}
-static bool allow_access_msr(unsigned int msr)
+static bool msr_read_allowed(unsigned int msr)
{
switch ( msr )
{
-/* MSR for CMT, refer to chapter 17.14 of Intel SDM. */
case MSR_IA32_CMT_EVTSEL:
case MSR_IA32_CMT_CTR:
+return cpu_has_pqe;
+
case MSR_IA32_TSC:
return true;
}
+if ( ppin_msr && msr == ppin_msr )
+return true;
+
+return false;
+}
+
+static bool msr_write_allowed(unsigned int msr)
+{
+switch ( msr )
+{
+case MSR_IA32_CMT_EVTSEL:
+case MSR_IA32_CMT_CTR:
+return cpu_has_pqe;
+}
+
return false;
}
@@ -96,15 +112,19 @@ void check_resource_access(struct resource_access *ra)
switch ( entry->u.cmd )
{
case XEN_RESOURCE_OP_MSR_READ:
-if ( ppin_msr && entry->idx == ppin_msr )
-break;
-/* fall through */
+if ( entry->idx >> 32 )
+ret = -EINVAL;
+else if ( !msr_read_allowed(entry->idx) )
+ret = -EPERM;
+break;
+
case XEN_RESOURCE_OP_MSR_WRITE:
if ( entry->idx >> 32 )
ret = -EINVAL;
-else if ( !allow_access_msr(entry->idx) )
-ret = -EACCES;
+else if ( !msr_write_allowed(entry->idx) )
+ret = -EPERM;
break;
+
default:
ret = -EOPNOTSUPP;
break;
@@ -163,12 +183,11 @@ void resource_access(void *info)
}
}
break;
+
case XEN_RESOURCE_OP_MSR_WRITE:
-if ( unlikely(entry->idx == MSR_IA32_TSC) )
-ret = -EPERM;
-else
-ret = wrmsr_safe(entry->idx, entry->val);
+ret = wrmsr_safe(entry->idx, entry->val);
break;
+
default:
BUG();
break;
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index d7f8864651..d805b85dc6 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -1558,7 +1558,7 @@ static void psr_cpu_init(void)
struct cpuid_leaf regs;
uint32_t feat_mask;
-if ( !psr_alloc_feat_enabled() || !boot_cpu_has(X86_FEATURE_PQE) )
+if ( !psr_alloc_feat_enabled() || !cpu_has_pqe )
goto assoc_init;
if ( boot_cpu_data.cpuid_level < PSR_CPUID_LEVEL_CAT )
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index a539a4bacd..5f6b83f71c 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -94,6 +94,7 @@
#define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
#define cpu_has_invpcid boot_cpu_has(X86_FEATURE_INVPCID)
#define cpu_has_rtm boot_cpu_has(X86_FEATURE_RTM)
+#define cpu_has_pqe boot_cpu_has(X86_FEATURE_PQE)
#define cpu_has_fpu_sel (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
#define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
#define cpu_has_avx512f boot_cpu_has(X86_FEATURE_AVX512F)
--
2.11.0
[PATCH 2/5] x86/platform: Permit reading the TSX control MSRs via XENPF_resource_op
We are going to want this to write some tests with. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/arch/x86/platform_hypercall.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 41d8e59563..284c2dfb9e 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -74,6 +74,12 @@ static bool msr_read_allowed(unsigned int msr) case MSR_IA32_TSC: return true; + +case MSR_TSX_FORCE_ABORT: +return cpu_has_tsx_force_abort; + +case MSR_TSX_CTRL: +return cpu_has_tsx_ctrl; } if ( ppin_msr && msr == ppin_msr ) -- 2.11.0
[PATCH 0/5] x86/tsx: Consistency and settings test
See patch 5 for details. Andrew Cooper (5): x86/platform: Improve MSR permission handling for XENPF_resource_op x86/platform: Permit reading the TSX control MSRs via XENPF_resource_op x86/msr: Expose MSR_ARCH_CAPS in the raw and host policies libs/guest: Move struct xc_cpu_policy into xg_private.h tests: Introduce a TSX test tools/libs/guest/xg_cpuid_x86.c | 11 +- tools/libs/guest/xg_private.h | 9 + tools/tests/Makefile | 1 + tools/tests/tsx/.gitignore| 1 + tools/tests/tsx/Makefile | 43 tools/tests/tsx/test-tsx.c| 474 ++ xen/arch/x86/msr.c| 14 ++ xen/arch/x86/platform_hypercall.c | 47 +++- xen/arch/x86/psr.c| 2 +- xen/include/asm-x86/cpufeature.h | 1 + 10 files changed, 581 insertions(+), 22 deletions(-) create mode 100644 tools/tests/tsx/.gitignore create mode 100644 tools/tests/tsx/Makefile create mode 100644 tools/tests/tsx/test-tsx.c -- 2.11.0
[PATCH 3/5] x86/msr: Expose MSR_ARCH_CAPS in the raw and host policies
MSR_ARCH_CAPS is still not supported for guests (other than the hardware
domain) yet, until the toolstack learns how to construct an MSR policy.
However, we want access to the host ARCH_CAPS_TSX_CTRL value in particular for
testing purposes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/msr.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 374f92b2c5..6dbb4744e7 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -47,8 +47,13 @@ struct msr_policy __read_mostly hvm_def_msr_policy;
static void __init calculate_raw_policy(void)
{
+struct msr_policy *mp = _msr_policy;
+
/* 0x00ce MSR_INTEL_PLATFORM_INFO */
/* Was already added by probe_cpuid_faulting() */
+
+if ( cpu_has_arch_caps )
+rdmsrl(MSR_ARCH_CAPABILITIES, mp->arch_caps.raw);
}
static void __init calculate_host_policy(void)
@@ -60,6 +65,11 @@ static void __init calculate_host_policy(void)
/* 0x00ce MSR_INTEL_PLATFORM_INFO */
/* probe_cpuid_faulting() sanity checks presence of MISC_FEATURES_ENABLES
*/
mp->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
+
+mp->arch_caps.raw &=
+(ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA |
+ ARCH_CAPS_SKIP_L1DFL | ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO |
+ ARCH_CAPS_IF_PSCHANGE_MC_NO | ARCH_CAPS_TSX_CTRL | ARCH_CAPS_TAA_NO);
}
static void __init calculate_pv_max_policy(void)
@@ -67,6 +77,8 @@ static void __init calculate_pv_max_policy(void)
struct msr_policy *mp = _max_msr_policy;
*mp = host_msr_policy;
+
+mp->arch_caps.raw = 0; /* Not supported yet. */
}
static void __init calculate_pv_def_policy(void)
@@ -84,6 +96,8 @@ static void __init calculate_hvm_max_policy(void)
/* It's always possible to emulate CPUID faulting for HVM guests */
mp->platform_info.cpuid_faulting = true;
+
+mp->arch_caps.raw = 0; /* Not supported yet. */
}
static void __init calculate_hvm_def_policy(void)
--
2.11.0
Re: [PATCH v9 06/14] swiotlb: Update is_swiotlb_active to add a struct device argument
I don't have the HW to verify the change. Hopefully I use the right device struct for is_swiotlb_active.
Re: [PATCH v8 00/15] Restricted DMA
v9 here: https://lore.kernel.org/patchwork/cover/1445081/ On Mon, Jun 7, 2021 at 11:28 AM Claire Chang wrote: > > On Sat, Jun 5, 2021 at 1:48 AM Will Deacon wrote: > > > > Hi Claire, > > > > On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote: > > > This series implements mitigations for lack of DMA access control on > > > systems without an IOMMU, which could result in the DMA accessing the > > > system memory at unexpected times and/or unexpected addresses, possibly > > > leading to data leakage or corruption. > > > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > > > not behind an IOMMU. As PCI-e, by design, gives the device full access to > > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > > > full chain of exploits; [2], [3]). > > > > > > To mitigate the security concerns, we introduce restricted DMA. Restricted > > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > > > specially allocated region and does memory allocation from the same > > > region. > > > The feature on its own provides a basic level of protection against the > > > DMA > > > overwriting buffer contents at unexpected times. However, to protect > > > against general data leakage and system memory corruption, the system > > > needs > > > to provide a way to restrict the DMA to a predefined memory region (this > > > is > > > usually done at firmware level, e.g. MPU in ATF on some ARM platforms > > > [4]). > > > > > > [1a] > > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > > > [1b] > > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > > > [2] https://blade.tencent.com/en/advisories/qualpwn/ > > > [3] > > > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > > > [4] > > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > > > > > v8: > > > - Fix reserved-memory.txt and add the reg property in example. > > > - Fix sizeof for of_property_count_elems_of_size in > > > drivers/of/address.c#of_dma_set_restricted_buffer. > > > - Apply Will's suggestion to try the OF node having DMA configuration in > > > drivers/of/address.c#of_dma_set_restricted_buffer. > > > - Fix typo in the comment of > > > drivers/of/address.c#of_dma_set_restricted_buffer. > > > - Add error message for PageHighMem in > > > kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to > > > rmem_swiotlb_setup. > > > - Fix the message string in rmem_swiotlb_setup. > > > > Thanks for the v8. It works for me out of the box on arm64 under KVM, so: > > > > Tested-by: Will Deacon > > > > Note that something seems to have gone wrong with the mail threading, so > > the last 5 patches ended up as a separate thread for me. Probably worth > > posting again with all the patches in one place, if you can. > > Thanks for testing. > > Christoph also added some comments in v7, so I'll prepare v9. > > > > > Cheers, > > > > Will
Re: [PATCH v9 03/14] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
I'm not sure if this would break arch/x86/pci/sta2x11-fixup.c
swiotlb_late_init_with_default_size is called here
https://elixir.bootlin.com/linux/v5.13-rc5/source/arch/x86/pci/sta2x11-fixup.c#L60
On Fri, Jun 11, 2021 at 11:27 PM Claire Chang wrote:
>
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
>
> Signed-off-by: Claire Chang
> ---
> drivers/of/device.c | 3 +++
> include/linux/device.h | 4
> include/linux/swiotlb.h | 8
> kernel/dma/swiotlb.c| 8
> 4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index c5a9473a5fb1..1defdf15ba95 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -165,6 +165,9 @@ int of_dma_configure_id(struct device *dev, struct
> device_node *np,
>
> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>
> + if (IS_ENABLED(CONFIG_SWIOTLB))
> + swiotlb_set_io_tlb_default_mem(dev);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_dma_configure_id);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4443e12238a0..2e9a378c9100 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -432,6 +432,7 @@ struct dev_links_info {
> * @dma_pools: Dma pools (if dma'ble device).
> * @dma_mem: Internal for coherent mem override.
> * @cma_area: Contiguous memory area for dma allocations
> + * @dma_io_tlb_mem: Pointer to the swiotlb pool used. Not for driver use.
> * @archdata: For arch-specific additions.
> * @of_node: Associated device tree node.
> * @fwnode:Associated device node supplied by platform firmware.
> @@ -540,6 +541,9 @@ struct device {
> #ifdef CONFIG_DMA_CMA
> struct cma *cma_area; /* contiguous memory area for dma
>allocations */
> +#endif
> +#ifdef CONFIG_SWIOTLB
> + struct io_tlb_mem *dma_io_tlb_mem;
> #endif
> /* arch specific additions */
> struct dev_archdata archdata;
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 216854a5e513..008125ccd509 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -108,6 +108,11 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
> return mem && paddr >= mem->start && paddr < mem->end;
> }
>
> +static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
> +{
> + dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
> void __init swiotlb_exit(void);
> unsigned int swiotlb_max_segment(void);
> size_t swiotlb_max_mapping_size(struct device *dev);
> @@ -119,6 +124,9 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
> {
> return false;
> }
> +static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
> +{
> +}
> static inline void swiotlb_exit(void)
> {
> }
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 8a3e2b3b246d..29b950ab1351 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -344,7 +344,7 @@ void __init swiotlb_exit(void)
> static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t
> size,
>enum dma_data_direction dir)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
> phys_addr_t orig_addr = mem->slots[index].orig_addr;
> size_t alloc_size = mem->slots[index].alloc_size;
> @@ -426,7 +426,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem,
> unsigned int index)
> static int find_slots(struct device *dev, phys_addr_t orig_addr,
> size_t alloc_size)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned long boundary_mask = dma_get_seg_boundary(dev);
> dma_addr_t tbl_dma_addr =
> phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
> @@ -503,7 +503,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
> phys_addr_t orig_addr,
> size_t mapping_size, size_t alloc_size,
> enum dma_data_direction dir, unsigned long attrs)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned int offset = swiotlb_align_offset(dev, orig_addr);
> unsigned int i;
> int index;
> @@ -554,7 +554,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
> phys_addr_t tlb_addr,
> size_t mapping_size, enum dma_data_direction
> dir,
> unsigned long attrs)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
> unsigned long flags;
> unsigned int offset =
[PATCH v9 09/14] swiotlb: Refactor swiotlb_tbl_unmap_single
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 364c6c822063..a6562573f090 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -554,27 +554,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
return tlb_addr;
}
-/*
- * tlb_addr is the physical address of the bounce buffer to unmap.
- */
-void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
- size_t mapping_size, enum dma_data_direction dir,
- unsigned long attrs)
+static void release_slots(struct device *dev, phys_addr_t tlb_addr)
{
- struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long flags;
- unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
+ unsigned int offset = swiotlb_align_offset(dev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
int nslots = nr_slots(mem->slots[index].alloc_size + offset);
int count, i;
- /*
-* First, sync the memory before unmapping the entry
-*/
- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(hwdev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
-
/*
* Return the buffer to the free list by setting the corresponding
* entries to indicate the number of contiguous entries available.
@@ -609,6 +597,23 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
spin_unlock_irqrestore(>lock, flags);
}
+/*
+ * tlb_addr is the physical address of the bounce buffer to unmap.
+ */
+void swiotlb_tbl_unmap_single(struct device *dev, phys_addr_t tlb_addr,
+ size_t mapping_size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ /*
+* First, sync the memory before unmapping the entry
+*/
+ if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+ (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
+ swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
+
+ release_slots(dev, tlb_addr);
+}
+
void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
size_t size, enum dma_data_direction dir)
{
--
2.32.0.272.g935e593368-goog
[PATCH v9 10/14] dma-direct: Add a new wrapper __dma_direct_free_pages()
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 078f7087e466..eb4098323bbc 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -75,6 +75,12 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
}
+static void __dma_direct_free_pages(struct device *dev, struct page *page,
+ size_t size)
+{
+ dma_free_contiguous(dev, page, size);
+}
+
static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp_t gfp)
{
@@ -237,7 +243,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return NULL;
}
out_free_pages:
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
return NULL;
}
@@ -273,7 +279,7 @@ void dma_direct_free(struct device *dev, size_t size,
else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
- dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
+ __dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);
}
struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
@@ -310,7 +316,7 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
return page;
out_free_pages:
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
return NULL;
}
@@ -329,7 +335,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
if (force_dma_unencrypted(dev))
set_memory_encrypted((unsigned long)vaddr, 1 << page_order);
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
}
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
--
2.32.0.272.g935e593368-goog
[PATCH v9 11/14] swiotlb: Add restricted DMA alloc/free support.
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 15 +++
kernel/dma/swiotlb.c| 35 +--
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8200c100fe10..d3374497a4f8 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -162,4 +162,19 @@ static inline void swiotlb_adjust_size(unsigned long size)
extern void swiotlb_print_info(void);
extern void swiotlb_set_max_segment(unsigned int);
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+struct page *swiotlb_alloc(struct device *dev, size_t size);
+bool swiotlb_free(struct device *dev, struct page *page, size_t size);
+#else
+static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
+{
+ return NULL;
+}
+static inline bool swiotlb_free(struct device *dev, struct page *page,
+ size_t size)
+{
+ return false;
+}
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
+
#endif /* __LINUX_SWIOTLB_H */
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index a6562573f090..0a19858da5b8 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -461,8 +461,9 @@ static int find_slots(struct device *dev, phys_addr_t
orig_addr,
index = wrap = wrap_index(mem, ALIGN(mem->index, stride));
do {
- if ((slot_addr(tbl_dma_addr, index) & iotlb_align_mask) !=
- (orig_addr & iotlb_align_mask)) {
+ if (orig_addr &&
+ (slot_addr(tbl_dma_addr, index) & iotlb_align_mask) !=
+ (orig_addr & iotlb_align_mask)) {
index = wrap_index(mem, index + 1);
continue;
}
@@ -702,6 +703,36 @@ late_initcall(swiotlb_create_default_debugfs);
#endif
#ifdef CONFIG_DMA_RESTRICTED_POOL
+struct page *swiotlb_alloc(struct device *dev, size_t size)
+{
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ phys_addr_t tlb_addr;
+ int index;
+
+ if (!mem)
+ return NULL;
+
+ index = find_slots(dev, 0, size);
+ if (index == -1)
+ return NULL;
+
+ tlb_addr = slot_addr(mem->start, index);
+
+ return pfn_to_page(PFN_DOWN(tlb_addr));
+}
+
+bool swiotlb_free(struct device *dev, struct page *page, size_t size)
+{
+ phys_addr_t tlb_addr = page_to_phys(page);
+
+ if (!is_swiotlb_buffer(dev, tlb_addr))
+ return false;
+
+ release_slots(dev, tlb_addr);
+
+ return true;
+}
+
static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
struct device *dev)
{
--
2.32.0.272.g935e593368-goog
[PATCH v9 13/14] dt-bindings: of: Add restricted DMA pool
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36 +--
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index e8d3096d922c..46804f24df05 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -51,6 +51,23 @@ compatible (optional) - standard definition
used as a shared pool of DMA buffers for a set of devices. It can
be used by an operating system to instantiate the necessary pool
management subsystem if necessary.
+- restricted-dma-pool: This indicates a region of memory meant to be
+ used as a pool of restricted DMA buffers for a set of devices. The
+ memory region would be the only region accessible to those devices.
+ When using this, the no-map and reusable properties must not be set,
+ so the operating system can create a virtual mapping that will be
used
+ for synchronization. The main purpose for restricted DMA is to
+ mitigate the lack of DMA access control on systems without an IOMMU,
+ which could result in the DMA accessing the system memory at
+ unexpected times and/or unexpected addresses, possibly leading to
data
+ leakage or corruption. The feature on its own provides a basic level
+ of protection against the DMA overwriting buffer contents at
+ unexpected times. However, to protect against general data leakage
and
+ system memory corruption, the system needs to provide way to lock
down
+ the memory access, e.g., MPU. Note that since coherent allocation
+ needs remapping, one must set up another device coherent pool by
+ shared-dma-pool and use dma_alloc_from_dev_coherent instead for
atomic
+ coherent allocation.
- vendor specific string in the form ,[-]
no-map (optional) - empty property
- Indicates the operating system must not create a virtual mapping
@@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one for
each corresponding
Example
---
-This example defines 3 contiguous regions are defined for Linux kernel:
+This example defines 4 contiguous regions for Linux kernel:
one default of all device drivers (named linux,cma@7200 and 64MiB in size),
-one dedicated to the framebuffer device (named framebuffer@7800, 8MiB), and
-one for multimedia processing (named multimedia-memory@7700, 64MiB).
+one dedicated to the framebuffer device (named framebuffer@7800, 8MiB),
+one for multimedia processing (named multimedia-memory@7700, 64MiB), and
+one for restricted dma pool (named restricted_dma_reserved@0x5000, 64MiB).
/ {
#address-cells = <1>;
@@ -120,6 +138,11 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
compatible = "acme,multimedia-memory";
reg = <0x7700 0x400>;
};
+
+ restricted_dma_reserved: restricted_dma_reserved {
+ compatible = "restricted-dma-pool";
+ reg = <0x5000 0x400>;
+ };
};
/* ... */
@@ -138,4 +161,11 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
memory-region = <_reserved>;
/* ... */
};
+
+ pcie_device: pcie_device@0,0 {
+ reg = <0x8301 0x0 0x 0x0 0x0010
+ 0x8301 0x0 0x0010 0x0 0x0010>;
+ memory-region = <_dma_mem_reserved>;
+ /* ... */
+ };
};
--
2.32.0.272.g935e593368-goog
[PATCH v9 14/14] of: Add plumbing for restricted DMA pool
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 3b2acca7e363..c8066d95ff0e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1001,6 +1002,38 @@ int of_dma_get_range(struct device_node *np, const
struct bus_dma_region **map)
of_node_put(node);
return ret;
}
+
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
+{
+ struct device_node *node, *of_node = dev->of_node;
+ int count, i;
+
+ count = of_property_count_elems_of_size(of_node, "memory-region",
+ sizeof(u32));
+ /*
+* If dev->of_node doesn't exist or doesn't contain memory-region, try
+* the OF node having DMA configuration.
+*/
+ if (count <= 0) {
+ of_node = np;
+ count = of_property_count_elems_of_size(
+ of_node, "memory-region", sizeof(u32));
+ }
+
+ for (i = 0; i < count; i++) {
+ node = of_parse_phandle(of_node, "memory-region", i);
+ /*
+* There might be multiple memory regions, but only one
+* restricted-dma-pool region is allowed.
+*/
+ if (of_device_is_compatible(node, "restricted-dma-pool") &&
+ of_device_is_available(node))
+ return of_reserved_mem_device_init_by_idx(dev, of_node,
+ i);
+ }
+
+ return 0;
+}
#endif /* CONFIG_HAS_DMA */
/**
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1defdf15ba95..ba4656e77502 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -168,6 +168,9 @@ int of_dma_configure_id(struct device *dev, struct
device_node *np,
if (IS_ENABLED(CONFIG_SWIOTLB))
swiotlb_set_io_tlb_default_mem(dev);
+ if (!iommu)
+ return of_dma_set_restricted_buffer(dev, np);
+
return 0;
}
EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 631489f7f8c0..376462798f7e 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -163,12 +163,18 @@ struct bus_dma_region;
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np);
#else
static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
{
return -ENODEV;
}
+static inline int of_dma_set_restricted_buffer(struct device *dev,
+ struct device_node *np)
+{
+ return -ENODEV;
+}
#endif
void fdt_init_reserved_mem(void);
--
2.32.0.272.g935e593368-goog
[PATCH v9 12/14] dma-direct: Allocate memory from restricted DMA pool if available
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
dma_alloc_from_dev_coherent instead for atomic coherent allocation.
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index eb4098323bbc..73fc4c659ba7 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -78,6 +78,9 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
static void __dma_direct_free_pages(struct device *dev, struct page *page,
size_t size)
{
+ if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL) &&
+ swiotlb_free(dev, page, size))
+ return;
dma_free_contiguous(dev, page, size);
}
@@ -92,7 +95,17 @@ static struct page *__dma_direct_alloc_pages(struct device
*dev, size_t size,
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
_limit);
- page = dma_alloc_contiguous(dev, size, gfp);
+ if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL)) {
+ page = swiotlb_alloc(dev, size);
+ if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
+ __dma_direct_free_pages(dev, page, size);
+ page = NULL;
+ }
+ return page;
+ }
+
+ if (!page)
+ page = dma_alloc_contiguous(dev, size, gfp);
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, size);
page = NULL;
@@ -148,7 +161,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
gfp |= __GFP_NOWARN;
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev)) {
+ !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
@@ -161,18 +174,23 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !dev_is_dma_coherent(dev))
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+ !is_dev_swiotlb_force(dev))
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
/*
* Remapping or decrypting memory may block. If either is required and
* we can't block, allocate the memory from the atomic pools.
+* If restricted DMA (i.e., is_dev_swiotlb_force) is required, one must
+* set up another device coherent pool by shared-dma-pool and use
+* dma_alloc_from_dev_coherent instead.
*/
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
!gfpflags_allow_blocking(gfp) &&
(force_dma_unencrypted(dev) ||
-(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
!dev_is_dma_coherent(dev
+(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
+ !dev_is_dma_coherent(dev))) &&
+ !is_dev_swiotlb_force(dev))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
/* we always manually zero the memory once we are done */
@@ -253,15 +271,15 @@ void dma_direct_free(struct device *dev, size_t size,
unsigned int page_order = get_order(size);
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev)) {
+ !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
/* cpu_addr is a struct page cookie, not a kernel address */
dma_free_contiguous(dev, cpu_addr, size);
return;
}
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !dev_is_dma_coherent(dev)) {
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+ !is_dev_swiotlb_force(dev)) {
arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
return;
}
@@ -289,7 +307,8 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void *ret;
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
- force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp))
+ force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp) &&
+
[PATCH v9 08/14] swiotlb: Move alloc_size to find_slots
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e5ccc198d0a7..364c6c822063 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -486,8 +486,11 @@ static int find_slots(struct device *dev, phys_addr_t
orig_addr,
return -1;
found:
- for (i = index; i < index + nslots; i++)
+ for (i = index; i < index + nslots; i++) {
mem->slots[i].list = 0;
+ mem->slots[i].alloc_size =
+ alloc_size - ((i - index) << IO_TLB_SHIFT);
+ }
for (i = index - 1;
io_tlb_offset(i) != IO_TLB_SEGSIZE - 1 &&
mem->slots[i].list; i--)
@@ -542,11 +545,8 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
* This is needed when we sync the memory. Then we sync the buffer if
* needed.
*/
- for (i = 0; i < nr_slots(alloc_size + offset); i++) {
+ for (i = 0; i < nr_slots(alloc_size + offset); i++)
mem->slots[index + i].orig_addr = slot_addr(orig_addr, i);
- mem->slots[index + i].alloc_size =
- alloc_size - (i << IO_TLB_SHIFT);
- }
tlb_addr = slot_addr(mem->start, index) + offset;
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
--
2.32.0.272.g935e593368-goog
[PATCH v9 07/14] swiotlb: Bounce data from/to restricted DMA pool if available
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.
Note that is_dev_swiotlb_force doesn't check if
swiotlb_force == SWIOTLB_FORCE. Otherwise the memory allocation behavior
with default swiotlb will be changed by the following patche
("dma-direct: Allocate memory from restricted DMA pool if available").
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 10 +-
kernel/dma/direct.c | 3 ++-
kernel/dma/direct.h | 3 ++-
kernel/dma/swiotlb.c| 1 +
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 06cf17a80f5c..8200c100fe10 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -85,6 +85,7 @@ extern enum swiotlb_force swiotlb_force;
* unmap calls.
* @debugfs: The dentry to debugfs.
* @late_alloc:%true if allocated using the page allocator
+ * @force_swiotlb: %true if swiotlb is forced
*/
struct io_tlb_mem {
phys_addr_t start;
@@ -95,6 +96,7 @@ struct io_tlb_mem {
spinlock_t lock;
struct dentry *debugfs;
bool late_alloc;
+ bool force_swiotlb;
struct io_tlb_slot {
phys_addr_t orig_addr;
size_t alloc_size;
@@ -115,6 +117,11 @@ static inline void swiotlb_set_io_tlb_default_mem(struct
device *dev)
dev->dma_io_tlb_mem = io_tlb_default_mem;
}
+static inline bool is_dev_swiotlb_force(struct device *dev)
+{
+ return dev->dma_io_tlb_mem->force_swiotlb;
+}
+
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
@@ -126,8 +133,9 @@ static inline bool is_swiotlb_buffer(struct device *dev,
phys_addr_t paddr)
{
return false;
}
-static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+static inline bool is_dev_swiotlb_force(struct device *dev)
{
+ return false;
}
static inline void swiotlb_exit(void)
{
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 7a88c34d0867..078f7087e466 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -496,7 +496,8 @@ size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
if (is_swiotlb_active(dev) &&
- (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
+ (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE ||
+is_dev_swiotlb_force(dev)))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
}
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index 13e9e7158d94..f94813674e23 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -87,7 +87,8 @@ static inline dma_addr_t dma_direct_map_page(struct device
*dev,
phys_addr_t phys = page_to_phys(page) + offset;
dma_addr_t dma_addr = phys_to_dma(dev, phys);
- if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ if (unlikely(swiotlb_force == SWIOTLB_FORCE) ||
+ is_dev_swiotlb_force(dev))
return swiotlb_map(dev, phys, size, dir, attrs);
if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 21e99907edd6..e5ccc198d0a7 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -714,6 +714,7 @@ static int rmem_swiotlb_device_init(struct reserved_mem
*rmem,
return -ENOMEM;
swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false, true);
+ mem->force_swiotlb = true;
rmem->priv = mem;
--
2.32.0.272.g935e593368-goog
[PATCH v9 06/14] swiotlb: Update is_swiotlb_active to add a struct device argument
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c | 2 +-
include/linux/swiotlb.h | 4 ++--
kernel/dma/direct.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..89a894354263 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -42,7 +42,7 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (is_swiotlb_active()) {
+ if (is_swiotlb_active(obj->base.dev->dev)) {
unsigned int max_segment;
max_segment = swiotlb_max_segment();
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index f4c2e46b6fe1..2ca9d9a9e5d5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -276,7 +276,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
}
#if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
- need_swiotlb = is_swiotlb_active();
+ need_swiotlb = is_swiotlb_active(dev->dev);
#endif
ret = ttm_device_init(>ttm.bdev, _bo_driver, drm->dev->dev,
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b7a8f3a1921f..0d56985bfe81 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -693,7 +693,7 @@ static int pcifront_connect_and_init_dma(struct
pcifront_device *pdev)
spin_unlock(_dev_lock);
- if (!err && !is_swiotlb_active()) {
+ if (!err && !is_swiotlb_active(>xdev->dev)) {
err = pci_xen_swiotlb_init_late();
if (err)
dev_err(>xdev->dev, "Could not setup SWIOTLB!\n");
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 921b469c6ad2..06cf17a80f5c 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -118,7 +118,7 @@ static inline void swiotlb_set_io_tlb_default_mem(struct
device *dev)
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
-bool is_swiotlb_active(void);
+bool is_swiotlb_active(struct device *dev);
void __init swiotlb_adjust_size(unsigned long size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
@@ -141,7 +141,7 @@ static inline size_t swiotlb_max_mapping_size(struct device
*dev)
return SIZE_MAX;
}
-static inline bool is_swiotlb_active(void)
+static inline bool is_swiotlb_active(struct device *dev)
{
return false;
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 84c9feb5474a..7a88c34d0867 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -495,7 +495,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
- if (is_swiotlb_active() &&
+ if (is_swiotlb_active(dev) &&
(dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c4a071d6a63f..21e99907edd6 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -666,9 +666,9 @@ size_t swiotlb_max_mapping_size(struct device *dev)
return ((size_t)IO_TLB_SIZE) * IO_TLB_SEGSIZE;
}
-bool is_swiotlb_active(void)
+bool is_swiotlb_active(struct device *dev)
{
- return io_tlb_default_mem != NULL;
+ return dev->dma_io_tlb_mem != NULL;
}
EXPORT_SYMBOL_GPL(is_swiotlb_active);
--
2.32.0.272.g935e593368-goog
[PATCH v9 05/14] swiotlb: Update is_swiotlb_buffer to add a struct device argument
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c | 6 +++---
kernel/dma/direct.h | 6 +++---
5 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5d96fcc45fec..1a6a08908245 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -506,7 +506,7 @@ static void __iommu_dma_unmap_swiotlb(struct device *dev,
dma_addr_t dma_addr,
__iommu_dma_unmap(dev, dma_addr, size);
- if (unlikely(is_swiotlb_buffer(phys)))
+ if (unlikely(is_swiotlb_buffer(dev, phys)))
swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
}
@@ -577,7 +577,7 @@ static dma_addr_t __iommu_dma_map_swiotlb(struct device
*dev, phys_addr_t phys,
}
iova = __iommu_dma_map(dev, phys, aligned_size, prot, dma_mask);
- if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(phys))
+ if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(dev, phys))
swiotlb_tbl_unmap_single(dev, phys, org_size, dir, attrs);
return iova;
}
@@ -783,7 +783,7 @@ static void iommu_dma_sync_single_for_cpu(struct device
*dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(phys, size, dir);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_cpu(dev, phys, size, dir);
}
@@ -796,7 +796,7 @@ static void iommu_dma_sync_single_for_device(struct device
*dev,
return;
phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_device(dev, phys, size, dir);
if (!dev_is_dma_coherent(dev))
@@ -817,7 +817,7 @@ static void iommu_dma_sync_sg_for_cpu(struct device *dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir);
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_cpu(dev, sg_phys(sg),
sg->length, dir);
}
@@ -834,7 +834,7 @@ static void iommu_dma_sync_sg_for_device(struct device *dev,
return;
for_each_sg(sgl, sg, nelems, i) {
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_device(dev, sg_phys(sg),
sg->length, dir);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 24d11861ac7d..0c4fb34f11ab 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -100,7 +100,7 @@ static int is_xen_swiotlb_buffer(struct device *dev,
dma_addr_t dma_addr)
* in our domain. Therefore _only_ check address within our domain.
*/
if (pfn_valid(PFN_DOWN(paddr)))
- return is_swiotlb_buffer(paddr);
+ return is_swiotlb_buffer(dev, paddr);
return 0;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ec0c01796c8a..921b469c6ad2 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -2,6 +2,7 @@
#ifndef __LINUX_SWIOTLB_H
#define __LINUX_SWIOTLB_H
+#include
#include
#include
#include
@@ -102,9 +103,9 @@ struct io_tlb_mem {
};
extern struct io_tlb_mem *io_tlb_default_mem;
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
return mem && paddr >= mem->start && paddr < mem->end;
}
@@ -121,7 +122,7 @@ bool is_swiotlb_active(void);
void __init swiotlb_adjust_size(unsigned long size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
return false;
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index f737e3347059..84c9feb5474a 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -343,7 +343,7 @@ void dma_direct_sync_sg_for_device(struct device *dev,
for_each_sg(sgl, sg, nents, i) {
phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg));
- if (unlikely(is_swiotlb_buffer(paddr)))
+ if (unlikely(is_swiotlb_buffer(dev, paddr)))
swiotlb_sync_single_for_device(dev, paddr, sg->length,
[PATCH v9 04/14] swiotlb: Add restricted DMA pool initialization
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 3 +-
kernel/dma/Kconfig | 14
kernel/dma/swiotlb.c| 75 +
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 008125ccd509..ec0c01796c8a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -72,7 +72,8 @@ extern enum swiotlb_force swiotlb_force;
* range check to see if the memory was in fact allocated by this
* API.
* @nslabs:The number of IO TLB blocks (in groups of 64) between @start and
- * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @end. For default swiotlb, this is command line adjustable via
+ * setup_io_tlb_npages.
* @used: The number of used IO TLB block.
* @list: The free list describing the number of free entries available
* from each index.
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -80,6 +80,20 @@ config SWIOTLB
bool
select NEED_DMA_MAP_STATE
+config DMA_RESTRICTED_POOL
+ bool "DMA Restricted Pool"
+ depends on OF && OF_RESERVED_MEM
+ select SWIOTLB
+ help
+ This enables support for restricted DMA pools which provide a level of
+ DMA memory protection on systems with limited hardware protection
+ capabilities, such as those lacking an IOMMU.
+
+ For more information see
+
+ and .
+ If unsure, say "n".
+
#
# Should be selected if we can mmap non-coherent mappings to userspace.
# The only thing that is really required is a way to set an uncached bit
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 29b950ab1351..c4a071d6a63f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -39,6 +39,13 @@
#ifdef CONFIG_DEBUG_FS
#include
#endif
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+#include
+#include
+#include
+#include
+#include
+#endif
#include
#include
@@ -688,3 +695,71 @@ static int __init swiotlb_create_default_debugfs(void)
late_initcall(swiotlb_create_default_debugfs);
#endif
+
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ struct io_tlb_mem *mem = rmem->priv;
+ unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
+
+ /*
+* Since multiple devices can share the same pool, the private data,
+* io_tlb_mem struct, will be initialized by the first device attached
+* to it.
+*/
+ if (!mem) {
+ mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
+ if (!mem)
+ return -ENOMEM;
+
+ swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false, true);
+
+ rmem->priv = mem;
+
+ if (IS_ENABLED(CONFIG_DEBUG_FS)) {
+ mem->debugfs =
+ debugfs_create_dir(rmem->name, debugfs_dir);
+ swiotlb_create_debugfs_files(mem);
+ }
+ }
+
+ dev->dma_io_tlb_mem = mem;
+
+ return 0;
+}
+
+static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ dev->dma_io_tlb_mem = io_tlb_default_mem;
+}
+
+static const struct reserved_mem_ops rmem_swiotlb_ops = {
+ .device_init = rmem_swiotlb_device_init,
+ .device_release = rmem_swiotlb_device_release,
+};
+
+static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
+{
+ unsigned long node = rmem->fdt_node;
+
+ if (of_get_flat_dt_prop(node, "reusable", NULL) ||
+ of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
+ of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
+ of_get_flat_dt_prop(node, "no-map", NULL))
+ return -EINVAL;
+
+ if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base {
+ pr_err("Restricted DMA pool must be accessible within the
linear mapping.");
+ return -EINVAL;
+ }
+
+ rmem->ops = _swiotlb_ops;
+ pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld
MiB\n",
+ >base, (unsigned long)rmem->size / SZ_1M);
+ return 0;
+}
+
+RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
--
2.32.0.272.g935e593368-goog
[PATCH v9 03/14] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
---
drivers/of/device.c | 3 +++
include/linux/device.h | 4
include/linux/swiotlb.h | 8
kernel/dma/swiotlb.c| 8
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index c5a9473a5fb1..1defdf15ba95 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -165,6 +165,9 @@ int of_dma_configure_id(struct device *dev, struct
device_node *np,
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
+ if (IS_ENABLED(CONFIG_SWIOTLB))
+ swiotlb_set_io_tlb_default_mem(dev);
+
return 0;
}
EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/include/linux/device.h b/include/linux/device.h
index 4443e12238a0..2e9a378c9100 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -432,6 +432,7 @@ struct dev_links_info {
* @dma_pools: Dma pools (if dma'ble device).
* @dma_mem: Internal for coherent mem override.
* @cma_area: Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Pointer to the swiotlb pool used. Not for driver use.
* @archdata: For arch-specific additions.
* @of_node: Associated device tree node.
* @fwnode:Associated device node supplied by platform firmware.
@@ -540,6 +541,9 @@ struct device {
#ifdef CONFIG_DMA_CMA
struct cma *cma_area; /* contiguous memory area for dma
allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+ struct io_tlb_mem *dma_io_tlb_mem;
#endif
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 216854a5e513..008125ccd509 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -108,6 +108,11 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
return mem && paddr >= mem->start && paddr < mem->end;
}
+static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+{
+ dev->dma_io_tlb_mem = io_tlb_default_mem;
+}
+
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
@@ -119,6 +124,9 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
{
return false;
}
+static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+{
+}
static inline void swiotlb_exit(void)
{
}
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8a3e2b3b246d..29b950ab1351 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -344,7 +344,7 @@ void __init swiotlb_exit(void)
static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t
size,
enum dma_data_direction dir)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
phys_addr_t orig_addr = mem->slots[index].orig_addr;
size_t alloc_size = mem->slots[index].alloc_size;
@@ -426,7 +426,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem,
unsigned int index)
static int find_slots(struct device *dev, phys_addr_t orig_addr,
size_t alloc_size)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long boundary_mask = dma_get_seg_boundary(dev);
dma_addr_t tbl_dma_addr =
phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
@@ -503,7 +503,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned int offset = swiotlb_align_offset(dev, orig_addr);
unsigned int i;
int index;
@@ -554,7 +554,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
size_t mapping_size, enum dma_data_direction dir,
unsigned long attrs)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
unsigned long flags;
unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
--
2.32.0.272.g935e593368-goog
[PATCH v9 02/14] swiotlb: Refactor swiotlb_create_debugfs
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1a1208c81e85..8a3e2b3b246d 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -64,6 +64,9 @@
enum swiotlb_force swiotlb_force;
struct io_tlb_mem *io_tlb_default_mem;
+#ifdef CONFIG_DEBUG_FS
+static struct dentry *debugfs_dir;
+#endif
/*
* Max segment that we can provide which (if pages are contingous) will
@@ -664,18 +667,24 @@ EXPORT_SYMBOL_GPL(is_swiotlb_active);
#ifdef CONFIG_DEBUG_FS
-static int __init swiotlb_create_debugfs(void)
+static void swiotlb_create_debugfs_files(struct io_tlb_mem *mem)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
-
- if (!mem)
- return 0;
- mem->debugfs = debugfs_create_dir("swiotlb", NULL);
debugfs_create_ulong("io_tlb_nslabs", 0400, mem->debugfs, >nslabs);
debugfs_create_ulong("io_tlb_used", 0400, mem->debugfs, >used);
+}
+
+static int __init swiotlb_create_default_debugfs(void)
+{
+ struct io_tlb_mem *mem = io_tlb_default_mem;
+
+ debugfs_dir = debugfs_create_dir("swiotlb", NULL);
+ if (mem) {
+ mem->debugfs = debugfs_dir;
+ swiotlb_create_debugfs_files(mem);
+ }
return 0;
}
-late_initcall(swiotlb_create_debugfs);
+late_initcall(swiotlb_create_default_debugfs);
#endif
--
2.32.0.272.g935e593368-goog
[PATCH v9 01/14] swiotlb: Refactor swiotlb init functions
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 53 ++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8ca7d505d61c..1a1208c81e85 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -168,9 +168,32 @@ void __init swiotlb_update_mem_attributes(void)
memset(vaddr, 0, bytes);
}
-int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
+ unsigned long nslabs, bool late_alloc,
+ bool memory_decrypted)
{
+ void *vaddr = phys_to_virt(start);
unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
+
+ mem->nslabs = nslabs;
+ mem->start = start;
+ mem->end = mem->start + bytes;
+ mem->index = 0;
+ mem->late_alloc = late_alloc;
+ spin_lock_init(>lock);
+ for (i = 0; i < mem->nslabs; i++) {
+ mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
+ mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
+ mem->slots[i].alloc_size = 0;
+ }
+
+ if (memory_decrypted)
+ set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT);
+ memset(vaddr, 0, bytes);
+}
+
+int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+{
struct io_tlb_mem *mem;
size_t alloc_size;
@@ -186,16 +209,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
if (!mem)
panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
__func__, alloc_size, PAGE_SIZE);
- mem->nslabs = nslabs;
- mem->start = __pa(tlb);
- mem->end = mem->start + bytes;
- mem->index = 0;
- spin_lock_init(>lock);
- for (i = 0; i < mem->nslabs; i++) {
- mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
- mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
- mem->slots[i].alloc_size = 0;
- }
+
+ swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false, false);
io_tlb_default_mem = mem;
if (verbose)
@@ -282,7 +297,6 @@ swiotlb_late_init_with_default_size(size_t default_size)
int
swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
{
- unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
struct io_tlb_mem *mem;
if (swiotlb_force == SWIOTLB_NO_FORCE)
@@ -297,20 +311,7 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
if (!mem)
return -ENOMEM;
- mem->nslabs = nslabs;
- mem->start = virt_to_phys(tlb);
- mem->end = mem->start + bytes;
- mem->index = 0;
- mem->late_alloc = 1;
- spin_lock_init(>lock);
- for (i = 0; i < mem->nslabs; i++) {
- mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
- mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
- mem->slots[i].alloc_size = 0;
- }
-
- set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
- memset(tlb, 0, bytes);
+ swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true, true);
io_tlb_default_mem = mem;
swiotlb_print_info();
--
2.32.0.272.g935e593368-goog
[PATCH v9 00/14] Restricted DMA
This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is not behind an IOMMU. As PCI-e, by design, gives the device full access to system memory, a vulnerability in the Wi-Fi firmware could easily escalate to a full system exploit (remote wifi exploits: [1a], [1b] that shows a full chain of exploits; [2], [3]). To mitigate the security concerns, we introduce restricted DMA. Restricted DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a specially allocated region and does memory allocation from the same region. The feature on its own provides a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to restrict the DMA to a predefined memory region (this is usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html [2] https://blade.tencent.com/en/advisories/qualpwn/ [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 v9: Address the comments in v7 to - set swiotlb active pool to dev->dma_io_tlb_mem - get rid of get_io_tlb_mem - dig out the device struct for is_swiotlb_active - move debugfs_create_dir out of swiotlb_create_debugfs - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem - use IS_ENABLED in kernel/dma/direct.c - fix redefinition of 'of_dma_set_restricted_buffer' v8: - Fix reserved-memory.txt and add the reg property in example. - Fix sizeof for of_property_count_elems_of_size in drivers/of/address.c#of_dma_set_restricted_buffer. - Apply Will's suggestion to try the OF node having DMA configuration in drivers/of/address.c#of_dma_set_restricted_buffer. - Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer. - Add error message for PageHighMem in kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to rmem_swiotlb_setup. - Fix the message string in rmem_swiotlb_setup. https://lore.kernel.org/patchwork/cover/1437112/ v7: Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init https://lore.kernel.org/patchwork/cover/1431031/ v6: Address the comments in v5 https://lore.kernel.org/patchwork/cover/1423201/ v5: Rebase on latest linux-next https://lore.kernel.org/patchwork/cover/1416899/ v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 https://lore.kernel.org/patchwork/cover/1378113/ v3: Using only one reserved memory region for both streaming DMA and memory allocation. https://lore.kernel.org/patchwork/cover/1360992/ v2: Building on top of swiotlb. https://lore.kernel.org/patchwork/cover/1280705/ v1: Using dma_map_ops. https://lore.kernel.org/patchwork/cover/1271660/ Claire Chang (14): swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used swiotlb: Add restricted DMA pool initialization swiotlb: Update is_swiotlb_buffer to add a struct device argument swiotlb: Update is_swiotlb_active to add a struct device argument swiotlb: Bounce data from/to restricted DMA pool if available swiotlb: Move alloc_size to find_slots swiotlb: Refactor swiotlb_tbl_unmap_single dma-direct: Add a new wrapper __dma_direct_free_pages() swiotlb: Add restricted DMA alloc/free support. dma-direct: Allocate memory from restricted DMA pool if available dt-bindings: of: Add restricted DMA pool of: Add plumbing for restricted DMA pool .../reserved-memory/reserved-memory.txt | 36 ++- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/iommu/dma-iommu.c | 12 +- drivers/of/address.c | 33 +++ drivers/of/device.c | 6 + drivers/of/of_private.h | 6 + drivers/pci/xen-pcifront.c| 2 +- drivers/xen/swiotlb-xen.c | 2 +- include/linux/device.h| 4 + include/linux/swiotlb.h | 45 +++- kernel/dma/Kconfig| 14 + kernel/dma/direct.c | 62 +++-- kernel/dma/direct.h | 9 +- kernel/dma/swiotlb.c | 242
Re: [PATCH] swiotlb-xen: override common mmap and get_sgtable dma ops
On 6/11/21 5:55 AM, Roman Skakun wrote:
>
> +static int
> +xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + unsigned long user_count = vma_pages(vma);
> + unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> + unsigned long off = vma->vm_pgoff;
> + struct page *page;
> +
> + if (is_vmalloc_addr(cpu_addr))
> + page = vmalloc_to_page(cpu_addr);
> + else
> + page = virt_to_page(cpu_addr);
> +
> + vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
> +
> + if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, ))
> + return -ENXIO;
> +
> + if (off >= count || user_count > count - off)
> + return -ENXIO;
> +
> + return remap_pfn_range(vma, vma->vm_start,
> + page_to_pfn(page) + vma->vm_pgoff,
> + user_count << PAGE_SHIFT, vma->vm_page_prot);
> +}
I suggest you create a helper for computing page value and then revert
922659ea771b3fd728149262c5ea15608fab9719 and pass result of the helper instead
of cpu_addr. Here and in xen_swiotlb_dma_get_sgtable().
And use this new helper in xen_swiotlb_free_coherent() too. I am curious though
why this was not a problem when Stefano was looking at the problem that
introduced this vmalloc check (i.e. 8b1e868f66076490189a36d984fcce286cdd6295).
Stefano?
-boris
[qemu-mainline test] 162623: regressions - FAIL
flight 162623 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162623/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass
Re: [PATCH] Arm32: MSR to SPSR needs qualification
On Fri, 11 Jun 2021, 15:02 Jan Beulich, wrote: > On 11.06.2021 12:41, Julien Grall wrote: > > On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote: > > > >> On 11.06.2021 10:00, Julien Grall wrote: > >>> On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote: > >>> > The Arm ARM's description of MSR doesn't even allow for plain "SPSR" > here, and while gas accepts this, it takes it to mean SPSR_cf. Yet > surely all of SPSR wants updating on this path, not just the lowest > and > highest 8 bits. > > >>> > >>> Can you provide a reference to the Arm Arm? This would help to navigate > >>> through the 8000 pages. > >> > >> Referencing the instruction page would be enough, I thought (as > >> even I, not being an Arm person, have no difficulty locating it). > >> If it isn't, how is a canonical doc ref supposed to look like on > >> Arm? On x86, we avoid recording document versions, section > >> numbers, or even page numbers in code comments or commit messages > >> (which isn't to say we have none of these, but we try to avoid > >> new ones to appear), as these tend to change with every new > >> version of the doc. Therefore, to me, the offending commit's "ARM > >> DDI 0487D.b page G8-5993" doesn't look like something I wanted to > >> clone from. But if you tell me otherwise, then well - so be it. > > > > > > The Arm website provides a link for nearly every revision on the specs. > As > > the wording can change between version, it is useful to know which spec > the > > understanding is based from. > > > > Note that for Arm32 we should quote the Armv7 spec and not the Armv8 one > > because we only follow the former (there are a few small differences). > > Thanks for having me dig out an up-to-date Armv7 spec. I find this > puzzling in particular because you didn't care to have the earlier > commit provide a v7 doc ref. Initially I did intentionally use (a > newer version of) the doc that was pointed at there (which I also > think is better structured than the v7 one). Well Stefano replied past midnight UK time with the reference and committed nearly afterwards. So I didn't really have time to object... When I asked for the reference I didn't think I needed to mention it should be the Armv7 as he should know we only support Armv7 for 32-bit. I didn't bother to reply afterwards. But given there is a bug and you quoted him, I chose to make clear that reference should be Armv7 only. Cheers, > Jan > >
[xen-unstable-smoke test] 162642: regressions - FAIL
flight 162642 xen-unstable-smoke real [real] flight 162646 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162642/ http://logs.test-lab.xenproject.org/osstest/logs/162646/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen d2cad41defe4e0e9987549fbc8ebdf9ae138f90f baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z1 days Failing since162584 2021-06-10 00:00:27 Z1 days 10 attempts Testing same since 162642 2021-06-11 10:00:31 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Ian Jackson Jan Beulich Juergen Gross Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit d2cad41defe4e0e9987549fbc8ebdf9ae138f90f Author: Juergen Gross Date: Wed May 12 16:48:32 2021 +0200 tools/libs/store: cleanup libxenstore interface There are some internals in the libxenstore interface which should be removed. Move those functions into xs_lib.c and the related definitions into xs_lib.h. Remove the functions from the mapfile. Add xs_lib.o to xenstore_client as some of the internal functions are needed there. Bump the libxenstore version to 4.0 as the change is incompatible. Note that the removed functions should not result in any problem as they ought to be used by xenstored or xenstore_client only. Avoid an enum as part of a structure as the size of an enum is compiler implementation dependent. Signed-off-by: Juergen Gross Acked-by: Ian Jackson commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a
[PATCH v2] Arm32: MSR to SPSR needs qualification
The Arm ARM's description of MSR (ARM DDI 0406C.d section B9.3.12)
doesn't even allow for plain "SPSR" here, and while gas accepts this, it
takes it to mean SPSR_cf. Yet surely all of SPSR wants updating on this
path, not just the lowest and highest 8 bits.
Fixes: dfcffb128be4 ("xen/arm32: SPSR_hyp/SPSR")
Signed-off-by: Jan Beulich
---
v2: Add doc ref.
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -395,7 +395,7 @@ return_to_hypervisor:
ldr r11, [sp, #UREGS_pc]
msr ELR_hyp, r11
ldr r11, [sp, #UREGS_cpsr]
-msr SPSR, r11
+msr SPSR_cxsf, r11
#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
/*
* Hardening branch predictor may require to setup a different
Re: [PATCH] Arm32: MSR to SPSR needs qualification
On 11.06.2021 12:41, Julien Grall wrote: > On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote: > >> On 11.06.2021 10:00, Julien Grall wrote: >>> On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote: >>> The Arm ARM's description of MSR doesn't even allow for plain "SPSR" here, and while gas accepts this, it takes it to mean SPSR_cf. Yet surely all of SPSR wants updating on this path, not just the lowest and highest 8 bits. >>> >>> Can you provide a reference to the Arm Arm? This would help to navigate >>> through the 8000 pages. >> >> Referencing the instruction page would be enough, I thought (as >> even I, not being an Arm person, have no difficulty locating it). >> If it isn't, how is a canonical doc ref supposed to look like on >> Arm? On x86, we avoid recording document versions, section >> numbers, or even page numbers in code comments or commit messages >> (which isn't to say we have none of these, but we try to avoid >> new ones to appear), as these tend to change with every new >> version of the doc. Therefore, to me, the offending commit's "ARM >> DDI 0487D.b page G8-5993" doesn't look like something I wanted to >> clone from. But if you tell me otherwise, then well - so be it. > > > The Arm website provides a link for nearly every revision on the specs. As > the wording can change between version, it is useful to know which spec the > understanding is based from. > > Note that for Arm32 we should quote the Armv7 spec and not the Armv8 one > because we only follow the former (there are a few small differences). Thanks for having me dig out an up-to-date Armv7 spec. I find this puzzling in particular because you didn't care to have the earlier commit provide a v7 doc ref. Initially I did intentionally use (a newer version of) the doc that was pointed at there (which I also think is better structured than the v7 one). Jan
Re: [PATCH] Arm32: MSR to SPSR needs qualification
On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote: > On 11.06.2021 10:00, Julien Grall wrote: > > On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote: > > > >> The Arm ARM's description of MSR doesn't even allow for plain "SPSR" > >> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet > >> surely all of SPSR wants updating on this path, not just the lowest and > >> highest 8 bits. > >> > > > > Can you provide a reference to the Arm Arm? This would help to navigate > > through the 8000 pages. > > Referencing the instruction page would be enough, I thought (as > even I, not being an Arm person, have no difficulty locating it). > If it isn't, how is a canonical doc ref supposed to look like on > Arm? On x86, we avoid recording document versions, section > numbers, or even page numbers in code comments or commit messages > (which isn't to say we have none of these, but we try to avoid > new ones to appear), as these tend to change with every new > version of the doc. Therefore, to me, the offending commit's "ARM > DDI 0487D.b page G8-5993" doesn't look like something I wanted to > clone from. But if you tell me otherwise, then well - so be it. The Arm website provides a link for nearly every revision on the specs. As the wording can change between version, it is useful to know which spec the understanding is based from. Note that for Arm32 we should quote the Armv7 spec and not the Armv8 one because we only follow the former (there are a few small differences). > Jan > > >
[linux-linus test] 162605: regressions - FAIL
flight 162605 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162605/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-armhf-armhf-xl-multivcpu 6 host-ping-check-native fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never
[PATCH] swiotlb-xen: override common mmap and get_sgtable dma ops
This commit is dedicated to fix incorrect convertion from
cpu_addr to page address in cases when we get virtual
address which allocated throught xen_swiotlb_alloc_coherent()
and can be mapped in the vmalloc range.
As the result, virt_to_page() cannot convert this address
properly and return incorrect page address.
Need to detect such cases and obtains the page address using
vmalloc_to_page() instead.
The reference code was copied from kernel/dma/ops_helpers.c
and modified to provide additional detections as described
above.
Signed-off-by: Roman Skakun
Reviewed-by: Andrii Anisov
---
Also, I have observed that the original common code didn't
make additional checks about contiguity of the memory region
represented by cpu_addr and size
May be, this means that these functions can get only physically
contiguous memory.
Is this correct?
Cheers!
---
drivers/xen/swiotlb-xen.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 2b385c1b4a99..f99c98472927 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -563,6 +563,53 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
return xen_virt_to_bus(hwdev, xen_io_tlb_end - 1) <= mask;
}
+static int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ unsigned long user_count = vma_pages(vma);
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long off = vma->vm_pgoff;
+ struct page *page;
+
+ if (is_vmalloc_addr(cpu_addr))
+ page = vmalloc_to_page(cpu_addr);
+ else
+ page = virt_to_page(cpu_addr);
+
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
+
+ if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, ))
+ return -ENXIO;
+
+ if (off >= count || user_count > count - off)
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ page_to_pfn(page) + vma->vm_pgoff,
+ user_count << PAGE_SHIFT, vma->vm_page_prot);
+}
+
+static int
+xen_swiotlb_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+ struct page *page;
+ int ret;
+
+ if (is_vmalloc_addr(cpu_addr))
+ page = vmalloc_to_page(cpu_addr);
+ else
+ page = virt_to_page(cpu_addr);
+
+ ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+ if (!ret)
+ sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
+ return ret;
+}
+
const struct dma_map_ops xen_swiotlb_dma_ops = {
.alloc = xen_swiotlb_alloc_coherent,
.free = xen_swiotlb_free_coherent,
@@ -575,8 +622,8 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
.map_page = xen_swiotlb_map_page,
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
- .mmap = dma_common_mmap,
- .get_sgtable = dma_common_get_sgtable,
+ .mmap = xen_swiotlb_dma_mmap,
+ .get_sgtable = xen_swiotlb_dma_get_sgtable,
.alloc_pages = dma_common_alloc_pages,
.free_pages = dma_common_free_pages,
};
--
2.27.0
[PATCH] Arm: avoid .init.data to be marked as executable
This confuses disassemblers, at the very least. Move
.altinstr_replacement to .init.text, dropping the redundant ALIGN().
Also, to have .altinstr_replacement have consistent attributes in the
object files, add "x" to the one instance where it was missing.
Signed-off-by: Jan Beulich
---
I'm uncertain whether having .altinstr_replacement inside or outside the
[_sinittext,_einittext) region is better; I simply followed what we have
on the x86 side right now.
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -147,6 +147,7 @@ SECTIONS
.init.text : {
_sinittext = .;
*(.init.text)
+ *(.altinstr_replacement)
_einittext = .;
} :text
. = ALIGN(PAGE_SIZE);
@@ -169,8 +170,6 @@ SECTIONS
__alt_instructions = .;
*(.altinstructions)
__alt_instructions_end = .;
- . = ALIGN(4);
- *(.altinstr_replacement)
#ifdef CONFIG_DEBUG_LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -67,7 +67,7 @@ int apply_alternatives(const struct alt_
ALTINSTR_ENTRY(feature,cb) \
".popsection\n" \
" .if " __stringify(cb) " == 0\n" \
- ".pushsection .altinstr_replacement, \"a\"\n" \
+ ".pushsection .altinstr_replacement, \"ax\"\n" \
"663:\n\t" \
newinstr "\n" \
"664:\n\t" \
[xen-unstable-smoke test] 162636: regressions - FAIL
flight 162636 xen-unstable-smoke real [real] flight 162640 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162636/ http://logs.test-lab.xenproject.org/osstest/logs/162640/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 2bb17a45b1814b0b6aa4646eff58e16f876281fd baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z1 days Failing since162584 2021-06-10 00:00:27 Z1 days9 attempts Testing same since 162607 2021-06-10 15:00:30 Z0 days5 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Jan Beulich Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a build with -O2 in effect, and despite "compat" being constant "false" when CONFIG_COMPAT (and hence CONFIG_PV32) is not defined, as it gets set at the top of the function from the result of is_pv_32bit_domain(). Re-arrange the two "offending" if()s such that when COMPAT=n the respective variables will be seen as unconditionally initialized. The original aim was to have the !compat cases first, though. Reported-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit dfcffb128be46a3e413eaa941744536fe53c94b6 Author: Stefano Stabellini Date: Wed Jun 9 10:37:59 2021 -0700 xen/arm32: SPSR_hyp/SPSR SPSR_hyp is not meant to be accessed from Hyp mode (EL2); accesses trigger UNPREDICTABLE behaviour. Xen should read/write SPSR instead. See: ARM DDI 0487D.b page G8-5993. This fixes booting
[PATCH] Arm32: avoid .rodata to be marked as executable
This confuses disassemblers, at the very least. When this data still
lived in .init.*, this probably didn't matter much, albeit the
"#execinstr" would have been suspicious to me already then. But the
latest with their movement to .rodata these attributes should have been
dropped.
Fixes: 9cbe093b7b84 ("xen/arm: link: Link proc_info_list in .rodata instead of
.init.data")
Signed-off-by: Jan Beulich
---
The PRINT() macro in head.S is another source of such confusion of code
vs data. While in head.o there are mapping symbols guiding disassemblers,
these mapping symbols are gone when looking at xen-syms. But I realize
adr's reach is too limited to allow for a halfway reasonable approach of
moving those strings (e.g. to, at least, have them all together).
--- a/xen/arch/arm/arm32/proc-v7.S
+++ b/xen/arch/arm/arm32/proc-v7.S
@@ -29,7 +29,7 @@ brahma15mp_init:
mcr CP32(r0, ACTLR)
mov pc, lr
-.section ".proc.info", #alloc, #execinstr
+.section ".proc.info", #alloc
.type __v7_ca15mp_proc_info, #object
__v7_ca15mp_proc_info:
.long 0x410FC0F0 /* Cortex-A15 */
@@ -38,7 +38,7 @@ __v7_ca15mp_proc_info:
.long caxx_processor
.size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
-.section ".proc.info", #alloc, #execinstr
+.section ".proc.info", #alloc
.type __v7_ca7mp_proc_info, #object
__v7_ca7mp_proc_info:
.long 0x410FC070 /* Cortex-A7 */
@@ -47,7 +47,7 @@ __v7_ca7mp_proc_info:
.long caxx_processor
.size __v7_ca7mp_proc_info, . - __v7_ca7mp_proc_info
-.section ".proc.info", #alloc, #execinstr
+.section ".proc.info", #alloc
.type __v7_brahma15mp_proc_info, #object
__v7_brahma15mp_proc_info:
.long 0x420F00F0 /* Broadcom Brahma-B15 */
Re: [PATCH] Arm32: MSR to SPSR needs qualification
On 11.06.2021 10:00, Julien Grall wrote: > On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote: > >> The Arm ARM's description of MSR doesn't even allow for plain "SPSR" >> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet >> surely all of SPSR wants updating on this path, not just the lowest and >> highest 8 bits. >> > > Can you provide a reference to the Arm Arm? This would help to navigate > through the 8000 pages. Referencing the instruction page would be enough, I thought (as even I, not being an Arm person, have no difficulty locating it). If it isn't, how is a canonical doc ref supposed to look like on Arm? On x86, we avoid recording document versions, section numbers, or even page numbers in code comments or commit messages (which isn't to say we have none of these, but we try to avoid new ones to appear), as these tend to change with every new version of the doc. Therefore, to me, the offending commit's "ARM DDI 0487D.b page G8-5993" doesn't look like something I wanted to clone from. But if you tell me otherwise, then well - so be it. Jan
[libvirt test] 162632: regressions - FAIL
flight 162632 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/162632/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt 2a51ff7b40ac7ed81d9244120716e1fd38371572 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 336 days Failing since151818 2020-07-11 04:18:52 Z 335 days 328 attempts Testing same since 162598 2021-06-10 09:09:48 Z0 days2 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle SeongHyun Jo Shalini Chellathurai Saroja Shaojun Yang Shi Lei simmon Simon Gaiser Stefan Bader Stefan Berger Stefan Berger Stefan Hajnoczi Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Ville Skyttä Wang Xin WangJian Weblate Wei Liu Wei Liu William Douglas Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yaroslav Kargin Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass
Re: [PATCH] Arm32: MSR to SPSR needs qualification
On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
> The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
> surely all of SPSR wants updating on this path, not just the lowest and
> highest 8 bits.
>
Can you provide a reference to the Arm Arm? This would help to navigate
through the 8000 pages.
Cheers,
> Fixes: dfcffb128be4 ("xen/arm32: SPSR_hyp/SPSR")
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -395,7 +395,7 @@ return_to_hypervisor:
> ldr r11, [sp, #UREGS_pc]
> msr ELR_hyp, r11
> ldr r11, [sp, #UREGS_cpsr]
> -msr SPSR, r11
> +msr SPSR_cxsf, r11
> #ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> /*
> * Hardening branch predictor may require to setup a different
>
>
[PATCH] Arm32: MSR to SPSR needs qualification
The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
surely all of SPSR wants updating on this path, not just the lowest and
highest 8 bits.
Fixes: dfcffb128be4 ("xen/arm32: SPSR_hyp/SPSR")
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -395,7 +395,7 @@ return_to_hypervisor:
ldr r11, [sp, #UREGS_pc]
msr ELR_hyp, r11
ldr r11, [sp, #UREGS_cpsr]
-msr SPSR, r11
+msr SPSR_cxsf, r11
#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
/*
* Hardening branch predictor may require to setup a different
[linux-5.4 test] 162604: tolerable FAIL - PUSHED
flight 162604 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/162604/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162346 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 162346 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162346 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162346 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 162346 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 162346 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 162346 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 162346 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 162346 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 162346 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 162346 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linux3909e2374335335c9504467caabc906d3f7487e4 baseline version: linux70154d2f82a9058e8316b6e106071c72fcc58718 Last test of basis 162346 2021-06-03 07:12:37 Z8 days Testing same since 162604 2021-06-10 12:11:03 Z0 days1 attempts People who touched revisions under test: Ahelenia Ziemiańska Alex Deucher Alex Williamson Anand Jain Anant Thazhemadam Andrea Righi Andrew Bowers Andrew Morton Ard Biesheuvel Ariel Levkovich Armin Wolf Arnd Bergmann Benjamin Tissoires Bob Moore Borislav Petkov Brett Creeley Carlos M
Re: [xen-unstable-smoke test] 162597: regressions - FAIL
On 11.06.2021 03:49, Stefano Stabellini wrote:
> In any case, I tried to figure it out. I guessed it could be a compiler
> error. I followed the white rabbit down the ARM ARM hole. I disassebled
> the Xen binary [1] from the failed job. "msr SPSR, r11" is 0x0026a38c.
>
> The encoding should be at B9.3.12 of the ARMv7-A DDI 0406C and F5.1.121
> of ARMv8 DDI 0487D.b. Unfortunately it doesn't seem to match either one
> of them and I don't understand why.
>
>
> The "mrs r11, SPSR" is generated as 0x00262ecc. That should be described
> at F5.1.117 for ARMv8 and B9.3.9 for ARMv7. Also doesn't seem to match.
According to my looking at the disassembly, the two numbers you've
quoted are the addresses, not insn encodings. Using my own disassembler
(i.e. there's room for that one being wrong), I do get
E169F00Bmsr spsr_cf, r11
E14FB000mrs r11, spsr
the former of which doesn't look like an exact equivalent of the input
instruction. I guess it really is "msr spsr_cxsf, r11" which is meant?
In gas sources I find this:
/* Unadorned APSR is equivalent to APSR_nzcvq/CPSR_f (for writes). This
is deprecated, but allow it anyway. */
if (is_apsr && lhs)
{
psr_field |= PSR_f;
as_tsktsk (_("writing to APSR without specifying a bitmask is "
"deprecated"));
}
else if (!m_profile)
/* These bits are never right for M-profile devices: don't set them
(only code paths which read/write APSR reach here). */
psr_field |= (PSR_c | PSR_f);
There's clearly a comment missing to talk about the "unadorned" SPSR
case, but the effect is exactly what is observed: Rather than
defaulting to the setting of all 4 bits, only two of them get set
when plain "SPSR" is used. I've not been able to spot a place where
the Arm ARM specifies this, but given its size I'm not surprised at
all. I'd like to note though that the MSR description doesn't even
allow for plain "SPSR" (unlike MRS); only SPSR_<...> is described
there.
Based on this analysis I guess I can make a patch despite not being
able to test it, as I'm pretty certain you really want to restore
all of PSR; not just the low half ...
Jan
[ovmf test] 162609: regressions - FAIL
flight 162609 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162609/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf b8649cf2a3e673a4a8cb6c255e394b354b771550 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z7 days Failing since162368 2021-06-04 15:42:59 Z6 days7 attempts Testing same since 162583 2021-06-09 23:44:58 Z1 days2 attempts People who touched revisions under test: Ard Biesheuvel Kaaira Gupta Laszlo Ersek Leif Lindholm Liming Gao Ni, Ray Ray Ni Rebecca Cran jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1717 lines long.)
Re: [PATCH v2 2/2] tools/xenstore: set open file descriptor limit for xenstored
Am Fri, 11 Jun 2021 09:07:24 +0200 schrieb Juergen Gross : > Isn't that a bug in fillup or the related rpm-macro? No. Fillup expects a certain pattern: a bunch of comments and a single key=var right after that. With such format it might be able to adjust the comment and leave the key=var as it is. Without key=var it will see it as a stale comment, and removes the entire section of comments during the next package update. Olaf pgpuK5DdIQlHg.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2 2/2] tools/xenstore: set open file descriptor limit for xenstored
On 11.06.21 07:46, Olaf Hering wrote: Am Fri, 11 Jun 2021 07:01:31 +0200 schrieb Juergen Gross : Why? You realize that above is a comment just documenting the default? That depends on the context. See https://bugzilla.opensuse.org/show_bug.cgi?id=1185682 for a reason why it should become an empty variable. But yes, we can patch that one too. Isn't that a bug in fillup or the related rpm-macro? A variable set in the existing /etc/sysconfig/xencommons file only should be preserved. In general I think we should be consistent in the file. In case there is no downside for other distributions I'd recommend to switch all variables to your suggested pattern. If there are disadvantages for others we should keep the current pattern as changing it now would break existing installations. Any thoughts? Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [xen-unstable-smoke test] 162597: regressions - FAIL
On 11.06.2021 03:49, Stefano Stabellini wrote: > On Thu, 10 Jun 2021, Bertrand Marquis wrote: >>> On 10 Jun 2021, at 12:32, Jan Beulich wrote: >>> On 10.06.2021 12:50, osstest service owner wrote: flight 162597 xen-unstable-smoke real [real] flight 162602 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162597/ http://logs.test-lab.xenproject.org/osstest/logs/162602/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 >>> >>> This now being the 3rd failure in a row, I guess there's a fair chance >>> of there actually being something wrong with ... >>> commit dfcffb128be46a3e413eaa941744536fe53c94b6 Author: Stefano Stabellini Date: Wed Jun 9 10:37:59 2021 -0700 xen/arm32: SPSR_hyp/SPSR SPSR_hyp is not meant to be accessed from Hyp mode (EL2); accesses trigger UNPREDICTABLE behaviour. Xen should read/write SPSR instead. See: ARM DDI 0487D.b page G8-5993. This fixes booting Xen/arm32 on QEMU. Signed-off-by: Stefano Stabellini Reviewed-by: Julien Grall Reviewed-by: Edgar E. Iglesias Tested-by: Edgar E. Iglesias >>> >>> ... this. My Arm-untrained eye couldn't spot anything in the logs. >> >> I am not sure to read the log correctly so do I see it right that dom0 >> started and it failed then to start a guest ? Well, in this particular flight it succeeded to create Dom1 (for guest-start) and then it managed to also create Dom2, but failed to get the expected "sign of life". It varies at which of the repeated attempts the failure occurs (in one of the flights it also occurred right at guest-start), but failure chances are high enough such that so far in all of the flights things didn't complete successfully. And with this high a failure rate, it accidentally succeeding and thus leading to a push would probably do us more bad than good. > Thanks Jan for bringing it to my attention. > > I am not an expert in reading OSSTest logs. From the following: > > http://logs.test-lab.xenproject.org/osstest/logs/162597/test-armhf-armhf-xl/info.html > > I understand that Xen booted and a DomU was started. However, > "migrate-support-check" and "saverestore-support-check" failed. Is that > correct? Yes, but these two steps aren't the problem - afaict they always fail, and hence wouldn't prevent a push. It's guest-start/debian.repeat which is the problem in this flight. > If so, it would be really strange for SPSR_hyp/SPSR to cause the problem > because I would expect Xen to hang at boot before Dom0 is started > instead. > > > I don't have any ARMv7 hardware to try to repro this issue, and ARMv7 is > most certainly required (ARMv8/aarch32 won't repro.) > > Could someone more at ease with OSSTest than me arrange for a run with > this commit reverted to verify that it is the issue? > > > > In any case, I tried to figure it out. I guessed it could be a compiler > error. I followed the white rabbit down the ARM ARM hole. I disassebled > the Xen binary [1] from the failed job. "msr SPSR, r11" is 0x0026a38c. > > The encoding should be at B9.3.12 of the ARMv7-A DDI 0406C and F5.1.121 > of ARMv8 DDI 0487D.b. Unfortunately it doesn't seem to match either one > of them and I don't understand why. > > > The "mrs r11, SPSR" is generated as 0x00262ecc. That should be described > at F5.1.117 for ARMv8 and B9.3.9 for ARMv7. Also doesn't seem to match. Indeed I was wondering whether perhaps the tool chain has an issue here. Otoh I'd expect a tool chain issue to yield consistent failures rather than ones with just a fair probability. Unless, of course, unspecified behavior is hit, and the hardware indeed behaves randomly in this case. Jan
Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?
On 11.06.21 09:45, Jan Beulich wrote: > On 10.06.2021 17:33, Oleksandr Andrushchenko wrote: >> On 10.06.21 17:10, Roger Pau Monné wrote: >>> On Thu, Jun 10, 2021 at 10:01:16AM +, Oleksandr Andrushchenko wrote: On 10.06.21 10:54, Roger Pau Monné wrote: > On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote: >> Hi, all! >> >> While working on PCI SR-IOV support for ARM I started porting [1] on top >> of current PCI on ARM support [2]. The question I have for this series >> is if we really need emulating SR-IOV code in Xen? >> >> I have implemented a PoC for SR-IOV on ARM [3] (please see the top 2 >> patches) >> and it "works for me": MSI support is still WIP, but I was able to see >> that >> VFs are properly seen in the guest and BARs are properly programmed in >> p2m. >> >> What I can't fully understand is if we can live with this approach or >> there >> are use-cases I can't see. >> >> Previously I've been told that this approach might not work on FreeBSD >> running >> as Domain-0, but is seems that "PCI Passthrough is not supported >> (Xen/FreeBSD)" >> anyways [4]. > PCI passthorgh is not supported on FreeBSD dom0 because PCI > passthrough is not supported by Xen itself when using a PVH dom0, and > that's the only mode FreeBSD dom0 can use. So, it is still not clear to me: how and if PCI passthrough is supported on FreeBSD, what are the scenarios and requirements for that? > PHYSDEVOP_pci_device_add can be added to FreeBSD, so it could be made > to work. I however think this is not the proper way to implement > SR-IOV support. I was not able to find any support for PHYSDEVOP_XXX in FreeBSD code, could you please point me to where are these used? >>> Those are not used on FreeBSD, because x86 PVHv2 dom0 doesn't >>> implement them anymore. They are implemented on Linux for x86 PV dom0, >>> AFAIK Arm doesn't use them either. >> Well, ARM didn't until we started implementing PCI passthrough [1]. >> >> It was previously discussed [2], "# Discovering PCI devices:" and proposed >> >> to use PHYSDEVOP_pci_device_add. >> >> Long story short, it is not easy for ARM to enumerate PCI devices in Xen as >> there is >> >> no unified way of doing so: different platforms implement different PCI host >> bridges >> >> which require complex initialization including clocks, power domains etc. > Just for my own understanding: If this isn't done by firmware, doesn't > this mean you can't boot an Arm system from e.g. a disk connected through > a PCI-based controller? Host bridge setup is definitely firmware's job on > x86 ... On the platforms I work with: no, you can't. Well, it is possible to add PCI support to the firmware, but we normally boot out of eMMC, SD, network and all those are typically NOT PCI devices. Even more. In my everyday work I don't use (need) any PCI device to run the system at all. > Jan > Thank you, Oleksandr
[xen-unstable-smoke test] 162630: regressions - FAIL
flight 162630 xen-unstable-smoke real [real] flight 162634 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162630/ http://logs.test-lab.xenproject.org/osstest/logs/162634/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 18 guest-start/debian.repeat fail REGR. vs. 162574 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 2bb17a45b1814b0b6aa4646eff58e16f876281fd baseline version: xen 3e09045991cde360432bc7437103f8f8a6699359 Last test of basis 162574 2021-06-09 14:00:34 Z1 days Failing since162584 2021-06-10 00:00:27 Z1 days8 attempts Testing same since 162607 2021-06-10 15:00:30 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Edgar E. Iglesias Jan Beulich Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 Not pushing. commit 2bb17a45b1814b0b6aa4646eff58e16f876281fd Author: Jan Beulich Date: Thu Jun 10 16:56:24 2021 +0200 x86: please Clang in arch_set_info_guest() Clang 10 reports domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1334:34: note: uninitialized use occurs here cr3_page = get_page_from_mfn(cr3_mfn, d); ^~~ domain.c:1328:5: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1042:18: note: initialize the variable 'cr3_mfn' to silence this warning mfn_t cr3_mfn; ^ = 0 domain.c:1189:14: error: variable 'fail' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if ( !compat ) ^~~ domain.c:1211:9: note: uninitialized use occurs here fail |= v->arch.pv.gdt_ents != c(gdt_ents); ^~~~ domain.c:1189:9: note: remove the 'if' if its condition is always true if ( !compat ) ^~ domain.c:1187:18: note: initialize the variable 'fail' to silence this warning bool fail; ^ = false despite this being a build with -O2 in effect, and despite "compat" being constant "false" when CONFIG_COMPAT (and hence CONFIG_PV32) is not defined, as it gets set at the top of the function from the result of is_pv_32bit_domain(). Re-arrange the two "offending" if()s such that when COMPAT=n the respective variables will be seen as unconditionally initialized. The original aim was to have the !compat cases first, though. Reported-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit dfcffb128be46a3e413eaa941744536fe53c94b6 Author: Stefano Stabellini Date: Wed Jun 9 10:37:59 2021 -0700 xen/arm32: SPSR_hyp/SPSR SPSR_hyp is not meant to be accessed from Hyp mode (EL2); accesses trigger UNPREDICTABLE behaviour. Xen should read/write SPSR instead. See: ARM DDI 0487D.b page G8-5993. This fixes booting
Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?
On 10.06.2021 17:33, Oleksandr Andrushchenko wrote: > On 10.06.21 17:10, Roger Pau Monné wrote: >> On Thu, Jun 10, 2021 at 10:01:16AM +, Oleksandr Andrushchenko wrote: >>> On 10.06.21 10:54, Roger Pau Monné wrote: On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote: > Hi, all! > > While working on PCI SR-IOV support for ARM I started porting [1] on top > of current PCI on ARM support [2]. The question I have for this series > is if we really need emulating SR-IOV code in Xen? > > I have implemented a PoC for SR-IOV on ARM [3] (please see the top 2 > patches) > and it "works for me": MSI support is still WIP, but I was able to see > that > VFs are properly seen in the guest and BARs are properly programmed in > p2m. > > What I can't fully understand is if we can live with this approach or > there > are use-cases I can't see. > > Previously I've been told that this approach might not work on FreeBSD > running > as Domain-0, but is seems that "PCI Passthrough is not supported > (Xen/FreeBSD)" > anyways [4]. PCI passthorgh is not supported on FreeBSD dom0 because PCI passthrough is not supported by Xen itself when using a PVH dom0, and that's the only mode FreeBSD dom0 can use. >>> So, it is still not clear to me: how and if PCI passthrough is supported >>> >>> on FreeBSD, what are the scenarios and requirements for that? >>> PHYSDEVOP_pci_device_add can be added to FreeBSD, so it could be made to work. I however think this is not the proper way to implement SR-IOV support. >>> I was not able to find any support for PHYSDEVOP_XXX in FreeBSD code, >>> >>> could you please point me to where are these used? >> Those are not used on FreeBSD, because x86 PVHv2 dom0 doesn't >> implement them anymore. They are implemented on Linux for x86 PV dom0, >> AFAIK Arm doesn't use them either. > > Well, ARM didn't until we started implementing PCI passthrough [1]. > > It was previously discussed [2], "# Discovering PCI devices:" and proposed > > to use PHYSDEVOP_pci_device_add. > > Long story short, it is not easy for ARM to enumerate PCI devices in Xen as > there is > > no unified way of doing so: different platforms implement different PCI host > bridges > > which require complex initialization including clocks, power domains etc. Just for my own understanding: If this isn't done by firmware, doesn't this mean you can't boot an Arm system from e.g. a disk connected through a PCI-based controller? Host bridge setup is definitely firmware's job on x86 ... Jan
Re: [xen-unstable bisection] complete test-xtf-amd64-amd64-4
Ian, On 11.06.2021 04:21, osstest service owner wrote: > branch xen-unstable > xenbranch xen-unstable > job test-xtf-amd64-amd64-4 > testid xtf/test-pv32pae-selftest > > Tree: linux git://xenbits.xen.org/linux-pvops.git > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: xen git://xenbits.xen.org/xen.git > Tree: xtf git://xenbits.xen.org/xtf.git > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen git://xenbits.xen.org/xen.git > Bug introduced: 1a0f2fe2297d122a08fee2b26de5de995fdeca13 > Bug not present: 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/162627/ > > > commit 1a0f2fe2297d122a08fee2b26de5de995fdeca13 > Author: George Dunlap > Date: Thu May 6 13:38:02 2021 +0100 > > SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported > > The support status of 32-bit guests doesn't seem particularly useful. > > With it changed to fully unsupported outside of PV-shim, adjust the PV32 > Kconfig default accordingly. > > Reported-by: Jann Horn > Signed-off-by: George Dunlap > Signed-off-by: Jan Beulich as indicated upfront, and as now also confirmed by the large amount of failures in the two most recent full unstable flights, our defaulting to off of PV32 for non-shim Xen builds means in osstest PV32 needs to be turned on again, or all the 32-bit PV Dom0 / DomU tests (and xtf equivalents) would need to be disabled. This will eventually be needed on all branches which we would backport this change to (I expect this would be at least all fully maintained ones), and which have a PV32 setting (exists only as of 4.14). As I don't expect disabling any tests is a reasonable course of action, I think it's going to need to be the .config override. Could you please arrange for this? Jan
