[Xen-devel] [ovmf baseline-only test] 75004: tolerable FAIL
This run is configured for baseline tests only. flight 75004 ovmf real [real] http://osstest.xensource.com/osstest/logs/75004/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75003 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75003 version targeted for testing: ovmf 0f78fd73496f26d45516f6c453a66f35edca6ab0 baseline version: ovmf 49a4797e9c6829520eb3e09b52710b6b6993a65e Last test of basis75003 2018-07-25 00:20:11 Z0 days Testing same since75004 2018-07-25 03:49:59 Z0 days1 attempts People who touched revisions under test: Jaben Carsey 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 0f78fd73496f26d45516f6c453a66f35edca6ab0 Author: Jaben Carsey Date: Fri Jul 20 01:57:39 2018 +0800 BaseTools: AutoGen - change class variable to funciton variable This variable is only used in one function, make it local there. Also when iterating on the variable, use dict.items() to get value instead of re-looking up the value multiple times. Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey Reviewed-by: Yonghong Zhu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125557: all pass - PUSHED
flight 125557 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125557/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0f78fd73496f26d45516f6c453a66f35edca6ab0 baseline version: ovmf 49a4797e9c6829520eb3e09b52710b6b6993a65e Last test of basis 125553 2018-07-24 21:10:51 Z0 days Testing same since 125557 2018-07-25 01:55:47 Z0 days1 attempts People who touched revisions under test: Jaben Carsey jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 49a4797e9c..0f78fd7349 0f78fd73496f26d45516f6c453a66f35edca6ab0 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 125525: regressions - FAIL
flight 125525 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125525/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125138 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125138 test-amd64-amd64-xl-xsm 10 debian-install fail REGR. vs. 125138 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 7 xen-boot fail in 125505 pass in 125525 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail in 125505 pass in 125525 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 125505 pass in 125525 test-amd64-amd64-qemuu-nested-amd 13 xen-install/l1fail pass in 125505 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 125505 like 125138 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail in 125505 never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125138 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125138 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125138 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125138 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125138 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125138 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass build-arm64-pvops 6 kernel-build fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for
[Xen-devel] [qemu-mainline test] 125524: regressions - FAIL
flight 125524 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/125524/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125169 test-amd64-amd64-xl 18 guest-localmigrate/x10 fail REGR. vs. 125169 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125169 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125169 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125169 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125169 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125169 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuue596be90393389405c96a5c9534c4c4e2e0b5675 baseline version: qemuu9277d81f5c2c6f4d0b5e47c8476eb7ee7e5c0beb Last test of basis 125169 2018-07-14 20:30:43 Z 10 days Failing since125246 2018-07-16 15:53:25 Z8 days6 attempts Testing same since 125524 2018-07-23 18:00:13 Z1 days1 attempts People who touched revisions under test: Alex Bennée Alistair Francis Andrew Jeffery BALATON Zoltan Calvin Lee Christian Borntraeger Cornelia Huck Daniel P. Berrangé David Gibson David Hildenbrand Eduardo Habkost Emanuele Giuseppe Esposito Greg Kurz Guenter Roeck Igor Mammedov Jan Kiszka Jason Wang Jonas Schievink Laurent Vivier Marc-André Lureau Marc-André Lureau Markus Armbruster Michael Davidsaver Michael Roth Paolo Bonzini Peter Maydell Peter Xu Philippe Mathieu-Daudé Richard Henderson Roman Kagan Shivaprasad G Bhat Stefan Hajnoczi Stefan Weil Thomas Huth Viktor Prutyanov Yaowei Bai Yunjian Wang jobs: build-amd64-xsm pass build-arm64-xsm
[Xen-devel] [ovmf baseline-only test] 75003: tolerable FAIL
This run is configured for baseline tests only. flight 75003 ovmf real [real] http://osstest.xensource.com/osstest/logs/75003/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75002 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75002 version targeted for testing: ovmf 49a4797e9c6829520eb3e09b52710b6b6993a65e baseline version: ovmf 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f Last test of basis75002 2018-07-24 17:50:09 Z0 days Testing same since75003 2018-07-25 00:20:11 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Laszlo Ersek 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 49a4797e9c6829520eb3e09b52710b6b6993a65e Author: Laszlo Ersek Date: Tue Jul 24 14:57:07 2018 +0200 ArmVirtPkg: remove wrong and superfluous ResourcePublicationLib resolution The class name for the "PeiResourcePublicationLib" instance is just "ResourcePublicationLib", not "PeiResourcePublicationLib". However, no module included in the ArmVirtPkg platforms depends on this lib class; remove its resolution. Cc: Ard Biesheuvel Cc: Julien Grall Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [examine test] 125522: FAIL
flight 125522 examine real [real] http://logs.test-lab.xenproject.org/osstest/logs/125522/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: examine-laxton0 2 hosts-allocate broken REGR. vs. 124647 Tests which did not succeed, but are not blocking: examine-rimava0 4 memdisk-try-append fail blocked in 124647 examine-albana1 4 memdisk-try-append fail like 124647 examine-albana0 4 memdisk-try-append fail like 124647 baseline version: flight 124647 jobs: build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass examine-albana0 pass examine-albana1 pass examine-baroque0 pass examine-baroque1 pass examine-arndale-bluewaterpass examine-cubietruck-braquepass examine-chardonnay0 pass examine-chardonnay1 pass examine-debina0 pass examine-debina1 pass examine-elbling0 pass examine-elbling1 pass examine-fiano0 pass examine-fiano1 pass examine-godello0 pass examine-godello1 pass examine-huxelrebe1 pass examine-italia0 pass examine-joubertin0 pass examine-joubertin1 pass examine-arndale-lakeside pass examine-laxton0 fail examine-laxton1 pass examine-arndale-metrocentre pass examine-cubietruck-metzinger pass examine-cubietruck-picasso pass examine-pinot0 pass examine-pinot1 pass examine-rimava0 pass examine-rimava1 pass examine-arndale-westfieldpass 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 Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] firmware/shim : filter output files during Xen tree setup
Exclude named output files from the Xen tree setup. The linkfarm.stamp content will differ between top level "make" and "make install" invocations, due to the introduction of these output files that are produced during the "make" build. Filter these out to prevent an unnecessary rebuild of the shim during "make install". Signed-off-by: Christopher Clark --- v2: added xen.efi, xen.efi.map to the exclusion list tools/firmware/xen-dir/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile index 84648c3..a9614e4 100644 --- a/tools/firmware/xen-dir/Makefile +++ b/tools/firmware/xen-dir/Makefile @@ -11,6 +11,10 @@ D=xen-root LINK_DIRS=config xen LINK_FILES=Config.mk +# Files to exclude from the link farm +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map xen.efi xen.efi.map \ + efi.lds xen.lds mkelf32 mkreloc + DEP_DIRS=$(foreach i, $(LINK_DIRS), $(XEN_ROOT)/$(i)) DEP_FILES=$(foreach i, $(LINK_FILES), $(XEN_ROOT)/$(i)) @@ -26,7 +30,8 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE $(foreach d, $(LINK_DIRS), \ (cd $(XEN_ROOT); \ find $(d) ! -type l -type f \ -$(addprefix ! -name , '*.[isoa]' '.*.d' '.*.d2')) \ +$(addprefix ! -name , '*.[isoa]' '.*.d' '.*.d2' \ + $(EXCLUDE_FILES) )) \ >> linkfarm.stamp.tmp ; ) \ $(foreach f, $(LINK_FILES), \ echo $(f) >> linkfarm.stamp.tmp ;) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup
On Tue, Jul 24, 2018 at 2:43 AM, Jan Beulich wrote: > >>> On 20.07.18 at 23:15, wrote: > > Exclude named output files from the Xen tree setup. > > > > The linkfarm.stamp content will differ between top level "make" > > and "make install" invocations, due to the introduction of these > > output files that are produced during the "make" build. > > > > Filter these out to prevent an unnecessary rebuild of the shim during > > "make install". > > > > Signed-off-by: Christopher Clark > > --- > > tools/firmware/xen-dir/Makefile | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/tools/firmware/xen-dir/Makefile > > b/tools/firmware/xen-dir/Makefile > > index 84648c3..e490dca 100644 > > --- a/tools/firmware/xen-dir/Makefile > > +++ b/tools/firmware/xen-dir/Makefile > > @@ -11,6 +11,9 @@ D=xen-root > > LINK_DIRS=config xen > > LINK_FILES=Config.mk > > > > +# Files to exclude from the link farm > > +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map efi.lds xen.lds mkelf32 > mkreloc > > What about xen.efi and all of its auxiliary files? Fair point - this list was from a non-EFI build, and EFI does add two more files to it: xen.efi and xen.efi.map > What about other generated files? > I don't see any others being added to the stamp file -- with the possible exception of the "disabled" file in xen/arch/x86/efi which can capture build errors. I don't think that file will be present in production builds. Did you have any others in mind? I'll post an updated patch with the EFI-updated list in the meantime. Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125553: all pass - PUSHED
flight 125553 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125553/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 49a4797e9c6829520eb3e09b52710b6b6993a65e baseline version: ovmf 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f Last test of basis 125546 2018-07-24 14:40:54 Z0 days Testing same since 125553 2018-07-24 21:10:51 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0ed73bcdcd..49a4797e9c 49a4797e9c6829520eb3e09b52710b6b6993a65e -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 12/12] xen: clarify the security-support status of Kconfig options on ARM
On Mon, 23 Jul 2018, Julien Grall wrote: > Hi, > > On 07/07/18 00:14, Stefano Stabellini wrote: > > Signed-off-by: Stefano Stabellini > > CC: george.dun...@eu.citrix.com > > CC: ian.jack...@eu.citrix.com > > CC: jbeul...@suse.com > > CC: andrew.coop...@citrix.com > > --- > > SUPPORT.md | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/SUPPORT.md b/SUPPORT.md > > index e3e49e2..151a63d 100644 > > --- a/SUPPORT.md > > +++ b/SUPPORT.md > > @@ -22,6 +22,16 @@ EXPERT and DEBUG Kconfig options are not security > > supported. Other > > Kconfig options are supported, if the related features are marked as > > supported in this document. > > +On ARM, a wider range of Kconfig configurations is available to enable > > +very small lines of code counts in the hypervisor. Not all possible > > +combinations of kconfig options are security supported. Instead, a few > > NIT: s/kconfig/Kconfig/ > > > +pre-canned configurations have been added to xen/arch/arm/configs: they > > +are security suppored. Configurations derived from the pre-canned files > > s/suppored/supported/ I'll fix > > +by adding non-listed options with their default values, or by enabling > > +any of the platform options under "Platform Support" (and their > > +dependent options) are security supported, unless stated > > +otherwise. > > I am not entirely sure to understand the implications the paragraph. It is meant to say: 1) xen/arch/arm/configs config files are security supported 2) default values of any kconfig options are security supported 3) if an option is marked as not security supported in SUPPORT.md, then it is not security supported, no matter the default value 4) everything else is not security supported Should I try to clarify it? I guess I should make clear that a .config with an unsupported option is unsupported as a whole. I can add: "A configuration with one or more unsupported options, is not unsupported." > For instance, if I choose arm64_defconfig, memaccess will be enabled by > default but any use of it is not security supported. What will be the state of > the security support for that .config? Yes, memaccess will default to enable. However, SUPPORT.md says it is not security supported, hence, the result is that the .config is not security supported, according to (3). There is a catch though. In the specific case of memaccess, SUPPORT.md only states the following: ### Virtual Machine Introspection Status, x86: Supported, not security supported Which doesn't say anything about ARM. It would be a good idea to do the same that x86 is doing (Supported, not security supported)? > I also think an Ack from the security team will probably more meaningful than > mine here. After all they are the one dealing with the security issues :). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs
On Mon, 23 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 07/07/18 00:13, Stefano Stabellini wrote: > > +config QEMU_PLATFORM > > + bool > > + > > +config RCAR3_PLATFORM > > + bool > > Those 2 options do nothing. So I would prefer if they are removed. With that > fixed: > > Acked-by: Julien Grall Sure, I'll do that. We'll add them when we/if we'll actually need them. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote: > However, if you are proposing that you'd like to contribute the enhanced > PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and > have them merged instead of this patch series, then I would certainly > welcome it! I'd in principle love us to push everything back to 4.4, but there are a few reasons (*) why that's not happening shortly. Anyway, to point out explicitly what's really needed for those folks running 4.4-stable and relying on PTI providing The Real Thing(TM), it's either a 4.4-stable port of http://kernel.suse.com/cgit/kernel-source/plain/patches.suse/x86-entry-64-use-a-per-cpu-trampoline-stack.patch?id=3428a77b02b1ba03e45d8fc352ec350429f57fc7 or making THREADINFO_GFP imply __GFP_ZERO. (*) IBRS is not upstream, we historically have had very different x86 codebase compared to either 4.4, 4.4-stable or current Linus' tree, and there are simply too many things happening right now to give this high enough priority, sadly. We're not fully-dependent downstream consumer of -stable any more, so this is one of the expected outcomes, unfortunately; we don't immediately benefit from pushing our downstream changes to stable, as we have to carry those over forward ourselves anyway. Thanks, -- Jiri Kosina SUSE Labs ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
> /* failed to reap part of the address space. Try again later */
> if (!__oom_reap_task_mm(mm)) {
> up_read(>mmap_sem);
> - return true;
> + return false;
> }
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
>
>
> On top of that the proposed cleanup looks as follows:
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 88657e018714..4e185a282b3d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
> return ret;
> }
>
> +/*
> + * Reaps the address space of the give task.
> + *
> + * Returns true on success and false if none or part of the address space
> + * has been reclaimed and the caller should retry later.
> + */
> static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
> {
> + bool ret = true;
> +
> if (!down_read_trylock(>mmap_sem)) {
> trace_skip_task_reaping(tsk->pid);
> return false;
> @@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
>* down_write();up_write() cycle in exit_mmap().
>*/
> if (test_bit(MMF_OOM_SKIP, >flags)) {
> - up_read(>mmap_sem);
> trace_skip_task_reaping(tsk->pid);
> - return true;
> + goto out_unlock;
> }
>
> trace_start_task_reaping(tsk->pid);
>
> /* failed to reap part of the address space. Try again later */
> - if (!__oom_reap_task_mm(mm)) {
> - up_read(>mmap_sem);
> - return false;
> - }
> + ret = __oom_reap_task_mm(mm);
> + if (!ret)
> + goto out_finish;
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
> task_pid_nr(tsk), tsk->comm,
> K(get_mm_counter(mm, MM_ANONPAGES)),
> K(get_mm_counter(mm, MM_FILEPAGES)),
> K(get_mm_counter(mm, MM_SHMEMPAGES)));
> +out_finish:
> + trace_finish_task_reaping(tsk->pid);
> +out_unlock:
> up_read(>mmap_sem);
>
> - trace_finish_task_reaping(tsk->pid);
> - return true;
> + return ret;
> }
>
> #define MAX_OOM_REAP_RETRIES 10
I think we still want to trace when reaping was skipped to know that the
oom reaper will retry again later.
mm/oom_kill.c: clean up oom_reap_task_mm() fix
indicate reaping has been partially skipped so we can expect future skips
or another start before finish.
Signed-off-by: David Rientjes
---
mm/oom_kill.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -569,10 +569,12 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
trace_start_task_reaping(tsk->pid);
- /* failed to reap part of the address space. Try again later */
ret = __oom_reap_task_mm(mm);
- if (!ret)
+ if (!ret) {
+ /* Failed to reap part of the address space. Try again later */
+ trace_skip_task_reaping(tsk->pid);
goto out_finish;
+ }
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 125514: regressions - FAIL
flight 125514 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/125514/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125401 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125401 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125401 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125401 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 125401 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125401 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 125401 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 125401 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125401 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125401 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 125401 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125401 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125401 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125401 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 125401 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125401 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125401 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 6 xen-install fail in 125466 pass in 125514 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail pass in 125466 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail pass in 125466 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail pass in 125466 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 10 debian-install fail REGR. vs. 125401 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125401 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125401 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125401 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125401 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125401 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125401 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125401 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125401 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check
Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
On 7/23/18 3:06 PM, Jiri Kosina wrote: > On Sat, 14 Jul 2018, Srivatsa S. Bhat wrote: > >> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS) >> and patches for the Speculative Store Bypass vulnerability to 4.4.y >> (they apply cleanly on top of 4.4.140). > > FWIW -- not sure how much inspiration you took from our SLE 4.4-based > tree, but most of the stuff is already there for quite some time > (including the non-upstream IBRS on kernel boundary on SKL+, trampoline > stack for PTI (which the original port didn't have), etc). > > The IBRS SKL+ stuff has not been picked up by Greg, as it's non-upstream, > and the trampoline stack I believe was pointed out to stable@, but noone > really sat down and did the port (our codebase is different than 4.4.x > stable base), but it definitely should be done if someone has to put 100% > trust into the PTI port (either that, or at least zeroing out the kernel > thread thread stack ... we used to have temporarily that before we > switched over to proper entry trampoline in this version as well). > I did glance at the SLES 4.4 kernel sometime ago, but there seemed to be way too many custom patches and I wasn't sure in what ways your PTI/Spectre fixes depended on the other (x86) patches in your tree. So I decided to backport entirely from the 4.9 stable tree instead. My reasoning was that, since the 4.9 stable patches were trusted to work well, their 4.4 backports should work well too, as long as they are backported correctly. However, if you are proposing that you'd like to contribute the enhanced PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and have them merged instead of this patch series, then I would certainly welcome it! Regards, Srivatsa VMware Photon OS ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to something which happened in the past, is in fact
> > referring to something which might happen in the future.
> >
> > - fails to call trace_finish_task_reaping() in one case
> >
> > - code duplication.
> >
> > - Increases mmap_sem hold time a little by moving
> > trace_finish_task_reaping() inside the locked region. So sue me ;)
> >
> > - Sharing the finish: path means that the trace event won't
> > distinguish between the two sources of finishing.
> >
> > Please take a look?
>
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
> /* failed to reap part of the address space. Try again later */
> if (!__oom_reap_task_mm(mm)) {
> up_read(>mmap_sem);
> - return true;
> + return false;
> }
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
OK, thanks, I added that.
>
> On top of that the proposed cleanup looks as follows:
>
Looks good to me. Seems a bit strange that we omit the pr_info()
output if the mm was partially reaped - people would still want to know
this? Not very important though.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 125517: regressions - FAIL
flight 125517 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125517/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 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-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a version targeted for testing: libvirt f508a65a21fb2a3ea3619c7eddbb85633279995a baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 49 days Failing since123840 2018-06-06 04:19:28 Z 48 days 36 attempts Testing same since 125517 2018-07-23 11:39:10 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked
[Xen-devel] [ovmf baseline-only test] 75002: tolerable FAIL
This run is configured for baseline tests only. flight 75002 ovmf real [real] http://osstest.xensource.com/osstest/logs/75002/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75001 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75001 version targeted for testing: ovmf 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f baseline version: ovmf 5b73e17fb17c6935d894b0084f32421e717c247f Last test of basis75001 2018-07-24 14:52:20 Z0 days Testing same since75002 2018-07-24 17:50:09 Z0 days1 attempts People who touched revisions under test: Dongao Guo Liming Gao 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f Author: Liming Gao Date: Tue Jul 24 10:23:28 2018 +0800 OvmfPkg: Correct ResourcePublicationLib class name in DSC/INF files ResourcePublicationLib class name is ResourcePublicationLib. INF and DSC files are updated to use the correct one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Signed-off-by: Dongao Guo [ler...@redhat.com: insert empty line between commit msg body and tags] Reviewed-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 125520: regressions - FAIL
flight 125520 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125520/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 123554 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123554 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 123554 build-armhf-pvops 6 kernel-build fail REGR. vs. 123554 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123554 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123554 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linuxd72e90f33aa4709ebecc5005562f52335e106a60 baseline version: linux0512e0134582ef85dee77d51aae77dcd1edec495 Last test of basis 123554 2018-06-01 13:09:41 Z 53 days Failing since123655 2018-06-03 01:45:35 Z 51 days 31 attempts Testing same since 125520 2018-07-23 12:51:24 Z1 days1 attempts 2317 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass
Re: [Xen-devel] [PATCH v2 01/17] x86/cpu: create Dhyana init file and register new cpu_dev to system
On 23/07/2018 15:20, Pu Wen wrote:
> Add x86 architecture support for new processor Hygon Dhyana Family 18h.
> Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the
> AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In
> this way we can remove old AMD architecture support codes from Hygon
> code path and generate a clear initialization flow for Hygon processors,
> it also reduce long-term maintenance effort.
> Also add hygon.c Maintainer information in accordance.
>
> To identify Hygon processors, add a new vendor type X86_VENDOR_HYGON(9)
> for system recognition.
>
> To enable Hygon processor config, add a separated Kconfig entry(CPU_SUP_
> HYGON) for Dhyana CPU in kernel config setup.
If Hygon processors are currently the same as AMD, I don't see the point
in creating a new file just for them. Likewise for example in patch 6
+ case X86_VENDOR_HYGON:
+ ideal_nops = p6_nops;
+ return;
+
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 > 0xf) {
ideal_nops = p6_nops;
Should only need to add "case X86_VENDOR_HYGON:". Or you could even
reuse X86_VENDOR_AMD.
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen ARM Community Call Wednesday 25th July 9AM Pacific / 4PM UTC
Hi all, This is just a reminder that tomorrow we are going to have the Xen on ARM Community Call at 9AM California time. You are very welcome to join! Cheers, Stefano On Fri, 13 Jul 2018, Stefano Stabellini wrote: > Hi all, > > It is time for another Xen on ARM Community Call. I suggest to talk > again on Wed 25 July at 9AM California time. > > Please reply to this thread suggestions topics for discussion. I'll > start by suggesting "progress on certifications". > > This time we get to use the Xilinx WebEx conference system, see > attached. I also appended the details to join the conference call. > > Cheers, > > Stefano > > > JOIN WEBEX MEETING > https://xilinx.webex.com/xilinx/j.php?MTID=m94c112941ad6a6f6a0ccc2140c84bfe9 > Meeting number: 920 504 982 > Meeting password: akZPPX*9 > > JOIN BY PHONE > Call-in toll-free number: 1-(877) 582-3182 (US) > Call-in number: 1-(770) 657-9791 (US) > Show global numbers: > https://www.tcconline.com/offSite/OffSiteController.jpf?cc=1659920463 > Conference Code: 165 992 0463 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: introduce a script for build test
On Tue, Jul 24, 2018 at 05:56:51PM +0100, Wei Liu wrote: > Signed-off-by: Ian Jackson > Signed-off-by: Wei Liu > --- > This is a script I wrote previously for build test. Goal here is to bisect a series to find the build failure? We could allow git bisect to do the work and just build and return success or failure instead of having to walk it by hand. I don't have one specifically for Xen but on other projects I've got something like: ./scripts/bisect.sh which looks roughly like: #!/bin/sh git bisect start $2 $1 git bisect run ./scripts/basic-build.sh Then my ./scripts/basic-build.sh would look like: #!/bin/sh git clean -xdf ./configure || exit 1 make > > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > Cc: Julien Grall > Cc: Anthony PERARD > > v5: > 1. Use bash so that while do ... done < () works. > 2. Move script to automation directory. > > v4: > 1. Check, save/restore $?. > 2. Don't use trap, check exit code directly. > 3. More error messages. > > v3: > 1. Use git-clean in default rune. > 2. Print more friendly message. > 3. Restore HEAD automatically. > --- > automation/scripts/build-test.sh | 68 > > 1 file changed, 68 insertions(+) > create mode 100755 automation/scripts/build-test.sh > > diff --git a/automation/scripts/build-test.sh > b/automation/scripts/build-test.sh > new file mode 100755 > index 00..885e5f7a13 > --- /dev/null > +++ b/automation/scripts/build-test.sh > @@ -0,0 +1,68 @@ > +#!/bin/bash > + > +# Run command on every commit within the range specified. If no command is > +# provided, use the default one to clean and build the whole tree. > +# > +# The default rune is rather simple. To do a cross-build, please put your > usual > +# build rune in a shell script and invoke it with this script. > + > +if ! test -f xen/common/kernel.c; then > +echo "Please run this script from top-level directory" > +exit 1 > +fi You could make it run from anywhere if you did: pushd `git rev-parse --show-toplevel` ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125549: tolerable all pass - PUSHED
flight 125549 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125549/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 173c7803592065d27bf2e60d50e08e197a0efa83 baseline version: xen be5e2ff6f54e0245331ed360b8786760f82fd673 Last test of basis 125543 2018-07-24 13:01:09 Z0 days Testing same since 125549 2018-07-24 16:00:29 Z0 days1 attempts People who touched revisions under test: Jan Beulich Jason Andryuk Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git be5e2ff6f5..173c780359 173c7803592065d27bf2e60d50e08e197a0efa83 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125546: all pass - PUSHED
flight 125546 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125546/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f baseline version: ovmf 5b73e17fb17c6935d894b0084f32421e717c247f Last test of basis 125540 2018-07-24 08:40:43 Z0 days Testing same since 125546 2018-07-24 14:40:54 Z0 days1 attempts People who touched revisions under test: Dongao Guo Liming Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 5b73e17fb1..0ed73bcdcd 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
FWIW, On Tue, 2018-07-24 at 16:26 +0100, George Dunlap wrote: > On 07/24/2018 12:23 PM, Lars Kurth wrote: > > > > It seems to me there are a number of options we have and thus some > > decisions > > that need to be made. > > 2: Do we have an opt-in or op-out (e.g. through a tag, a specific > > CC, etc.) for patches > > Opt-out. > +1 > > 5: Do we report back on success or only on failure? > > See question by Julien > > I'd start with having the bot respond to 00/NN exactly once, both on > success and failure. > +1 > > 4: Who else, besides the author should get a mail > > The patch submitters should definitely get a mail, the question is > > whether people on the CC list should also get one > > I think the bot should reply-to-all. Maybe we can add an opt-out to > our > website, so that the bot won't reply to you if you don't want it to. > +1 :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] automation: introduce a script for build test
Signed-off-by: Ian Jackson Signed-off-by: Wei Liu --- This is a script I wrote previously for build test. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Cc: Julien Grall Cc: Anthony PERARD v5: 1. Use bash so that while do ... done < () works. 2. Move script to automation directory. v4: 1. Check, save/restore $?. 2. Don't use trap, check exit code directly. 3. More error messages. v3: 1. Use git-clean in default rune. 2. Print more friendly message. 3. Restore HEAD automatically. --- automation/scripts/build-test.sh | 68 1 file changed, 68 insertions(+) create mode 100755 automation/scripts/build-test.sh diff --git a/automation/scripts/build-test.sh b/automation/scripts/build-test.sh new file mode 100755 index 00..885e5f7a13 --- /dev/null +++ b/automation/scripts/build-test.sh @@ -0,0 +1,68 @@ +#!/bin/bash + +# Run command on every commit within the range specified. If no command is +# provided, use the default one to clean and build the whole tree. +# +# The default rune is rather simple. To do a cross-build, please put your usual +# build rune in a shell script and invoke it with this script. + +if ! test -f xen/common/kernel.c; then +echo "Please run this script from top-level directory" +exit 1 +fi + +if test $# -lt 2 ; then +echo "Usage: $0 [CMD]" +exit 1 +fi + +status=`git status -s` +if test -n "$status"; then +echo "Tree is dirty, aborted" +exit 1 +fi + +BASE=$1; shift +TIP=$1; shift + +ORIG_BRANCH=`git symbolic-ref -q --short HEAD` +if test $? -ne 0; then +echo "Detached HEAD, aborted" +exit 1 +fi + +while read num rev; do +echo "Testing $num $rev" + +git checkout $rev +ret=$? +if test $ret -ne 0; then +echo "Failed to checkout $num $rev with $ret" +break +fi + +if test $# -eq 0 ; then +git clean -fdx && ./configure && make -j4 +else +"$@" +fi +ret=$? +if test $ret -ne 0; then +echo "Failed at $num $rev with $ret" +break +fi +echo +done < <(git rev-list $BASE..$TIP | nl -ba | tac) + +echo "Restoring original HEAD" +git checkout $ORIG_BRANCH +gco_ret=$? +if test $gco_ret -ne 0; then +echo "Failed to restore orignal HEAD. Check tree status before doing anything else!" +exit $gco_ret +fi + +if test $ret -eq 0; then +echo "ok." +fi +exit $ret -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75001: tolerable FAIL
This run is configured for baseline tests only. flight 75001 ovmf real [real] http://osstest.xensource.com/osstest/logs/75001/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 74999 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 74999 version targeted for testing: ovmf 5b73e17fb17c6935d894b0084f32421e717c247f baseline version: ovmf 005c855dc6be0f61f76de0d7ec4a62ee737518d6 Last test of basis74999 2018-07-24 05:19:57 Z0 days Testing same since75001 2018-07-24 14:52:20 Z0 days1 attempts People who touched revisions under test: Yonghong Zhu Yunhua Feng 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 5b73e17fb17c6935d894b0084f32421e717c247f Author: Yunhua Feng Date: Fri Jul 20 15:51:39 2018 +0800 BaseTools: Fix the different token with the same PCD If the different token with the same PCD names are used in the driver, build can pass. If the different token with the same PCD name are used in the different library, then the driver build will fail. The reason is that the driver autogen.c is not generated correctly for the second case. BaseTools should check the duplicated PCD name is the driver and its linked libraries. Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng Reviewed-by: Liming Gao commit bfa7eeb61d94623ddbe43b916a0bb1dc0f73a292 Author: Yonghong Zhu Date: Mon Jul 23 11:58:22 2018 +0800 BaseTools: Correct _PCD_PATCHABLE_TokenName_SIZE's value current if user use PatchPcdSetPtr in library, it will report the _PCD_PATCHABLE_TokenName_SIZE is not defined. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 07/24/2018 04:44 PM, Jan Beulich wrote: On 24.07.18 at 16:01, wrote: >> I don't see what the problem is in having a single response to the >> thread saying that the test was run, the result of the run, and a link >> to a page about it. It's certainly less mail than I get in the course >> of a normal review cycle about patch series I'm not interested in. >> >> I mean, suppose we just had a really enthusiastic contributor who made >> it their personal goal to test and build every patch that was sent to >> the list. Would anyone really complain about a single extra mail per >> series, when a typical series generates dozens of human-generated mails >> anyway? > > Well, I agree one can view at this from different angles. Your > perspective looks to be that with there already being so much > mail, a little more doesn't hurt. I'm on the position that every > unnecessary mail is a problem. For (long) series the one extra > mail perhaps is indeed not only tolerable but helpful (albeit even > there it would rather be one mail per version, which may > become increasingly pointless as only very small changes get > done between versions). For individual patches (one liners to > take the extreme) there often is just a single response with an > ack. The bot would increase that volume by a whopping 50% > (or 100% for anyone for their own patches). > > With all this said, just to be clear: I'm not against improvements > here or anywhere else, but their price needs to be reasonable. OK, well why don't we give it a try, and if people find the mail spammy we can add a "do-not-mail" list that the bot will avoid sending mail to. If there's a series someone in the do-not-mail list decides they want information on, it shouldn't be too difficult to find it from the status page. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.8-testing test] 125512: regressions - FAIL
flight 125512 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125512/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken in 125165 build-i386-pvops 6 kernel-build fail REGR. vs. 125065 build-armhf-libvirt 5 host-build-prep fail in 125165 REGR. vs. 125065 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 6 xen-install fail in 125165 pass in 125512 test-armhf-armhf-xl-multivcpu 7 xen-bootfail in 125165 pass in 125512 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 125218 pass in 125500 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail in 125500 pass in 125165 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail in 125500 pass in 125218 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail in 125500 pass in 125365 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 125500 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked in 125165 n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked in 125165 n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 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-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125365 like 124942 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 125365 like 125040 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail in 125500 like 124996 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125500 like 125040 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125500 like 125040 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 125500 like 125065 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125500 like 125065 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 125500 like 125065 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 125500 like 125065 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125500 like 125065 test-amd64-i386-libvirt 13 migrate-support-check fail in 125500 never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 125500 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 125500 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 125500 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 24.07.18 at 16:01, wrote: > I don't see what the problem is in having a single response to the > thread saying that the test was run, the result of the run, and a link > to a page about it. It's certainly less mail than I get in the course > of a normal review cycle about patch series I'm not interested in. > > I mean, suppose we just had a really enthusiastic contributor who made > it their personal goal to test and build every patch that was sent to > the list. Would anyone really complain about a single extra mail per > series, when a typical series generates dozens of human-generated mails > anyway? Well, I agree one can view at this from different angles. Your perspective looks to be that with there already being so much mail, a little more doesn't hurt. I'm on the position that every unnecessary mail is a problem. For (long) series the one extra mail perhaps is indeed not only tolerable but helpful (albeit even there it would rather be one mail per version, which may become increasingly pointless as only very small changes get done between versions). For individual patches (one liners to take the extreme) there often is just a single response with an ack. The bot would increase that volume by a whopping 50% (or 100% for anyone for their own patches). With all this said, just to be clear: I'm not against improvements here or anywhere else, but their price needs to be reasonable. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 07/24/2018 04:26 PM, George Dunlap wrote: > On 07/24/2018 12:23 PM, Lars Kurth wrote: >> >> On 24/07/2018, 11:50, "Julien Grall" wrote: >> >> Hi Lars, >> >> On 24/07/18 11:33, Lars Kurth wrote: >> > >> > On 24/07/2018, 11:19, "Wei Liu" wrote: >> > On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: >> > > I'm afraid my personal bar for any such automation is pretty >> > > high: There must not ever be any negative effect from such an >> > > addition. Positive effects would of course be very welcome. I >> > > realize this is an unrealistic goal, but it should at least come >> > > close (perhaps after some initial learning phase). But this >> implies >> > > that at least in theory it is possible to come close in the >> first >> > > place, which I can't take for given with the information I've >> been >> > > provided so far. >> > >> > Then I'm afraid the only suggestion I get for you at the moment >> is to >> > add a filter to dump those emails to /dev/null -- you already >> realised >> > that's an unrealistic goal (at least at the beginning). >> > >> > Wei. >> > >> > First of all, there should only be mail (aka spam) if there was a >> failure. >> >> This seems a little strange to only send e-mail on failure. How do you >> differentiate between the bot has successfully tested that series and >> the series is still in queue then? >> >> Yes, that would be a trade-off to minimize "spam" >> >> It seems to me there are a number of options we have and thus some decisions >> that need to be made. >> >> 1: Do we trigger a CI cycle for *every* patch? > > In a world with infinite resources, yes, because we want to detect > broken bisections. My guess is that this would be too > resource-intensive for the real world. > > No matter what, I'd prefer only one email per series; Definitely *don't* > want a success email for every patch. What about having "check-bisectability" as a separate test? Rather than doing a full build test from a clean tree for every possible distro, we could do something like for patch in $patches; do patch -p1 < $patch make done That should catch most bisection-breaking issues without being overly resource-intensive. From the CI's perspective, you'd be running on the whole series, and check-bisectability would be a single sub-test. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125543: tolerable all pass - PUSHED
flight 125543 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125543/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen be5e2ff6f54e0245331ed360b8786760f82fd673 baseline version: xen 6e2a53afa15422ee290663dbb798c085ef7068ed Last test of basis 125541 2018-07-24 09:00:34 Z0 days Testing same since 125543 2018-07-24 13:01:09 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6e2a53afa1..be5e2ff6f5 be5e2ff6f54e0245331ed360b8786760f82fd673 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 07/24/2018 12:23 PM, Lars Kurth wrote: > > On 24/07/2018, 11:50, "Julien Grall" wrote: > > Hi Lars, > > On 24/07/18 11:33, Lars Kurth wrote: > > > > On 24/07/2018, 11:19, "Wei Liu" wrote: > > On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > > > I'm afraid my personal bar for any such automation is pretty > > > high: There must not ever be any negative effect from such an > > > addition. Positive effects would of course be very welcome. I > > > realize this is an unrealistic goal, but it should at least come > > > close (perhaps after some initial learning phase). But this > implies > > > that at least in theory it is possible to come close in the first > > > place, which I can't take for given with the information I've > been > > > provided so far. > > > > Then I'm afraid the only suggestion I get for you at the moment is > to > > add a filter to dump those emails to /dev/null -- you already > realised > > that's an unrealistic goal (at least at the beginning). > > > > Wei. > > > > First of all, there should only be mail (aka spam) if there was a > failure. > > This seems a little strange to only send e-mail on failure. How do you > differentiate between the bot has successfully tested that series and > the series is still in queue then? > > Yes, that would be a trade-off to minimize "spam" > > It seems to me there are a number of options we have and thus some decisions > that need to be made. > > 1: Do we trigger a CI cycle for *every* patch? In a world with infinite resources, yes, because we want to detect broken bisections. My guess is that this would be too resource-intensive for the real world. No matter what, I'd prefer only one email per series; Definitely *don't* want a success email for every patch. > 2: Do we have an opt-in or op-out (e.g. through a tag, a specific CC, etc.) > for patches Opt-out. > 3: Do we report results back to xen-devel or to a separate list > Looking at Linux 0 day, they report failures to a separate list - see > https://lists.01.org/pipermail/kbuild-all/2018-July/thread.html > They also only seem to report failures > > I am not quite sure what QEMU does. But I can't see any bot messages on their > list archives [snip] > 5: Do we report back on success or only on failure? > See question by Julien I'd start with having the bot respond to 00/NN exactly once, both on success and failure. > 4: Who else, besides the author should get a mail > The patch submitters should definitely get a mail, the question is whether > people on the CC list should also get one I think the bot should reply-to-all. Maybe we can add an opt-out to our website, so that the bot won't reply to you if you don't want it to. > 6: What exactly do we report back > Aka what is in the actual mail A link to the git branch it created (if the patch applied), or a snippet of the rejection message if it didn't. Success / failure, with a link to a page containing the various tests run, so people can see which one failed and investigate the failures. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > >>> On 24.07.18 at 11:43, wrote: > > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote: > >> >>> On 24.07.18 at 11:24, wrote: > >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> >> >>> On 23.07.18 at 18:40, wrote: > >> >> > # How does this impact me? > >> >> > The contribution workflow is *not* impacted by this change, but once > >> >> > up and > >> > > >> >> > running the following will happen once you post a patch or patch > >> >> > series to > >> >> > xen-devel: > >> >> > * Patchwork will take patch series from the mailing list and applies > >> >> > it > >> >> > * CI/DC testing is triggered > >> >> > * A test report will be sent as a mail to the patch or the series > >> >> > (aka the 00 patch of the series) > >> >> > > >> >> > This does mean though that series which do not build or show other > >> >> > issues, > >> >> > will likely not be reviewed until the tests pass. This would lessen > >> >> > the > >> >> > burden on reviewers, as they will know whether the code submitted > >> >> > builds on a > >> >> > wide array of environments. > >> >> > >> >> So how are dependencies between series intended to be dealt with? It > >> >> is not uncommon for someone to say "applies only on top of xyz". The > >> >> implication of "will likely not be reviewed until the tests pass" seems > >> >> unsuitable to me in such a case. > >> >> > >> > > >> > We have been asking everyone to rebase to staging before posting a new > >> > version for a long time. It is natural for the bot to assume that > >> > everything should apply on top of staging. That would provide most value > >> > to the community. > >> > > >> > For special cases like you just mention, we should aim to provide > >> > mechanisms to manually appoint a branch to be tested. > >> > >> I'm afraid I disagree again: Tools used should not be dictated. I'm > >> using quilt, not git for my work, and hence I don't maintain any > >> branches anywhere. > > > > Alright. > > > > First, I don't think I said that only git would be supported. > > Git is the most prevalent VCS nowadays, and most developers use it, so > > it would make sense to support it first. If you want quilt, we can > > certainly look into that. But I'm afraid if you don't say what you > > specifically need, nothing can be done in that regard. > > Well, if you thought of other than git, then I'm afraid I lack > understanding of where such a "branch" should be coming from. > My first and foremost requirement is that, as stated pretty close > to the top, the contribution workflow be *not* impacted. Any > setting up of anything that I'd need to do would be contrary to > that. > > > Second, it is up to individual whether they want to use a certain tool > > or not. If you don't want to use this infrastructure for whatever > > reason, that's OK. You're only missing out all the work in the community > > has done, but you should be able to use your own workflow just fine. > > Then I maybe misunderstood Lars'es mail: I've gained the > impression that the picking up of patches would be automatic, > i.e. without me telling to system to do so. As it would presumably > send its (failure) mails back to the author, I'd expect to get what > effectively is spam in the described case. > > I'm afraid my personal bar for any such automation is pretty > high: There must not ever be any negative effect from such an > addition. Positive effects would of course be very welcome. I > realize this is an unrealistic goal, but it should at least come > close (perhaps after some initial learning phase). But this implies > that at least in theory it is possible to come close in the first > place, which I can't take for given with the information I've been > provided so far. > > Jan I hope you're not advocating for no progress until the perfect system is achieved without giving anyone the opportunity to develop a system since its impossible to develop a perfect system in the first go. The ultimate goal here is to take patches that are posted to the mailing list, apply them on top of staging and build them against a variety of compiler combos coming from different distros. The results would then be emailed as a reply to the cover letter. The idea is that this would help maintainers/reviewers out as they could tell the submitter that it won't get reviewed until it at least compiles. The first improvement to the entire system I'd like to make is automatic code-style checking. But that is depending on clang-format landing the Xen code-style plugin. Would you at least agree that this would be useful to some maintainers and something some subset of folks would like to see? This isn't necessarily targeted at code that you personally submit but folks that are less frequent contributors. I've seen on numerous occasions a new contributor making a patch against an outdated branch and this would help there for example.
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 03:32:09PM +0100, George Dunlap wrote: > On 07/24/2018 10:34 AM, Jan Beulich wrote: > On 24.07.18 at 11:24, wrote: > >> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> On 23.07.18 at 18:40, wrote: > # How does this impact me? > The contribution workflow is *not* impacted by this change, but once up > and > >> > running the following will happen once you post a patch or patch series > to > xen-devel: > * Patchwork will take patch series from the mailing list and applies it > * CI/DC testing is triggered > * A test report will be sent as a mail to the patch or the series (aka > the 00 patch of the series) > > This does mean though that series which do not build or show other > issues, > will likely not be reviewed until the tests pass. This would lessen the > burden on reviewers, as they will know whether the code submitted builds > on a > wide array of environments. > >>> > >>> So how are dependencies between series intended to be dealt with? It > >>> is not uncommon for someone to say "applies only on top of xyz". The > >>> implication of "will likely not be reviewed until the tests pass" seems > >>> unsuitable to me in such a case. > >>> > >> > >> We have been asking everyone to rebase to staging before posting a new > >> version for a long time. It is natural for the bot to assume that > >> everything should apply on top of staging. That would provide most value > >> to the community. > >> > >> For special cases like you just mention, we should aim to provide > >> mechanisms to manually appoint a branch to be tested. > > > > I'm afraid I disagree again: Tools used should not be dictated. I'm > > using quilt, not git for my work, and hence I don't maintain any > > branches anywhere. > > Well it's never been our habit to review patch series sent against > random private branches. (x86-next not being a random private branch.) > The idea would be that you put a tag in the message somewhere that > indicates what the patchbot should do. This would probably be just the > message-id of the patch series, given that (steady state) your previous > series would have had the bot reply to it with a link. Something like this: > > Prerequisite-series: <5b506a6e0278001d5...@prv1-mh.provo.novell.com> > > If the sender doesn't add the prerequisite series, then of course it > won't apply; but the reviewer can choose to ignore the failure in that case. > > -George So fwiw, there's a tool called git-series (the author says he's working on integrating its functionality into the git upstream) that does exactly this. Most of my recent patches have been sent with it and you'll actually see what commit from staging my patches are based on and if I wanted I could record instead the message-id of a posted series it would depend on. I've spoken with the patchwork folks about support that tag as well. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On Mon, Jul 16, 2018 at 05:02:01AM -0600, Jan Beulich wrote:
> > Unfortunably there has been a crash last week:
>
> Hmm, looks to be still all the same as before (except for the line
> number). I'm afraid I'm out of ideas, at least for the moment.
OK, FYI I commited xen 4.11 packages for NetBSD, with the attached
patch. With this the hypervisor doens't panic ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
$NetBSD: patch-zz-bouyer,v 1.1 2018/07/24 13:40:11 bouyer Exp $
Dirty hack to avoid assert failure. This has been discussed on xen-devel
but no solution has been fonud so far.
The box producing http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
is running with this patch; the printk has fired but the
hypervisor keeps running.
--- xen/arch/x86/mm.c.orig 2018-07-19 10:32:07.0 +0200
+++ xen/arch/x86/mm.c 2018-07-21 20:47:47.0 +0200
@@ -674,7 +674,12 @@
typeof(pg->linear_pt_count) oc;
oc = arch_fetch_and_add(>linear_pt_count, -1);
-ASSERT(oc > 0);
+if (oc <= 0) {
+gdprintk(XENLOG_WARNING,
+ "mm.c:dec_linear_entries(): oc %d would fail assert\n", oc);
+ pg->linear_pt_count = 0;
+}
+/* ASSERT(oc > 0); */
}
static bool inc_linear_uses(struct page_info *pg)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support
On Mon, Jul 23, 2018 at 03:42:37PM +0100, Andrew Cooper wrote: > Because of a bug in 2010, LMSL support didn't functioned in Xen. > > c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In > addition to migration problems, changes to the segmentation logic for > emulation would be needed before the feature could be enabled. > > This feature is entirely unused by operating systems (probably owing to its > semantics which only cover half the segment registers), and no one has > commented on its absence from Xen. As supporting it would involve a large > amount of effort, it seems better to remove the code entirely. > > If someone finds a valid usecase, we can resurrecting the code and ^ resurrect > implementing the remaining parts, but I doubt anyone will. ^implement > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
On 07/24/2018 08:45 AM, M. Vefa Bicakci wrote:
> Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
> adjustment corruption") has moved the query and calculation of the
> x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
> from the get_cpu_cap function to a new function named
> get_cpu_address_sizes.
>
> One of the call sites related to Xen PV VMs was unfortunately missed
> in the aforementioned commit. This prevents successful boot-up of
> kernel versions 4.17 and up in Xen PV VMs if CONFIG_DEBUG_VIRTUAL
> is enabled, due to the following code path:
>
> enlighten_pv.c::xen_start_kernel
> mmu_pv.c::xen_reserve_special_pages
> page.h::__pa
> physaddr.c::__phys_addr
> physaddr.h::phys_addr_valid
>
> phys_addr_valid uses boot_cpu_data.x86_phys_bits to validate physical
> addresses. boot_cpu_data.x86_phys_bits is no longer populated before
> the call to xen_reserve_special_pages due to the aforementioned commit
> though, so the validation performed by phys_addr_valid fails, which
> causes __phys_addr to trigger a BUG, preventing boot-up.
>
> Signed-off-by: M. Vefa Bicakci
> Cc: "Kirill A. Shutemov"
> Cc: Andy Lutomirski
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: xen-devel@lists.xenproject.org
> Cc: x...@kernel.org
> Cc: sta...@vger.kernel.org # for v4.17 and up
> Fixes: d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment
> corruption")
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
On 07/24/2018 02:42 PM, Jan Beulich wrote: On 12.07.18 at 09:29, wrote: Forgot to Cc maintainers. Konrad, Ross: Ping? Jan On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote: And replace the open-coded versions already in tree. No functional change. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Daniel Kiper Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 07/24/2018 10:34 AM, Jan Beulich wrote: On 24.07.18 at 11:24, wrote: >> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: >> On 23.07.18 at 18:40, wrote: # How does this impact me? The contribution workflow is *not* impacted by this change, but once up and >> running the following will happen once you post a patch or patch series to xen-devel: * Patchwork will take patch series from the mailing list and applies it * CI/DC testing is triggered * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series) This does mean though that series which do not build or show other issues, will likely not be reviewed until the tests pass. This would lessen the burden on reviewers, as they will know whether the code submitted builds on a wide array of environments. >>> >>> So how are dependencies between series intended to be dealt with? It >>> is not uncommon for someone to say "applies only on top of xyz". The >>> implication of "will likely not be reviewed until the tests pass" seems >>> unsuitable to me in such a case. >>> >> >> We have been asking everyone to rebase to staging before posting a new >> version for a long time. It is natural for the bot to assume that >> everything should apply on top of staging. That would provide most value >> to the community. >> >> For special cases like you just mention, we should aim to provide >> mechanisms to manually appoint a branch to be tested. > > I'm afraid I disagree again: Tools used should not be dictated. I'm > using quilt, not git for my work, and hence I don't maintain any > branches anywhere. Well it's never been our habit to review patch series sent against random private branches. (x86-next not being a random private branch.) The idea would be that you put a tag in the message somewhere that indicates what the patchbot should do. This would probably be just the message-id of the patch series, given that (steady state) your previous series would have had the bot reply to it with a link. Something like this: Prerequisite-series: <5b506a6e0278001d5...@prv1-mh.provo.novell.com> If the sender doesn't add the prerequisite series, then of course it won't apply; but the reviewer can choose to ignore the failure in that case. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 11:23:34AM +, Lars Kurth wrote: > I am not quite sure what QEMU does. But I can't see any bot messages on their > list archives The bot from: is no-re...@patchew.org, for e.g.: - coding style: https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01428.html - build failure: https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01329.html Those mails are been CCed to all. Only failure are sent. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125540: all pass - PUSHED
flight 125540 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125540/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5b73e17fb17c6935d894b0084f32421e717c247f baseline version: ovmf 005c855dc6be0f61f76de0d7ec4a62ee737518d6 Last test of basis 125531 2018-07-24 01:10:54 Z0 days Testing same since 125540 2018-07-24 08:40:43 Z0 days1 attempts People who touched revisions under test: Yonghong Zhu Yunhua Feng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 005c855dc6..5b73e17fb1 5b73e17fb17c6935d894b0084f32421e717c247f -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
On Tue, Jul 24, 2018 at 07:59:30AM -0600, Jan Beulich wrote: > >>> On 24.07.18 at 15:51, wrote: > > On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote: > >> >>> On 12.07.18 at 09:29, wrote: > >> > Forgot to Cc maintainers. > >> > >> Konrad, Ross: Ping? > > > > Daniel? Anyway, I will take a look at this no later than tomorrow. > > Sorry for delay but I was swamped with other important stuff. > > Well, I was sort of implying that it might take you a little longer > to get there, but the patch here is not depending on your > double checking - that's just patch 3. Note that patch 3 has been superseded by: https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01644.html git://xenbits.xen.org/people/royger/xen.git efi.v4 Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
>
> - comment "failed to reap part..." is misleading - sounds like it's
> referring to something which happened in the past, is in fact
> referring to something which might happen in the future.
>
> - fails to call trace_finish_task_reaping() in one case
>
> - code duplication.
>
> - Increases mmap_sem hold time a little by moving
> trace_finish_task_reaping() inside the locked region. So sue me ;)
>
> - Sharing the finish: path means that the trace event won't
> distinguish between the two sources of finishing.
>
> Please take a look?
oom_reap_task_mm should return false when __oom_reap_task_mm return
false. This is what my patch did but it seems this changed by
http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
so that one should be fixed.
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 104ef4a01a55..88657e018714 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
/* failed to reap part of the address space. Try again later */
if (!__oom_reap_task_mm(mm)) {
up_read(>mmap_sem);
- return true;
+ return false;
}
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
On top of that the proposed cleanup looks as follows:
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 88657e018714..4e185a282b3d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
return ret;
}
+/*
+ * Reaps the address space of the give task.
+ *
+ * Returns true on success and false if none or part of the address space
+ * has been reclaimed and the caller should retry later.
+ */
static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
{
+ bool ret = true;
+
if (!down_read_trylock(>mmap_sem)) {
trace_skip_task_reaping(tsk->pid);
return false;
@@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
* down_write();up_write() cycle in exit_mmap().
*/
if (test_bit(MMF_OOM_SKIP, >flags)) {
- up_read(>mmap_sem);
trace_skip_task_reaping(tsk->pid);
- return true;
+ goto out_unlock;
}
trace_start_task_reaping(tsk->pid);
/* failed to reap part of the address space. Try again later */
- if (!__oom_reap_task_mm(mm)) {
- up_read(>mmap_sem);
- return false;
- }
+ ret = __oom_reap_task_mm(mm);
+ if (!ret)
+ goto out_finish;
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
K(get_mm_counter(mm, MM_FILEPAGES)),
K(get_mm_counter(mm, MM_SHMEMPAGES)));
+out_finish:
+ trace_finish_task_reaping(tsk->pid);
+out_unlock:
up_read(>mmap_sem);
- trace_finish_task_reaping(tsk->pid);
- return true;
+ return ret;
}
#define MAX_OOM_REAP_RETRIES 10
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/18 13:45, Lars Kurth wrote: On 24/07/2018, 13:00, "Jan Beulich" wrote: >>> On 24.07.18 at 13:48, wrote: > In my personal opinion, just sending CI email as "reply-all" is fine. I > do not mind having an extra email per patch in my mailbox. This is exactly what I'm afraid of - when you're Cc-ed on a lot of patches, you may then also get a lot of mails here. And no, other than suggested elsewhere, I'm never going to have a rule to push all mails matching certain criteria right into trash - there's always the risk of a false positive. It is imo _always_ the sending side which needs to judge who needs to be on the To/Cc lists of a mail, never the receiving side to "paper over" mistakes the sender has made. I believe there is quite a bit of freedom on how we would implement this. @Doug: please correct me if this is wrong. For example: we could do something like the following * Contributor sends series to xen-devel@ (or if necessary to some alias or a different new list) * Patchbot to take mail off list and run the tests * Patchbot to augment the original mail(s) with embedded test results and/or Tested-by: tags to and send it to xen-devel@ * Augmented mail to be sent to xen-devel@ as if it came from sender - although this may cause problems with some mail clients Or we could push the burden onto the contributor, e.g. * Contributor to send series to test service * Contributor will get results (including some URL pointing to results) * If succeeded or there is another good reason to send the series: Contributor to send mail to xen-devel@ with a reference to the results in the patch I would prefer the first solution. If you push the burden onto the contributor, you increase potential discrepancy between the series tested and sent. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 07/24/2018 01:45 PM, Lars Kurth wrote: > > > On 24/07/2018, 13:00, "Jan Beulich" wrote: > > >>> On 24.07.18 at 13:48, wrote: > > In my personal opinion, just sending CI email as "reply-all" is fine. I > > do not mind having an extra email per patch in my mailbox. > > This is exactly what I'm afraid of - when you're Cc-ed on a lot of > patches, you may then also get a lot of mails here. And no, other > than suggested elsewhere, I'm never going to have a rule to push > all mails matching certain criteria right into trash - there's always > the risk of a false positive. It is imo _always_ the sending side > which needs to judge who needs to be on the To/Cc lists of a mail, > never the receiving side to "paper over" mistakes the sender has > made. > > I believe there is quite a bit of freedom on how we would implement this. > > @Doug: please correct me if this is wrong. > > For example: we could do something like the following > * Contributor sends series to xen-devel@ (or if necessary to some > alias or a different new list) > * Patchbot to take mail off list and run the tests > * Patchbot to augment the original mail(s) with embedded > test results and/or Tested-by: tags to and send it to xen-devel@ > * Augmented mail to be sent to xen-devel@ as if it came from > sender - although this may cause problems with some mail > clients > > Or we could push the burden onto the contributor, e.g. > * Contributor to send series to test service > * Contributor will get results (including some URL pointing to results) > * If succeeded or there is another good reason to send the series: > Contributor to send mail to xen-devel@ with a reference to the results > in the patch I don't see what the problem is in having a single response to the thread saying that the test was run, the result of the run, and a link to a page about it. It's certainly less mail than I get in the course of a normal review cycle about patch series I'm not interested in. I mean, suppose we just had a really enthusiastic contributor who made it their personal goal to test and build every patch that was sent to the list. Would anyone really complain about a single extra mail per series, when a typical series generates dozens of human-generated mails anyway? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
>>> On 24.07.18 at 15:51, wrote: > On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote: >> >>> On 12.07.18 at 09:29, wrote: >> > Forgot to Cc maintainers. >> >> Konrad, Ross: Ping? > > Daniel? Anyway, I will take a look at this no later than tomorrow. > Sorry for delay but I was swamped with other important stuff. Well, I was sort of implying that it might take you a little longer to get there, but the patch here is not depending on your double checking - that's just patch 3. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs
Hi Stefano,
On 07/07/18 00:12, Stefano Stabellini wrote:
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU". Calls construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids.
Move the discard_initial_modules after DomUs have been built
Nit: Missing full stop.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
xen/arch/arm/domain_build.c | 38 +++---
xen/arch/arm/setup.c| 8 +++-
xen/include/asm-arm/setup.h | 3 +++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d7e9040..9f58002 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2542,6 +2543,39 @@ static int __init construct_domU(struct domain *d,
struct dt_device_node *node)
return rc;
}
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+struct dt_device_node *chosen = dt_find_node_by_name(dt_host, "chosen");
newline here.
+if ( chosen != NULL )
+{
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+d_cfg.arch.nr_spis = 32;
You can set those fields directly when defining d_cfg above.
+
+d = domain_create(max_init_domid++, _cfg);
+if ( IS_ERR(d) )
+panic("Error creating domU");
It is probably worth to add the node name in the message. So the user
knows which guest failed.
+
+d->is_privileged = 0;
+d->is_console = 1;
+d->target = NULL;
+
+if ( construct_domU(d, node) != 0 )
+printk("Could not set up DOMU guest OS");
Should not it be a panic here? Also, the message is a little odd "DOMU
guest" is a bit redundant and the function will load the kernel but
that's not the only thing done.
Lastly, you probably want to add the node name in the message, so the
user knows which guest failed.
+
+domain_unpause_by_systemcontroller(d);
If a domain is bound to CPU0, then it will not boot until CPU0 is done
with creating domain. Is that what you want?
+}
+}
+}
+
int __init construct_dom0(struct domain *d)
{
struct kernel_info kinfo = {};
@@ -2592,9 +2626,7 @@ int __init construct_dom0(struct domain *d)
return rc;
-rc = __construct_domain(d, );
-discard_initial_modules();
-return rc;
+return __construct_domain(d, );
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7739a80..0b08af2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,6 +64,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid = 0;
+
static __used void init_done(void)
{
free_init_memory();
@@ -863,7 +865,7 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
-dom0 = domain_create(0, _cfg);
+dom0 = domain_create(max_init_domid++, _cfg);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0");
@@ -889,6 +891,10 @@ void __init start_xen(unsigned long boot_phys_offset,
domain_unpause_by_systemcontroller(dom0);
Why do you unpause Dom0 and then create the guests? It feels like to me
you want to create all the guests and then unpause dom0. dom0 would
likely get blocked anyway has CPU0 will be busy creating domains.
+create_domUs();
+
+discard_initial_modules();
I think it would be better to move that in init_done. This is where all
initial memory is freed.
+
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 5ecfe27..21b9729 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -56,6 +56,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote: > >>> On 12.07.18 at 09:29, wrote: > > Forgot to Cc maintainers. > > Konrad, Ross: Ping? Daniel? Anyway, I will take a look at this no later than tomorrow. Sorry for delay but I was swamped with other important stuff. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
>>> On 12.07.18 at 09:29, wrote:
> Forgot to Cc maintainers.
Konrad, Ross: Ping?
Jan
> On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
>> And replace the open-coded versions already in tree. No functional
>> change.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Jan Beulich
>> Cc: Andrew Cooper
>> Cc: Daniel Kiper
>> ---
>> xen/include/xen/compiler.h | 2 ++
>> xen/include/xen/livepatch_payload.h | 4 ++--
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>> index a7e05681c9..001f589655 100644
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -18,6 +18,8 @@
>>
>> #define __packed __attribute__((__packed__))
>>
>> +#define __weak__attribute__((weak))
>> +
>> #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
>> #define unreachable() do {} while (1)
>> #else
>> diff --git a/xen/include/xen/livepatch_payload.h
> b/xen/include/xen/livepatch_payload.h
>> index 8f38cc2c60..4a1a96d054 100644
>> --- a/xen/include/xen/livepatch_payload.h
>> +++ b/xen/include/xen/livepatch_payload.h
>> @@ -24,7 +24,7 @@ typedef void livepatch_unloadcall_t(void);
>> * executed in series by the livepatch infrastructure at patch load time.
>> */
>> #define LIVEPATCH_LOAD_HOOK(_fn) \
>> -livepatch_loadcall_t *__attribute__((weak)) \
>> +livepatch_loadcall_t *__weak \
>> const livepatch_load_data_##_fn __section(".livepatch.hooks.load")
> = _fn;
>>
>> /*
>> @@ -33,7 +33,7 @@ typedef void livepatch_unloadcall_t(void);
>> * Same as LOAD hook with s/load/unload/
>> */
>> #define LIVEPATCH_UNLOAD_HOOK(_fn) \
>> - livepatch_unloadcall_t *__attribute__((weak)) \
>> + livepatch_unloadcall_t *__weak \
>> const livepatch_unload_data_##_fn
> __section(".livepatch.hooks.unload") = _fn;
>>
>> #endif /* __XEN_LIVEPATCH_PAYLOAD_H__ */
>> --
>> 2.17.1
>>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: correct DEFCONFIG_LIST Kconfig item
>>> On 10.07.18 at 12:18, wrote: On 10.07.18 at 10:31, wrote: >> The default value of DEFCONFIG_LIST is wrong: it should be the value of >> the configured ARCH_DEFCONFIG item, not the string "$ARCH_DEFCONFIG". > > Makse sense and matches Linux, but I'd still prefer to have Doug's > consent here. Ping? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] vhpet: add support for level triggered interrupts
>>> On 17.07.18 at 12:38, wrote: > Level triggered interrupts are not an optional feature of HPET, and > must be implemented in order to comply with the HPET specification. > > Implement them by adding a callback to the timer which sets the > interrupt bit in the general interrupt status register. Further > interrupts (in case of periodic mode) will not be injected until the > bit is cleared. > > In order to reset the interrupts when the status bit is clear Xen must > also detect accesses to such register. > > While there convert tn and i in hpet_write to unsigned. > > Reported-by: Stefan Bader > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] vpt: add support for level interrupts
>>> On 17.07.18 at 12:38, wrote: > Level trigger interrupts will be asserted regardless of whether the > interrupt is masked, and thus the callback will also be executed. > > Add a new 'level' parameter to create_periodic_time in order to create > level triggered timers. None of the current users of vpt are switched > to use level triggered interrupts yet. > > Note that periodic level triggered interrupts are not supported. This > is because level triggered interrupts always require a deassert of the > IO-APIC pin, which should be done by the caller of vpt at which point > the caller should also reset the timer if required. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs
Hello Stefano, On 07.07.18 02:13, Stefano Stabellini wrote: Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, MPSOC and ALL. They enable the required options for their hardware platform. ALL enables all available platforms and it's the default. It doesn't automatically select any of the related drivers, otherwise they cannot be disabled. ALL is implemented by selecting hidden options corresponding to QEMU, MPSOC and RCAR3. In the case of the MPSOC that has a platform file under arch/arm/platforms/, build the file if MPSOC. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com --- Changes in v5: - turn platform support into a choice - add ALL Changes in v4: - fix GICv3/GICV3 - default y to all options - build xilinx-zynqmp if MPSOC --- xen/arch/arm/Kconfig| 2 ++ xen/arch/arm/platforms/Kconfig | 55 + xen/arch/arm/platforms/Makefile | 2 +- 3 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/platforms/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2b87111..75cacfb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +source "arch/arm/platforms/Kconfig" + source "common/Kconfig" source "drivers/Kconfig" diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig new file mode 100644 index 000..07c5930 --- /dev/null +++ b/xen/arch/arm/platforms/Kconfig @@ -0,0 +1,55 @@ +choice + prompt "Platform Support" + default ALL + ---help--- + Choose which hardware platform to enable in Xen. + + If unsure, choose ALL. + +config ALL I would suggest to separate it into ALL_ARM32 and ALL_ARM64. Then, in a makefile use them for platforms instead of raw ARM32 and ARM64. This would make such change really useful: disabling ALL_x will drop all odd platform code. + bool "All Platforms" + select MPSOC_PLATFORM + select QEMU_PLATFORM + select RCAR3_PLATFORM + ---help--- + Enable support for all available hardware platforms. It doesn't + automatically select any of the related drivers. + +config QEMU + bool "QEMU aarch virt machine support" + depends on ARM_64 + select QEMU_PLATFORM + select GICV3 + select HAS_PL011 + ---help--- + Enable all the required drivers for QEMU aarch64 virt emulated + machine. + +config RCAR3 + bool "Renesas RCar3 support" + depends on ARM_64 + select RCAR3_PLATFORM + select HAS_SCIF + ---help--- + Enable all the required drivers for Renesas RCar3 + +config MPSOC + bool "Xilinx Ultrascale+ MPSoC support" + depends on ARM_64 + select MPSOC_PLATFORM + select HAS_CADENCE_UART + select ARM_SMMU + ---help--- + Enable all the required drivers for Xilinx Ultrascale+ MPSoC + +endchoice + +config QEMU_PLATFORM + bool + +config RCAR3_PLATFORM + bool + +config MPSOC_PLATFORM Shouldn't MPSOC_PLATFORM be dependent on ARM64? + bool + diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 80e555c..a79bdb9 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o obj-$(CONFIG_ARM_64) += thunderx.o obj-$(CONFIG_ARM_64) += xgene-storm.o -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o +obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/18 10:57, Lars Kurth wrote: > > On 24/07/2018, 10:46, "Wei Liu" wrote: > > On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote: > > > > > > > On 24 Jul 2018, at 10:24, Wei Liu wrote: > > > > > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > > > On 23.07.18 at 18:40, wrote: > > >>> # How does this impact me? > > >>> The contribution workflow is *not* impacted by this change, but > once up and > > >>> running the following will happen once you post a patch or patch > series to > > >>> xen-devel: > > >>> * Patchwork will take patch series from the mailing list and > applies it > > >>> * CI/DC testing is triggered > > >>> * A test report will be sent as a mail to the patch or the series > (aka the 00 patch of the series) > > >>> > > >>> This does mean though that series which do not build or show other > issues, > > >>> will likely not be reviewed until the tests pass. This would lessen > the > > >>> burden on reviewers, as they will know whether the code submitted > builds on a > > >>> wide array of environments. > > >> > > >> So how are dependencies between series intended to be dealt with? It > > >> is not uncommon for someone to say "applies only on top of xyz". The > > >> implication of "will likely not be reviewed until the tests pass" > seems > > >> unsuitable to me in such a case. > > >> > > > > > > We have been asking everyone to rebase to staging before posting a new > > > version for a long time. It is natural for the bot to assume that > > > everything should apply on top of staging. That would provide most > value > > > to the community. > > > > > > For special cases like you just mention, we should aim to provide > > > mechanisms to manually appoint a branch to be tested. > > > > Wei, Doug: I have another question, which is mainly for my own > understanding. > > > > Right now we allow posting of patches to Linux, Qemu, xen.git, > > OSSTEST, ... to xen-devel. The planned CI infrastructure only applies > > to xen.git. Have you thought about how to handle such cases? > > No. I haven't. We may be able to use some heuristics here. > > Or an alternative would be to say: if you want to use the test bot then CC > xengit-test...@xenproject.org (or something like it) when you submit the > series. That would also get around Jan's issue with dependent series: you > would simply not add the CC, when you know it won't build without a > dependency. If you require contributors to opt into automation, people will won't know or forget, and reviewers will first have to ask people to submit full series again CC'ing the correct bot. -100 to any idea which requires an opt-in. It should be active by default. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 125511: regressions - FAIL
flight 125511 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125511/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 125156 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125183 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125183 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux19e5f4da1240dcc32cda9b9022308c1b4c72e1f1 baseline version: linux060744011e93679f03932f050619744be895b772 Last test of basis 125183 2018-07-15 16:46:53 Z8 days Failing since125271 2018-07-17 10:12:19 Z7 days5 attempts Testing same since 125511 2018-07-23
[Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and calculation of the
x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
from the get_cpu_cap function to a new function named
get_cpu_address_sizes.
One of the call sites related to Xen PV VMs was unfortunately missed
in the aforementioned commit. This prevents successful boot-up of
kernel versions 4.17 and up in Xen PV VMs if CONFIG_DEBUG_VIRTUAL
is enabled, due to the following code path:
enlighten_pv.c::xen_start_kernel
mmu_pv.c::xen_reserve_special_pages
page.h::__pa
physaddr.c::__phys_addr
physaddr.h::phys_addr_valid
phys_addr_valid uses boot_cpu_data.x86_phys_bits to validate physical
addresses. boot_cpu_data.x86_phys_bits is no longer populated before
the call to xen_reserve_special_pages due to the aforementioned commit
though, so the validation performed by phys_addr_valid fails, which
causes __phys_addr to trigger a BUG, preventing boot-up.
Signed-off-by: M. Vefa Bicakci
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org # for v4.17 and up
Fixes: d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment
corruption")
---
Changes since v1:
- Move the call to get_cpu_address_sizes below the call to
x86_configure_nx.
- Amend the commit message to describe why PV VMs do not boot up
successfully when CONFIG_DEBUG_VIRTUAL is enabled.
---
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/cpu.h| 1 +
arch/x86/xen/enlighten_pv.c | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f73fa6f6d85e..dd282482de09 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -911,7 +911,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
apply_forced_caps(c);
}
-static void get_cpu_address_sizes(struct cpuinfo_x86 *c)
+void get_cpu_address_sizes(struct cpuinfo_x86 *c)
{
u32 eax, ebx, ecx, edx;
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 38216f678fc3..12a5f0cec0b2 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -46,6 +46,7 @@ extern const struct cpu_dev *const __x86_cpu_dev_start[],
*const __x86_cpu_dev_end[];
extern void get_cpu_cap(struct cpuinfo_x86 *c);
+extern void get_cpu_address_sizes(struct cpuinfo_x86 *c);
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
extern u32 get_scattered_cpuid_leaf(unsigned int level,
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 105a57d73701..ee3b00c7acda 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1256,6 +1256,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
get_cpu_cap(_cpu_data);
x86_configure_nx();
+ /* Determine virtual and physical address sizes */
+ get_cpu_address_sizes(_cpu_data);
+
/* Let's presume PV guests always boot on vCPU with id 0. */
per_cpu(xen_vcpu_id, 0) = 0;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/2018, 13:00, "Jan Beulich" wrote: >>> On 24.07.18 at 13:48, wrote: > In my personal opinion, just sending CI email as "reply-all" is fine. I > do not mind having an extra email per patch in my mailbox. This is exactly what I'm afraid of - when you're Cc-ed on a lot of patches, you may then also get a lot of mails here. And no, other than suggested elsewhere, I'm never going to have a rule to push all mails matching certain criteria right into trash - there's always the risk of a false positive. It is imo _always_ the sending side which needs to judge who needs to be on the To/Cc lists of a mail, never the receiving side to "paper over" mistakes the sender has made. I believe there is quite a bit of freedom on how we would implement this. @Doug: please correct me if this is wrong. For example: we could do something like the following * Contributor sends series to xen-devel@ (or if necessary to some alias or a different new list) * Patchbot to take mail off list and run the tests * Patchbot to augment the original mail(s) with embedded test results and/or Tested-by: tags to and send it to xen-devel@ * Augmented mail to be sent to xen-devel@ as if it came from sender - although this may cause problems with some mail clients Or we could push the burden onto the contributor, e.g. * Contributor to send series to test service * Contributor will get results (including some URL pointing to results) * If succeeded or there is another good reason to send the series: Contributor to send mail to xen-devel@ with a reference to the results in the patch Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
On 07/23/2018 11:04 AM, Boris Ostrovsky wrote: On 07/22/2018 11:57 AM, M. Vefa Bicakci wrote: On 07/21/2018 07:17 PM, M. Vefa Bicakci wrote: On 07/21/2018 05:25 PM, Boris Ostrovsky wrote: On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 439a94bf89ad..87afb000142a 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1257,6 +1257,7 @@ asmlinkage __visible void __init xen_start_kernel(void) /* Work out if we support NX */ get_cpu_cap(_cpu_data); + get_cpu_address_sizes(_cpu_data); x86_configure_nx(); Have you observed any problems without this call? get_cpu_cap() is only called here to set X86_FEATURE_NX, and is then called again, together with get_cpu_address_sizes(), from early_identify_cpu(). Thank you for the reviews! Without the call to get_cpu_address_sizes, paravirtualized virtual machines do not boot up kernels with versions 4.17 and up at all; this includes dom0 and domU. No domU logs are generated in dom0's /var/log/xen/console/ directory either, despite having earlyprintk=xen on the kernel command line for my test domU. Hello Boris, I debugged this further with a debugging version of Xen (so that I can get early kernel print-outs via the "xen_raw_console_write" function), and I found the root cause of the boot up failure. In summary, the issue is due to the following call path in version 4.17 (and higher, I assume), which the kernel goes through /only/ when CONFIG_DEBUG_VIRTUAL is enabled: enlighten_pv.c::xen_start_kernel mmu_pv.c::xen_reserve_special_pages page.h::__pa physaddr.c::__phys_addr physaddr.h::phys_addr_valid // uses boot_cpu_data.x86_phys_bits The return value of phys_addr_valid is used with the VIRTUAL_BUG_ON macro, which evaluates to BUG_ON in case CONFIG_DEBUG_VIRTUAL is enabled. Ah, that's why it hasn't been detected. It looks like the call to get_cpu_address_size is required in the xen_start_kernel function. Perhaps there is a more elegant way to resolve this issue as well. Another approach could be to check in the phys_addr_valid function whether boot_cpu_data.x86_phys_bits has been initialized or not, I think, but I am not sure about the correctness of this approach. No, I think your patch is good. The only thing I'd suggest is to move the call a few lines down. The way it is placed now may create impression that we are calling get_cpu_address_sizes() to figure out NX support. Sorry for the delay, and thank you for your comments! I will send an updated version of this patch in a few moments. Vefa ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pvh: change the order of the iommu initialization for Dom0
>>> On 24.07.18 at 13:29, wrote: > The iommu initialization will also create MMIO mappings in the Dom0 > p2m, so the paging memory pool needs to be allocated or else iommu > initialization will fail. > > Move the call to init the iommu after the Dom0 p2m has been setup in > order to solve this. > > Note that issues caused by this wrong ordering have only been seen > when using shadow paging. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests
Hello Stefano, On 23.07.18 21:32, Stefano Stabellini wrote: also the GIC and timer addresses need to be configurable. I don't remember we ever had a problem with them. But yes, this should be configurable as well. I usually refer to this (future) feature as arbitrary guest memory map. I see. -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT
>>> On 24.07.18 at 13:26, wrote:
> On 07/24/2018 09:55 AM, Jan Beulich wrote:
> On 23.07.18 at 15:48, wrote:
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
>>> {
>>> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
>>> req->u.mem_access.gla = gla;
>>> -
>>> -if ( npfec.kind == npfec_kind_with_gla )
>>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>>> -else if ( npfec.kind == npfec_kind_in_gpt )
>>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>>> }
>>> +
>>> +if ( npfec.kind == npfec_kind_with_gla )
>>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>>> +else if ( npfec.kind == npfec_kind_in_gpt )
>>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>>
>> Without explanation in the commit message and without comment
>> this change is a no-go imo: I consider it at least questionable to
>> have npfec_kind_with_gla without .gla_valid set to true. Perhaps
>> it's just a naming issue, but that would then still require half a
>> sentence to explain.
>
> The naming here is confusing, but it seems to be based on the AMD manual
> naming convention (IIRC from my skim through the manual last week).
> "With gla" in this context means, "The nested fault happend while trying
> to translate the final guest linear address of the access", as opposed
> to "The nested fault happend while trying to translate one of the page
> tables, before the guest linear address for the virtual address could be
> calculated." It's a perfectly valid setting on AMD box, in spite of the
> fact that AMD doesn't report the virt -> gla translation.
>
> I'd be in favor of renaming the variable, but that shouldn't be
> Alexandru's job.
>
> What about adding a comment like this:
>
> "Naming is confusing here; 'with_gla' simply means the fault happened as
> the result of a translating the final gla, as opposed to translating one
> of the pagetables."
Yes, that would clarify thnigs enough, I think.
>>> +{
>>> +xfree(d->arch.monitor.msr_bitmap);
>>> +return -ENOMEM;
>>> +}
>>> +radix_tree_init(p2m->mem_access_settings);
>>> +}
>>
>> What's the SVM connection here? Please don't forget that p2m-pt.c
>> also serves the shadow case. Perhaps struct p2m_domain should
>> contain a boolean indicator whether this auxiliary data structure is
>> needed?
>
> It's basically just "hap_enabled()" isn't it?
Only if we can't make it there when EPT is active.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 24.07.18 at 13:48, wrote: > In my personal opinion, just sending CI email as "reply-all" is fine. I > do not mind having an extra email per patch in my mailbox. This is exactly what I'm afraid of - when you're Cc-ed on a lot of patches, you may then also get a lot of mails here. And no, other than suggested elsewhere, I'm never going to have a rule to push all mails matching certain criteria right into trash - there's always the risk of a false positive. It is imo _always_ the sending side which needs to judge who needs to be on the To/Cc lists of a mail, never the receiving side to "paper over" mistakes the sender has made. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
Hi All! Lars Kurth writes: > On 24/07/2018, 10:06, "Jan Beulich" wrote: > >>> On 23.07.18 at 18:40, wrote: > > This does mean though that series which do not build or show other > issues, > > will likely not be reviewed until the tests pass. This would lessen the > > burden on reviewers, as they will know whether the code submitted > builds on a > > wide array of environments. > > So how are dependencies between series intended to be dealt with? It > is not uncommon for someone to say "applies only on top of xyz". The > implication of "will likely not be reviewed until the tests pass" seems > unsuitable to me in such a case. > > We should look at how this is done in communities which have systems in place > that do some off-list verification of patches, such as qemu and linux (0 day > test service). > > Obviously in such cases the test bot would return results for a fail. The > sensible thing to do would be the following: > * For the submitter of the patch to notify the reviewer(s) to highlight the > test failure/dependency > * For the reviewer to spot the dependency This would probably make sense to send notification to the address from which the Patchwork gets emails for parsing. In case of successfully passed test, the bot can send an email with "Tested-by" tag, which will appear automatically in the commit message in the patchwork (similar to "Reviewed-by"). If you do not want to have "Tested-by ci-bot", just email with free text would be fine, because it will appear on the Patchwork's web interface anyways. In such a case, we could even send CI messages *only* to the patchwork, without flooding the mailing list. And whoever interested in reviewing the patch, will just look up the email from the bot on the web page related to this patch. In my personal opinion, just sending CI email as "reply-all" is fine. I do not mind having an extra email per patch in my mailbox. --Yuri. > > In any case, the reviewer would have to decide whether to review a series > which cannot be automatically build tested off list at that stage. > > Thinking about it a bit more, there are also two places at which things can > go wrong: > a) Failure to apply the patch => this would probably be the most likely > outcome with a dependency > b) Failure to build => if there was a missing dependency then probably fail > in ALL build environments > > In other words, there should be some tell-tales for this case, which can > probably be highlighted in the bot results > > Regards > Lars > > > ___ > Minios-devel mailing list > minios-de...@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/minios-devel -- Yuri Volchkov Software Specialist NEC Europe Ltd Kurfürsten-Anlage 36 D-69115 Heidelberg ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125541: tolerable all pass - PUSHED
flight 125541 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125541/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 6e2a53afa15422ee290663dbb798c085ef7068ed baseline version: xen 61bdddb82151fbf51c58f6ebc1b4a687942c45a8 Last test of basis 125521 2018-07-23 14:01:00 Z0 days Testing same since 125541 2018-07-24 09:00:34 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 61bdddb821..6e2a53afa1 6e2a53afa15422ee290663dbb798c085ef7068ed -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-snapshot test] 75000: regressions - FAIL
flight 75000 distros-debian-snapshot real [real] http://osstest.xensource.com/osstest/logs/75000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail REGR. vs. 74981 test-amd64-i386-amd64-daily-netboot-pygrub 10 debian-di-install fail REGR. vs. 74981 Tests which did not succeed, but are not blocking: test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start fail blocked in 74981 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail like 74981 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 74981 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 74981 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 74981 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 74981 baseline version: flight 74981 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-daily-netboot-pvgrub fail test-amd64-i386-i386-daily-netboot-pvgrubfail test-amd64-i386-amd64-daily-netboot-pygrub fail test-armhf-armhf-armhf-daily-netboot-pygrub fail test-amd64-amd64-i386-daily-netboot-pygrub fail test-amd64-amd64-amd64-current-netinst-pygrubfail test-amd64-i386-amd64-current-netinst-pygrub fail test-amd64-amd64-i386-current-netinst-pygrub fail test-amd64-i386-i386-current-netinst-pygrub fail test-amd64-amd64-amd64-weekly-netinst-pygrub fail test-amd64-i386-amd64-weekly-netinst-pygrub fail test-amd64-amd64-i386-weekly-netinst-pygrub fail test-amd64-i386-i386-weekly-netinst-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/pvh: change the order of the iommu initialization for Dom0
The iommu initialization will also create MMIO mappings in the Dom0
p2m, so the paging memory pool needs to be allocated or else iommu
initialization will fail.
Move the call to init the iommu after the Dom0 p2m has been setup in
order to solve this.
Note that issues caused by this wrong ordering have only been seen
when using shadow paging.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 9a833fa4b9..f0cd63b1ec 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1093,8 +1093,6 @@ int __init dom0_construct_pvh(struct domain *d, const
module_t *image,
printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
-iommu_hwdom_init(d);
-
rc = pvh_setup_p2m(d);
if ( rc )
{
@@ -1102,6 +1100,8 @@ int __init dom0_construct_pvh(struct domain *d, const
module_t *image,
return rc;
}
+iommu_hwdom_init(d);
+
rc = pvh_load_kernel(d, image, image_headroom, initrd,
bootstrap_map(image),
cmdline, , _info);
if ( rc )
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT
On 07/24/2018 09:55 AM, Jan Beulich wrote:
On 23.07.18 at 15:48, wrote:
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
>> gla,
>> {
>> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
>> req->u.mem_access.gla = gla;
>> -
>> -if ( npfec.kind == npfec_kind_with_gla )
>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>> -else if ( npfec.kind == npfec_kind_in_gpt )
>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>> }
>> +
>> +if ( npfec.kind == npfec_kind_with_gla )
>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>> +else if ( npfec.kind == npfec_kind_in_gpt )
>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>
> Without explanation in the commit message and without comment
> this change is a no-go imo: I consider it at least questionable to
> have npfec_kind_with_gla without .gla_valid set to true. Perhaps
> it's just a naming issue, but that would then still require half a
> sentence to explain.
The naming here is confusing, but it seems to be based on the AMD manual
naming convention (IIRC from my skim through the manual last week).
"With gla" in this context means, "The nested fault happend while trying
to translate the final guest linear address of the access", as opposed
to "The nested fault happend while trying to translate one of the page
tables, before the guest linear address for the virtual address could be
calculated." It's a perfectly valid setting on AMD box, in spite of the
fact that AMD doesn't report the virt -> gla translation.
I'd be in favor of renaming the variable, but that shouldn't be
Alexandru's job.
What about adding a comment like this:
"Naming is confusing here; 'with_gla' simply means the fault happened as
the result of a translating the final gla, as opposed to translating one
of the pagetables."
[snip]
>> +{
>> +xfree(d->arch.monitor.msr_bitmap);
>> +return -ENOMEM;
>> +}
>> +radix_tree_init(p2m->mem_access_settings);
>> +}
>
> What's the SVM connection here? Please don't forget that p2m-pt.c
> also serves the shadow case. Perhaps struct p2m_domain should
> contain a boolean indicator whether this auxiliary data structure is
> needed?
It's basically just "hap_enabled()" isn't it?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU
Hi Stefano,
On 07/07/18 00:12, Stefano Stabellini wrote:
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_date and write_data functions for
initial domains: vpl011_write_data_noring is very simple and just writes
to the console, while vpl011_read_data_inring is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
Looking at the patches applied, I think there need some more comments in
the code to help a reader differentiate which method is used.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
(vpl011_write_data_noring)
- duplicate vpl011_read_data
---
xen/arch/arm/domain_build.c | 10 ++-
xen/arch/arm/vpl011.c| 185 ++-
xen/include/asm-arm/vpl011.h | 10 +++
3 files changed, 182 insertions(+), 23 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 718be48..d7e9040 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2531,7 +2531,15 @@ static int __init construct_domU(struct domain *d,
struct dt_device_node *node)
if ( rc < 0 )
return rc;
-return __construct_domain(d, );
+rc = __construct_domain(d, );
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+if ( vpl011 )
+rc = domain_vpl011_init(d, NULL);
+#endif
I don't think the #ifdef is necessary here. We want to return an error
when vpl011 is set but not the emulation compiled in.
+return rc;
}
int __init construct_dom0(struct domain *d)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index e75957f..d4aab64 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -83,6 +83,111 @@ static void vpl011_update_interrupt_status(struct domain *d)
#endif
}
+void vpl011_rx_char(struct domain *d, char c)
Please add documentation explain what the use of this function. I would
also rename it to clarify who can call it (i.e only in the case when the
backend is in Xen).
+{
+unsigned long flags;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct xencons_in *intf = vpl011->inring;
+XENCONS_RING_IDX in_cons, in_prod, in_fifo_level;
+
ASSERT(!vpl011->ring_enable);
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) ==
sizeof(intf->in) )
+{
+VPL011_UNLOCK(d, flags);
+return;
+}
+
+intf->in[xencons_mask(in_prod, sizeof(intf->in))] = c;
+intf->in_prod = in_prod + 1;
+
+in_fifo_level = xencons_queued(in_prod,
+ in_cons,
+ sizeof(intf->in));
+
+vpl011_data_avail(d, in_fifo_level, sizeof(intf->in), 0, 1024);
Where does the 1024 come from? Most likely, you want a define for it.
+VPL011_UNLOCK(d, flags);
+}
+
+static void vpl011_write_data_noring(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = >arch.vpl011;
+
+VPL011_LOCK(d, flags);
+
+printk("%c", data);
+if (data == '\n')
+printk("DOM%u: ", d->domain_id);
You want to buffer the characters here and only print on newline or when
the buffer is full. Otherwise characters will get mangled with the Xen
console output or other domains output.
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+}
+
+static uint8_t vpl011_read_data_inring(struct domain *d)
+{
I think you can avoid the duplication here by using a macro.
+unsigned long flags;
+uint8_t data = 0;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct xencons_in *intf = vpl011->inring;
+XENCONS_RING_IDX in_cons, in_prod;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+
+smp_rmb();
+
+/*
+ * It is expected that there will be data in the ring buffer when this
+ * function is called since the guest is expected to read the data register
+ * only if the TXFE flag is not set.
+ * If the guest still does read when TXFE bit is set then 0 will be
returned.
+ */
+if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
+{
+unsigned int fifo_level;
+
+data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
+in_cons += 1;
+smp_mb();
+
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
Hi Lars, On 24/07/18 11:33, Lars Kurth wrote: On 24/07/2018, 11:19, "Wei Liu" wrote: On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > I'm afraid my personal bar for any such automation is pretty > high: There must not ever be any negative effect from such an > addition. Positive effects would of course be very welcome. I > realize this is an unrealistic goal, but it should at least come > close (perhaps after some initial learning phase). But this implies > that at least in theory it is possible to come close in the first > place, which I can't take for given with the information I've been > provided so far. Then I'm afraid the only suggestion I get for you at the moment is to add a filter to dump those emails to /dev/null -- you already realised that's an unrealistic goal (at least at the beginning). Wei. First of all, there should only be mail (aka spam) if there was a failure. This seems a little strange to only send e-mail on failure. How do you differentiate between the bot has successfully tested that series and the series is still in queue then? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/2018, 11:19, "Wei Liu" wrote: On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > I'm afraid my personal bar for any such automation is pretty > high: There must not ever be any negative effect from such an > addition. Positive effects would of course be very welcome. I > realize this is an unrealistic goal, but it should at least come > close (perhaps after some initial learning phase). But this implies > that at least in theory it is possible to come close in the first > place, which I can't take for given with the information I've been > provided so far. Then I'm afraid the only suggestion I get for you at the moment is to add a filter to dump those emails to /dev/null -- you already realised that's an unrealistic goal (at least at the beginning). Wei. First of all, there should only be mail (aka spam) if there was a failure. Hopefully such failures will be fairly rare in the long term: as people learn that they are expected to submit patches that build on all platforms, one would expect that they test this *before* submitting patches. And maybe we can gradually phase this in: aka have the contributor add something like CC xengit-test...@xenproject.org to the series. At some point later, we could always trigger a CI build. Or we could add a tag in the subject line, e.g. [CI-TESTED PATCH ...] or something like it, which triggers the test run. Maybe it would also be possible that contributors can send patches to xengit-test...@xenproject.org without CC'ing xen-devel to test whether their patches would pass the CI test. Or provide some alternative to doing so. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/6] x86/HVM: implement memory read caching
>>> On 19.07.18 at 16:20, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 19 July 2018 11:49 >> @@ -1046,6 +1060,8 @@ static int __hvmemul_read( >> pfec |= PFEC_implicit; >> else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 ) >> pfec |= PFEC_user_mode; >> +if ( access_type == hvm_access_insn_fetch ) >> +pfec |= PFEC_insn_fetch; > > Since you OR the insn_fetch flag in here... > >> >> rc = hvmemul_virtual_to_linear( >> seg, offset, bytes, , access_type, hvmemul_ctxt, ); >> @@ -1059,7 +1075,8 @@ static int __hvmemul_read( >> >> rc = ((access_type == hvm_access_insn_fetch) ? >>hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) : > > ...could you not just use hvm_copy_from_guest_linear() here regardless of > access_type (and just NULL out the cache argument if it is an insn_fetch)? > > AFAICT the only reason hvm_fetch_from_guest_linear() exists is to OR the > extra flag in. Well, technically it looks like I indeed could. I'm not sure that's good idea though - the visual separation of "copy" vs "fetch" is helpful I think. Let's see if I get any opinions by others in one or the other direction. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support
On Mon, Jul 23, 2018 at 03:42:37PM +0100, Andrew Cooper wrote: > Because of a bug in 2010, LMSL support didn't functioned in Xen. > > c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In > addition to migration problems, changes to the segmentation logic for > emulation would be needed before the feature could be enabled. > > This feature is entirely unused by operating systems (probably owing to its > semantics which only cover half the segment registers), and no one has > commented on its absence from Xen. As supporting it would involve a large > amount of effort, it seems better to remove the code entirely. > > If someone finds a valid usecase, we can resurrecting the code and > implementing the remaining parts, but I doubt anyone will. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > >>> On 24.07.18 at 11:43, wrote: > > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote: > >> >>> On 24.07.18 at 11:24, wrote: > >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> >> >>> On 23.07.18 at 18:40, wrote: > >> >> > # How does this impact me? > >> >> > The contribution workflow is *not* impacted by this change, but once > >> >> > up and > >> > > >> >> > running the following will happen once you post a patch or patch > >> >> > series to > >> >> > xen-devel: > >> >> > * Patchwork will take patch series from the mailing list and applies > >> >> > it > >> >> > * CI/DC testing is triggered > >> >> > * A test report will be sent as a mail to the patch or the series > >> >> > (aka the 00 patch of the series) > >> >> > > >> >> > This does mean though that series which do not build or show other > >> >> > issues, > >> >> > will likely not be reviewed until the tests pass. This would lessen > >> >> > the > >> >> > burden on reviewers, as they will know whether the code submitted > >> >> > builds on a > >> >> > wide array of environments. > >> >> > >> >> So how are dependencies between series intended to be dealt with? It > >> >> is not uncommon for someone to say "applies only on top of xyz". The > >> >> implication of "will likely not be reviewed until the tests pass" seems > >> >> unsuitable to me in such a case. > >> >> > >> > > >> > We have been asking everyone to rebase to staging before posting a new > >> > version for a long time. It is natural for the bot to assume that > >> > everything should apply on top of staging. That would provide most value > >> > to the community. > >> > > >> > For special cases like you just mention, we should aim to provide > >> > mechanisms to manually appoint a branch to be tested. > >> > >> I'm afraid I disagree again: Tools used should not be dictated. I'm > >> using quilt, not git for my work, and hence I don't maintain any > >> branches anywhere. > > > > Alright. > > > > First, I don't think I said that only git would be supported. > > Git is the most prevalent VCS nowadays, and most developers use it, so > > it would make sense to support it first. If you want quilt, we can > > certainly look into that. But I'm afraid if you don't say what you > > specifically need, nothing can be done in that regard. > > Well, if you thought of other than git, then I'm afraid I lack > understanding of where such a "branch" should be coming from. Well even CVS has the concept of branch. Mercurial also has branch (but not the same as git branch). But I admit I was mostly thinking about git branches. It would be strange for me to not think about git as first approximation because Xen uses git as the official VCS. Anyway, I don't see much point in arguing this more. I can only say this again: if you want other tools, this can be done in principle, but at the very least you need to provide insight on your workflow, and the community will see about what to do. > My first and foremost requirement is that, as stated pretty close > to the top, the contribution workflow be *not* impacted. Any > setting up of anything that I'd need to do would be contrary to > that. > If you don't use it, you don't need to set up anything (other than a filter?), you won't be impacted. Does this make sense? > > Second, it is up to individual whether they want to use a certain tool > > or not. If you don't want to use this infrastructure for whatever > > reason, that's OK. You're only missing out all the work in the community > > has done, but you should be able to use your own workflow just fine. > > Then I maybe misunderstood Lars'es mail: I've gained the > impression that the picking up of patches would be automatic, > i.e. without me telling to system to do so. As it would presumably > send its (failure) mails back to the author, I'd expect to get what > effectively is spam in the described case. > > I'm afraid my personal bar for any such automation is pretty > high: There must not ever be any negative effect from such an > addition. Positive effects would of course be very welcome. I > realize this is an unrealistic goal, but it should at least come > close (perhaps after some initial learning phase). But this implies > that at least in theory it is possible to come close in the first > place, which I can't take for given with the information I've been > provided so far. Then I'm afraid the only suggestion I get for you at the moment is to add a filter to dump those emails to /dev/null -- you already realised that's an unrealistic goal (at least at the beginning). Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support
>>> On 23.07.18 at 16:42, wrote: > Because of a bug in 2010, LMSL support didn't functioned in Xen. > > c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In > addition to migration problems, changes to the segmentation logic for > emulation would be needed before the feature could be enabled. > > This feature is entirely unused by operating systems (probably owing to its > semantics which only cover half the segment registers), and no one has > commented on its absence from Xen. As supporting it would involve a large > amount of effort, it seems better to remove the code entirely. > > If someone finds a valid usecase, we can resurrecting the code and > implementing the remaining parts, but I doubt anyone will. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Disallow unknown MSR_EFER bits
>>> On 23.07.18 at 16:11, wrote: > On Mon, Jul 23, 2018 at 02:49:50PM +0100, Andrew Cooper wrote: >> It turns out that nothing ever prevented HVM guests from trying to set > unknown >> EFER bits. Generally, this results in a vmentry failure. >> >> For Intel hardware, all implemented bits are covered by the checks. >> >> For AMD hardware, the only EFER bit which isn't covered by the checks is TCE >> (which AFAICT is specific to AMD Fam15/16 hardware). We never advertise TCE >> in CPUID, but it isn't a security problem to have TCE unexpected enabled in >> guest context. >> >> Disallow the setting of bits outside of the EFER_KNOWN_MASK, which prevents >> any vmentry failures for guests, yielding #GP instead. >> >> Signed-off-by: Andrew Cooper > > Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware
>>> On 23.07.18 at 16:22, wrote: > On 23/07/18 15:48, Andrew Cooper wrote: >> The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data >> hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will >> always evaluate false. >> >> As a result, the default case won't disable XPTI on Intel hardware which >> advertises ARCH_CAPABILITIES_RDCL_NO. >> >> Simplify parse_xpti() to solely the setting of opt_xpti according to the >> passed string, and have init_speculation_mitigations() call >> xpti_init_default() if appropiate. Drop the force parameter, and pass caps >> instead, to avoid redundant re-reading of MSR_ARCH_CAPS. >> >> Signed-off-by: Andrew Cooper > > Reviewed-by: Juergen Gross Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] hvm/altp2m: Clarify the proper way to extend the altp2m interface
>>> On 23.07.18 at 19:09, wrote: > The altp2m functionality was originally envisioned to be used in > several different configurations, one of which was a single in-guest > agent that had full operational control of altp2m. This required the > single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests > are not allowed to make DOMCTLs. Access to this HVMOP is controlled > by a per-domain HVM_PARAM, and defaults to 'off'. > > Exposing the altp2m functionality to the guest was controversial at > the time, but was ultimately accepted. The fact that altp2m is an > HVMOP rather than a DOMCTL has caused some problems, however, for > those moving forward trying to extend the interface: Extending the > interface even for the 'external' use case now means extending an > HVMOP, which implicitly extends the surface of attack for the > 'internal' use case as well. The result has been that every addition > to this interface has also been controversial. > > Settle the controversy once and for all by documenting 1) the purpose > of the altp2m interface, and 2) how to extend it. In particular: > > * Specify that the fully in-guest agent is a target use case > > * Specify that all extensions to altp2m functionality should be subops > of the HVMOP hypercall > > * Specify that new subops should be enabled in ALTP2M_mixed mode by > default, but that this mode has not been evaluated for safety. > > Hopefully this will allow the altp2m interface to be developed further > without unnecessary controversy. > > Further discussion: > > As far as I can tell there are three possible solutions to this > controversy. > > A. Remove the 'internal' functionality as a target by converting the > current HVMOP into a DOMCTL. > > B. Have two hypercalls -- an HVMOP which contains functionality > expected to be used by the 'internal' agent, and a DOMCTL for > functionality which is expected to be used only be the 'external' > agent. > > C. Agree to add all new subops to the current hypercall (HVMOP), even > if we're not sure if they should be exposed to the guest. > > I think A is a terrible idea. Having a single in-guest agent is a > reasonable design choice, and apparently it was even implemented at > some point; we should make it straightforward for someone in the > future to pick up the work if they want to. > > I think B is also a bad idea. The people extending it at the moment > are primarily concerned with the 'external' use case. There is nobody > around to represent whether new functionality should end up in the > HVMOP or the DOMCTL, which means that by default it will end up in the > DOMCTL. If it is discovered, afterwards, that the new operations > *would* be safe and useful for the 'internal' use case, then we will > either have to duplicate them inside the HVMOP (which would be > terrible) or move the operation from the DOMCTL to the HVMOP (which > would make coding an agent against several versions a mess). > > It just makes more sense to have all the altp2m operations in a single > place, and a simple way to control whether they're available to the > 'internal' use case or not. As such, I am proposing 'C'. > > Even within that, we have several options as far as what to do with > the current interface: > > C1: Audit the current subops and make a blacklist of subops not > suitable for exposure to the guest. Future subops should be on the > blacklist unless they have been evaluated as safe for exposure. > > C2: Don't blacklist the current subops, but require that all future > subops be blacklisted unless they have been evaluated as safe for > exposure. > > C3: Don't blacklist current or future subops for the present; just > document that they need to be evaluated (and some potentially > blacklisted) before being exposed to a guest in a safety-critical > environment. > > C1 would be ideal, but there's nobody at present to do the work. > Given that, C3 has been seen as the best solution in discussion. > > Signed-off-by: George Dunlap FTR - this looks acceptable to me, but I don't think I want to ack it. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/2018, 10:34, "Jan Beulich" wrote: >>> On 24.07.18 at 11:24, wrote: > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: >> >>> On 23.07.18 at 18:40, wrote: >> > # How does this impact me? >> > The contribution workflow is *not* impacted by this change, but once up and > >> > running the following will happen once you post a patch or patch series to >> > xen-devel: >> > * Patchwork will take patch series from the mailing list and applies it >> > * CI/DC testing is triggered >> > * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series) >> > >> > This does mean though that series which do not build or show other issues, >> > will likely not be reviewed until the tests pass. This would lessen the >> > burden on reviewers, as they will know whether the code submitted builds on a >> > wide array of environments. >> >> So how are dependencies between series intended to be dealt with? It >> is not uncommon for someone to say "applies only on top of xyz". The >> implication of "will likely not be reviewed until the tests pass" seems >> unsuitable to me in such a case. >> > > We have been asking everyone to rebase to staging before posting a new > version for a long time. It is natural for the bot to assume that > everything should apply on top of staging. That would provide most value > to the community. > > For special cases like you just mention, we should aim to provide > mechanisms to manually appoint a branch to be tested. I'm afraid I disagree again: Tools used should not be dictated. I'm using quilt, not git for my work, and hence I don't maintain any branches anywhere. Jan, I have to clarify what I meant by "will likely not be reviewed until the tests pass". At the end of the day, the CI loop is simply providing reviewers with more information. Reviewers then make a decision on whether they want to review a series or not. Now in most cases, reviewers will rightly not want to review series which don't build on all platforms, which is why I added "will likely not be reviewed until the tests pass". But in some cases - such as the case of dependencies - there is a reason to still review the series. And there may be other reasons to do so. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 24.07.18 at 11:43, wrote: > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote: >> >>> On 24.07.18 at 11:24, wrote: >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: >> >> >>> On 23.07.18 at 18:40, wrote: >> >> > # How does this impact me? >> >> > The contribution workflow is *not* impacted by this change, but once up >> >> > and >> > >> >> > running the following will happen once you post a patch or patch series >> >> > to >> >> > xen-devel: >> >> > * Patchwork will take patch series from the mailing list and applies it >> >> > * CI/DC testing is triggered >> >> > * A test report will be sent as a mail to the patch or the series (aka >> >> > the 00 patch of the series) >> >> > >> >> > This does mean though that series which do not build or show other >> >> > issues, >> >> > will likely not be reviewed until the tests pass. This would lessen the >> >> > burden on reviewers, as they will know whether the code submitted >> >> > builds on a >> >> > wide array of environments. >> >> >> >> So how are dependencies between series intended to be dealt with? It >> >> is not uncommon for someone to say "applies only on top of xyz". The >> >> implication of "will likely not be reviewed until the tests pass" seems >> >> unsuitable to me in such a case. >> >> >> > >> > We have been asking everyone to rebase to staging before posting a new >> > version for a long time. It is natural for the bot to assume that >> > everything should apply on top of staging. That would provide most value >> > to the community. >> > >> > For special cases like you just mention, we should aim to provide >> > mechanisms to manually appoint a branch to be tested. >> >> I'm afraid I disagree again: Tools used should not be dictated. I'm >> using quilt, not git for my work, and hence I don't maintain any >> branches anywhere. > > Alright. > > First, I don't think I said that only git would be supported. > Git is the most prevalent VCS nowadays, and most developers use it, so > it would make sense to support it first. If you want quilt, we can > certainly look into that. But I'm afraid if you don't say what you > specifically need, nothing can be done in that regard. Well, if you thought of other than git, then I'm afraid I lack understanding of where such a "branch" should be coming from. My first and foremost requirement is that, as stated pretty close to the top, the contribution workflow be *not* impacted. Any setting up of anything that I'd need to do would be contrary to that. > Second, it is up to individual whether they want to use a certain tool > or not. If you don't want to use this infrastructure for whatever > reason, that's OK. You're only missing out all the work in the community > has done, but you should be able to use your own workflow just fine. Then I maybe misunderstood Lars'es mail: I've gained the impression that the picking up of patches would be automatic, i.e. without me telling to system to do so. As it would presumably send its (failure) mails back to the author, I'd expect to get what effectively is spam in the described case. I'm afraid my personal bar for any such automation is pretty high: There must not ever be any negative effect from such an addition. Positive effects would of course be very welcome. I realize this is an unrealistic goal, but it should at least come close (perhaps after some initial learning phase). But this implies that at least in theory it is possible to come close in the first place, which I can't take for given with the information I've been provided so far. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 17/21] xen/arm: refactor vpl011_data_avail
Hi Stefano, On 07/07/18 00:12, Stefano Stabellini wrote: Move the code to calculate in_fifo_level and out_fifo_level out of vpl011_data_avail, to the caller. This change will make it possible to reuse vpl011_data_avail with different ring structures in a later patch. Signed-off-by: Stefano Stabellini --- Changes in v2: - new patch --- xen/arch/arm/vpl011.c | 70 ++- 1 file changed, 42 insertions(+), 28 deletions(-) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 33fcaa0..e75957f 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -34,6 +34,12 @@ #include #include +static void vpl011_data_avail(struct domain *d, + XENCONS_RING_IDX in_fifo_level, + XENCONS_RING_IDX in_size, + XENCONS_RING_IDX out_fifo_level, + XENCONS_RING_IDX out_size); + Looking at the end code, I think you can avoid the declaration by adding vpl011_rx_char somewhere else. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/2018, 10:46, "Wei Liu" wrote: On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote: > > > > On 24 Jul 2018, at 10:24, Wei Liu wrote: > > > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > > On 23.07.18 at 18:40, wrote: > >>> # How does this impact me? > >>> The contribution workflow is *not* impacted by this change, but once up and > >>> running the following will happen once you post a patch or patch series to > >>> xen-devel: > >>> * Patchwork will take patch series from the mailing list and applies it > >>> * CI/DC testing is triggered > >>> * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series) > >>> > >>> This does mean though that series which do not build or show other issues, > >>> will likely not be reviewed until the tests pass. This would lessen the > >>> burden on reviewers, as they will know whether the code submitted builds on a > >>> wide array of environments. > >> > >> So how are dependencies between series intended to be dealt with? It > >> is not uncommon for someone to say "applies only on top of xyz". The > >> implication of "will likely not be reviewed until the tests pass" seems > >> unsuitable to me in such a case. > >> > > > > We have been asking everyone to rebase to staging before posting a new > > version for a long time. It is natural for the bot to assume that > > everything should apply on top of staging. That would provide most value > > to the community. > > > > For special cases like you just mention, we should aim to provide > > mechanisms to manually appoint a branch to be tested. > > Wei, Doug: I have another question, which is mainly for my own understanding. > > Right now we allow posting of patches to Linux, Qemu, xen.git, > OSSTEST, ... to xen-devel. The planned CI infrastructure only applies > to xen.git. Have you thought about how to handle such cases? No. I haven't. We may be able to use some heuristics here. Or an alternative would be to say: if you want to use the test bot then CC xengit-test...@xenproject.org (or something like it) when you submit the series. That would also get around Jan's issue with dependent series: you would simply not add the CC, when you know it won't build without a dependency. Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PVH dom0 creation fails - the system freezes
>>> On 23.07.18 at 13:50, wrote:
> For the last few days, I have been trying to get a PVH dom0 running,
> however I encountered the following problem: the system seems to
> freeze after the hypervisor boots, the screen goes black. I have tried to
> debug it via a serial console (using Minicom) and managed to get some
> more Xen output, after the screen turns black.
>
> I mention that I have tried to boot the PVH dom0 using different kernel
> images (from 4.9.0 to 4.18-rc3), different Xen versions (4.10, 4.11, 4.12).
>
> Below I attached my system / hypervisor configuration, as well as the
> output captured through the serial console, corresponding to the latest
> versions for Xen and the Linux Kernel (Xen staging and Kernel from the
> xen/tip tree).
> [...]
> (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]DMAR:[DMA Write] Request device [:00:14.0] fault addr
> 8deb3000, iommu reg = 82c00021b000
> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> (XEN) print_vtd_entries: iommu #0 dev :00:14.0 gmfn 8deb3
> (XEN) root_entry[00] = 1021c60001
> (XEN) context[a0] = 2_1021d6d001
> (XEN) l4[000] = 9c1021d6c107
> (XEN) l3[002] = 9c1021d3e107
> (XEN) l2[06f] = 9c10218c0107
> (XEN) l1[0b3] = 8000
> (XEN) l1[0b3] not present
> (XEN) Dom0 callback via changed to Direct Vector 0xf3
This might be a hint at a missing RMRR entry in the ACPI tables, as
we've seen to be the case for a number of systems (I dare to guess
that :00:14.0 is a USB controller, perhaps one with a keyboard
and/or mouse connected). You may want to play with the respective
command line option ("rmrr="). Note that "iommu_inclusive_mapping"
as you're using it does not have any meaning for PVH (see
intel_iommu_hwdom_init()).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote: > > > > On 24 Jul 2018, at 10:24, Wei Liu wrote: > > > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > > On 23.07.18 at 18:40, wrote: > >>> # How does this impact me? > >>> The contribution workflow is *not* impacted by this change, but once up > >>> and > >>> running the following will happen once you post a patch or patch series > >>> to > >>> xen-devel: > >>> * Patchwork will take patch series from the mailing list and applies it > >>> * CI/DC testing is triggered > >>> * A test report will be sent as a mail to the patch or the series (aka > >>> the 00 patch of the series) > >>> > >>> This does mean though that series which do not build or show other > >>> issues, > >>> will likely not be reviewed until the tests pass. This would lessen the > >>> burden on reviewers, as they will know whether the code submitted builds > >>> on a > >>> wide array of environments. > >> > >> So how are dependencies between series intended to be dealt with? It > >> is not uncommon for someone to say "applies only on top of xyz". The > >> implication of "will likely not be reviewed until the tests pass" seems > >> unsuitable to me in such a case. > >> > > > > We have been asking everyone to rebase to staging before posting a new > > version for a long time. It is natural for the bot to assume that > > everything should apply on top of staging. That would provide most value > > to the community. > > > > For special cases like you just mention, we should aim to provide > > mechanisms to manually appoint a branch to be tested. > > Wei, Doug: I have another question, which is mainly for my own understanding. > > Right now we allow posting of patches to Linux, Qemu, xen.git, > OSSTEST, ... to xen-devel. The planned CI infrastructure only applies > to xen.git. Have you thought about how to handle such cases? No. I haven't. We may be able to use some heuristics here. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote: > >>> On 24.07.18 at 11:24, wrote: > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> >>> On 23.07.18 at 18:40, wrote: > >> > # How does this impact me? > >> > The contribution workflow is *not* impacted by this change, but once up > >> > and > > > >> > running the following will happen once you post a patch or patch series > >> > to > >> > xen-devel: > >> > * Patchwork will take patch series from the mailing list and applies it > >> > * CI/DC testing is triggered > >> > * A test report will be sent as a mail to the patch or the series (aka > >> > the 00 patch of the series) > >> > > >> > This does mean though that series which do not build or show other > >> > issues, > >> > will likely not be reviewed until the tests pass. This would lessen the > >> > burden on reviewers, as they will know whether the code submitted builds > >> > on a > >> > wide array of environments. > >> > >> So how are dependencies between series intended to be dealt with? It > >> is not uncommon for someone to say "applies only on top of xyz". The > >> implication of "will likely not be reviewed until the tests pass" seems > >> unsuitable to me in such a case. > >> > > > > We have been asking everyone to rebase to staging before posting a new > > version for a long time. It is natural for the bot to assume that > > everything should apply on top of staging. That would provide most value > > to the community. > > > > For special cases like you just mention, we should aim to provide > > mechanisms to manually appoint a branch to be tested. > > I'm afraid I disagree again: Tools used should not be dictated. I'm > using quilt, not git for my work, and hence I don't maintain any > branches anywhere. Alright. First, I don't think I said that only git would be supported. Git is the most prevalent VCS nowadays, and most developers use it, so it would make sense to support it first. If you want quilt, we can certainly look into that. But I'm afraid if you don't say what you specifically need, nothing can be done in that regard. Second, it is up to individual whether they want to use a certain tool or not. If you don't want to use this infrastructure for whatever reason, that's OK. You're only missing out all the work in the community has done, but you should be able to use your own workflow just fine. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup
>>> On 20.07.18 at 23:15, wrote: > Exclude named output files from the Xen tree setup. > > The linkfarm.stamp content will differ between top level "make" > and "make install" invocations, due to the introduction of these > output files that are produced during the "make" build. > > Filter these out to prevent an unnecessary rebuild of the shim during > "make install". > > Signed-off-by: Christopher Clark > --- > tools/firmware/xen-dir/Makefile | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/tools/firmware/xen-dir/Makefile > b/tools/firmware/xen-dir/Makefile > index 84648c3..e490dca 100644 > --- a/tools/firmware/xen-dir/Makefile > +++ b/tools/firmware/xen-dir/Makefile > @@ -11,6 +11,9 @@ D=xen-root > LINK_DIRS=config xen > LINK_FILES=Config.mk > > +# Files to exclude from the link farm > +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map efi.lds xen.lds mkelf32 > mkreloc What about xen.efi and all of its auxiliary files? What about other generated files? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
> On 24 Jul 2018, at 10:24, Wei Liu wrote: > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > On 23.07.18 at 18:40, wrote: >>> # How does this impact me? >>> The contribution workflow is *not* impacted by this change, but once up and >>> running the following will happen once you post a patch or patch series to >>> xen-devel: >>> * Patchwork will take patch series from the mailing list and applies it >>> * CI/DC testing is triggered >>> * A test report will be sent as a mail to the patch or the series (aka the >>> 00 patch of the series) >>> >>> This does mean though that series which do not build or show other issues, >>> will likely not be reviewed until the tests pass. This would lessen the >>> burden on reviewers, as they will know whether the code submitted builds on >>> a >>> wide array of environments. >> >> So how are dependencies between series intended to be dealt with? It >> is not uncommon for someone to say "applies only on top of xyz". The >> implication of "will likely not be reviewed until the tests pass" seems >> unsuitable to me in such a case. >> > > We have been asking everyone to rebase to staging before posting a new > version for a long time. It is natural for the bot to assume that > everything should apply on top of staging. That would provide most value > to the community. > > For special cases like you just mention, we should aim to provide > mechanisms to manually appoint a branch to be tested. Wei, Doug: I have another question, which is mainly for my own understanding. Right now we allow posting of patches to Linux, Qemu, xen.git, OSSTEST, ... to xen-devel. The planned CI infrastructure only applies to xen.git. Have you thought about how to handle such cases? We probably don't want to spam Linux and Qemu lists with results from a test bot. And we want to minimise false positives. Some patches may be identifiable through subject lines (e.g. OSSTEST in subject lines) Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 24.07.18 at 11:24, wrote: > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: >> >>> On 23.07.18 at 18:40, wrote: >> > # How does this impact me? >> > The contribution workflow is *not* impacted by this change, but once up >> > and > >> > running the following will happen once you post a patch or patch series to >> > xen-devel: >> > * Patchwork will take patch series from the mailing list and applies it >> > * CI/DC testing is triggered >> > * A test report will be sent as a mail to the patch or the series (aka the >> > 00 patch of the series) >> > >> > This does mean though that series which do not build or show other issues, >> > will likely not be reviewed until the tests pass. This would lessen the >> > burden on reviewers, as they will know whether the code submitted builds >> > on a >> > wide array of environments. >> >> So how are dependencies between series intended to be dealt with? It >> is not uncommon for someone to say "applies only on top of xyz". The >> implication of "will likely not be reviewed until the tests pass" seems >> unsuitable to me in such a case. >> > > We have been asking everyone to rebase to staging before posting a new > version for a long time. It is natural for the bot to assume that > everything should apply on top of staging. That would provide most value > to the community. > > For special cases like you just mention, we should aim to provide > mechanisms to manually appoint a branch to be tested. I'm afraid I disagree again: Tools used should not be dictated. I'm using quilt, not git for my work, and hence I don't maintain any branches anywhere. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT
>>> On 24.07.18 at 11:28, wrote:
> On 07/24/2018 11:55 AM, Jan Beulich wrote:
>>> +if ( cpu_has_svm && !p2m->mem_access_settings )
>>> +{
>>> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
>>> +
>>> +if( !p2m->mem_access_settings )
>> Style.
>>
>>> +{
>>> +xfree(d->arch.monitor.msr_bitmap);
>>> +return -ENOMEM;
>>> +}
>>> +radix_tree_init(p2m->mem_access_settings);
>>> +}
>> What's the SVM connection here? Please don't forget that p2m-pt.c
>> also serves the shadow case. Perhaps struct p2m_domain should
>> contain a boolean indicator whether this auxiliary data structure is
>> needed?
>
> Would it not work to simply check for "if ( cpu_has_svm &&
> p2m_is_hostp2m(p2m) && !p2m->mem_access_settings )" here?
>
> In the shadow case, will not p2m->p2m_class be p2m_nested?
Maybe, but that wasn't the point of my remark. I want to
get rid of the cpu_has_svm here, not have it amended.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 24.07.18 at 11:14, wrote: > On 24/07/18 10:06, Jan Beulich wrote: > On 23.07.18 at 18:40, wrote: >>> # How does this impact me? >>> The contribution workflow is *not* impacted by this change, but once up and >>> running the following will happen once you post a patch or patch series to >>> xen-devel: >>> * Patchwork will take patch series from the mailing list and applies it >>> * CI/DC testing is triggered >>> * A test report will be sent as a mail to the patch or the series (aka the > 00 patch of the series) >>> >>> This does mean though that series which do not build or show other issues, >>> will likely not be reviewed until the tests pass. This would lessen the >>> burden on reviewers, as they will know whether the code submitted builds on > a >>> wide array of environments. >> So how are dependencies between series intended to be dealt with? It >> is not uncommon for someone to say "applies only on top of xyz". The >> implication of "will likely not be reviewed until the tests pass" seems >> unsuitable to me in such a case. > > 99% of submissions aren't "applies on top of xyz". > > Alternative, how about we see about not blocking underlying patches for > unreasonable periods of time? Well, I'm all for it, but I don't expect us to get there any time soon. Just take the recent example of my indirect call patching series depending on another series that I had submitted over 4 months ago. Along those lines, the oldest (non-RFC) series I have in my to-be- reviewed folder is from November - what if the author submitted anything depending on it? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT
On 07/24/2018 11:55 AM, Jan Beulich wrote:
>> +if ( cpu_has_svm && !p2m->mem_access_settings )
>> +{
>> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
>> +
>> +if( !p2m->mem_access_settings )
> Style.
>
>> +{
>> +xfree(d->arch.monitor.msr_bitmap);
>> +return -ENOMEM;
>> +}
>> +radix_tree_init(p2m->mem_access_settings);
>> +}
> What's the SVM connection here? Please don't forget that p2m-pt.c
> also serves the shadow case. Perhaps struct p2m_domain should
> contain a boolean indicator whether this auxiliary data structure is
> needed?
Would it not work to simply check for "if ( cpu_has_svm &&
p2m_is_hostp2m(p2m) && !p2m->mem_access_settings )" here?
In the shadow case, will not p2m->p2m_class be p2m_nested?
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/2018, 10:06, "Jan Beulich" wrote: >>> On 23.07.18 at 18:40, wrote: > This does mean though that series which do not build or show other issues, > will likely not be reviewed until the tests pass. This would lessen the > burden on reviewers, as they will know whether the code submitted builds on a > wide array of environments. So how are dependencies between series intended to be dealt with? It is not uncommon for someone to say "applies only on top of xyz". The implication of "will likely not be reviewed until the tests pass" seems unsuitable to me in such a case. We should look at how this is done in communities which have systems in place that do some off-list verification of patches, such as qemu and linux (0 day test service). Obviously in such cases the test bot would return results for a fail. The sensible thing to do would be the following: * For the submitter of the patch to notify the reviewer(s) to highlight the test failure/dependency * For the reviewer to spot the dependency In any case, the reviewer would have to decide whether to review a series which cannot be automatically build tested off list at that stage. Thinking about it a bit more, there are also two places at which things can go wrong: a) Failure to apply the patch => this would probably be the most likely outcome with a dependency b) Failure to build => if there was a missing dependency then probably fail in ALL build environments In other words, there should be some tell-tales for this case, which can probably be highlighted in the bot results Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >>> On 23.07.18 at 18:40, wrote: > > # How does this impact me? > > The contribution workflow is *not* impacted by this change, but once up and > > running the following will happen once you post a patch or patch series to > > xen-devel: > > * Patchwork will take patch series from the mailing list and applies it > > * CI/DC testing is triggered > > * A test report will be sent as a mail to the patch or the series (aka the > > 00 patch of the series) > > > > This does mean though that series which do not build or show other issues, > > will likely not be reviewed until the tests pass. This would lessen the > > burden on reviewers, as they will know whether the code submitted builds on > > a > > wide array of environments. > > So how are dependencies between series intended to be dealt with? It > is not uncommon for someone to say "applies only on top of xyz". The > implication of "will likely not be reviewed until the tests pass" seems > unsuitable to me in such a case. > We have been asking everyone to rebase to staging before posting a new version for a long time. It is natural for the bot to assume that everything should apply on top of staging. That would provide most value to the community. For special cases like you just mention, we should aim to provide mechanisms to manually appoint a branch to be tested. Wei. > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On 24/07/18 10:06, Jan Beulich wrote: On 23.07.18 at 18:40, wrote: >> # How does this impact me? >> The contribution workflow is *not* impacted by this change, but once up and >> running the following will happen once you post a patch or patch series to >> xen-devel: >> * Patchwork will take patch series from the mailing list and applies it >> * CI/DC testing is triggered >> * A test report will be sent as a mail to the patch or the series (aka the >> 00 patch of the series) >> >> This does mean though that series which do not build or show other issues, >> will likely not be reviewed until the tests pass. This would lessen the >> burden on reviewers, as they will know whether the code submitted builds on >> a >> wide array of environments. > So how are dependencies between series intended to be dealt with? It > is not uncommon for someone to say "applies only on top of xyz". The > implication of "will likely not be reviewed until the tests pass" seems > unsuitable to me in such a case. 99% of submissions aren't "applies on top of xyz". Alternative, how about we see about not blocking underlying patches for unreasonable periods of time? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
>>> On 23.07.18 at 18:40, wrote: > # How does this impact me? > The contribution workflow is *not* impacted by this change, but once up and > running the following will happen once you post a patch or patch series to > xen-devel: > * Patchwork will take patch series from the mailing list and applies it > * CI/DC testing is triggered > * A test report will be sent as a mail to the patch or the series (aka the 00 > patch of the series) > > This does mean though that series which do not build or show other issues, > will likely not be reviewed until the tests pass. This would lessen the > burden on reviewers, as they will know whether the code submitted builds on a > wide array of environments. So how are dependencies between series intended to be dealt with? It is not uncommon for someone to say "applies only on top of xyz". The implication of "will likely not be reviewed until the tests pass" seems unsuitable to me in such a case. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT
>>> On 23.07.18 at 15:48, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
> {
> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
> req->u.mem_access.gla = gla;
> -
> -if ( npfec.kind == npfec_kind_with_gla )
> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
> -else if ( npfec.kind == npfec_kind_in_gpt )
> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
> }
> +
> +if ( npfec.kind == npfec_kind_with_gla )
> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
> +else if ( npfec.kind == npfec_kind_in_gpt )
> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
Without explanation in the commit message and without comment
this change is a no-go imo: I consider it at least questionable to
have npfec_kind_with_gla without .gla_valid set to true. Perhaps
it's just a naming issue, but that would then still require half a
sentence to explain.
> @@ -366,8 +366,11 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn,
> uint32_t nr,
> /* If request to set default access. */
> if ( gfn_eq(gfn, INVALID_GFN) )
> {
> -p2m->default_access = a;
> -return 0;
> +if ( (rc = p2m->check_access(a)) == 0 )
> +{
> +p2m->default_access = a;
> +return 0;
> +}
> }
This latching into rc makes subsequent code yield inconsistent
behavior.
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -667,6 +667,12 @@ bool_t ept_handle_misconfig(uint64_t gpa)
> return spurious ? (rc >= 0) : (rc > 0);
> }
>
> +int ept_check_access(p2m_access_t p2ma)
> +{
> +/* All access is permitted */
> +return 0;
> +}
With this I'd rather see the hook omitted here, to avoid the indirect
call. Perhaps you'll want a wrapper around the indirect call, abstracting
away the NULL check for callers.
> +static void p2m_set_access(struct p2m_domain *p2m, unsigned long gfn,
> + p2m_access_t a)
> +{
> +int rc;
> +
> +if ( !p2m->mem_access_settings )
> +return;
No error indication?
> +if ( p2m_access_rwx == a )
> +{
> +radix_tree_delete(p2m->mem_access_settings, gfn);
> +return;
> +}
Is it really p2m_access_rwx that you want to special case here, rather
than ->default_access?
> @@ -31,6 +34,18 @@ int arch_monitor_init_domain(struct domain *d)
> if ( !d->arch.monitor.msr_bitmap )
> return -ENOMEM;
>
> +if ( cpu_has_svm && !p2m->mem_access_settings )
> +{
> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
> +
> +if( !p2m->mem_access_settings )
Style.
> +{
> +xfree(d->arch.monitor.msr_bitmap);
> +return -ENOMEM;
> +}
> +radix_tree_init(p2m->mem_access_settings);
> +}
What's the SVM connection here? Please don't forget that p2m-pt.c
also serves the shadow case. Perhaps struct p2m_domain should
contain a boolean indicator whether this auxiliary data structure is
needed?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v13 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func
>>> On 19.07.18 at 16:08, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1026,24 +1026,32 @@ static int viridian_load_domain_ctxt(struct domain
> *d, hvm_domain_context_t *h)
> HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
>viridian_load_domain_ctxt, 1, HVMSR_PER_DOM);
>
> -static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +static int viridian_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t
> *h)
> {
> -struct vcpu *v;
> +struct hvm_viridian_vcpu_context ctxt = {};
>
> -if ( !is_viridian_domain(d) )
> +if ( !is_viridian_domain(v->domain) )
> return 0;
>
> -for_each_vcpu( d, v ) {
> -struct hvm_viridian_vcpu_context ctxt = {
> -.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw,
> -.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending,
> -};
> +ctxt.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw;
> +ctxt.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending;
>
> -if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
> -return 1;
> +return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, );
> +}
> +
> +static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +struct vcpu *v;
> +int err = 0;
> +
> +for_each_vcpu ( d, v ) {
Style.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v13 02/11] x86/hvm: Introduce hvm_save_tsc_adjust_one() func
>>> On 19.07.18 at 16:08, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -740,16 +740,23 @@ void hvm_domain_destroy(struct domain *d)
> destroy_vpci_mmcfg(d);
> }
>
> +static int hvm_save_tsc_adjust_one(struct vcpu *v, hvm_domain_context_t *h)
> +{
> +struct hvm_tsc_adjust ctxt = {};
> +
> +ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
Considering earlier comments, why is this still not part of the
initializer?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
Hi Daniel,
I think the main questions here are:
1. Do we need a separated KConfig option for SILO
2. Can we use indirect call like "dummy_xsm_ops.grant_copy"
Any suggestion?
Best regards
Xin(Talons) Li
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Monday, July 2, 2018 5:39 PM
> > To: Xin Li (Talons) ; Xin Li
> > Cc: Andrew Cooper ; George Dunlap
> > ; Ming Lu ; Sergey
> > Dyasli ; Wei Liu ;
> > Stefano Stabellini ; xen-de...@lists.xen.org;
> > Konrad Rzeszutek Wilk ; Daniel de Graaf
> > ; Tim
> > (Xen.org)
> > Subject: RE: [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
> >
> > >>> On 02.07.18 at 11:22, wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Monday, July 2, 2018 3:29 PM
> > >> >>> On 02.07.18 at 08:57, wrote:
> > >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> >> Sent: Friday, June 29, 2018 6:36 PM
> > >> >> >>> On 29.06.18 at 11:28, wrote:
> > >> >> > When SILO is enabled, there would be no page-sharing between
> > >> >> > unprivileged VMs (no grant tables or event channels).
> > >> >>
> > >> >> What is the relation between page sharing and event channels?
> > >> >
> > >> > They are the two mechanisms exist for inter-domain communication,
> > >> > And we want to block them in SILO mode.
> > >>
> > >> I understand this, but it doesn't answer my question. I agree that
> > >> grant tables are a means to share pages, but the wording looks odd
> > >> to me wrt event channels.
> > > Do you mean add " or event notifications", When SILO is enabled,
> > > there would be no page-sharing or event notifications between
> > > unprivileged VMs (no grant tables or event channels).
> >
> > Yes, that's one way to clarify things.
> >
> > >> > Change to:
> > >> >
> > >> > config XSM_SILO
> > >> >>---def_bool y
> > >> >>---prompt "SILO support"
> > >> >>---depends on XSM
> > >> >>--help---
> > >> >>--- Enables SILO as the access control mechanism used by the
> > >> >>XSM
> > >> framework.
> > >> >>--- This is not the default module, add boot parameter
> > >> >>xsm=silo to choose
> > >> >>--- it. This will deny any unmediated communication channels
> > >> >>(grant tables
> > >> >>--- and event channels) between unprivileged VMs.
> > >>
> > >> With s/module/mode/ this is an improvement, but continues to leave
> > >> open in particular what an "unmediated communication channel" is.
> > > This can't prevent side-channel attack.
> >
> > ???
> >
> > >> Btw, thinking about it again - do we need a Kconfig option here in
> > >> the first place, when the mode isn't the default, and it's not a
> > >> whole lot of code
> > > that gets
> > >> added?
> > > The existing XSM code use Kconfig,
> > > I just want to follow the similar style for new module.
> > > And yes, we can handle it in CONFIG_XSM like dummy.
> > > Which way is better?
> >
> > Daniel, Andrew?
> >
> > >> >> > +static bool silo_mode_dom_check(domid_t ldom, domid_t rdom) {
> > >> >> > +domid_t hd_dom = hardware_domain->domain_id;
> > >> >>
> > >> >> I don't think you mean the hardware domain here, but the control
> > >> >> domain (of which in theory there may be multiple).
> > >> >
> > >> > I mean the one and only dom0.
> > >>
> > >> No, for the purpose here you don't mean Dom0, which just happens to
> > >> be both hardware and (the only) control domain in most setups. From
> > >> a security pov though you need to distinguish all of these.
> > >
> > > Yes! thanks.
> > > I will use
> > > is_control_domain(d)
> > > instead of comparing the hardware domain id.
> > >
> > > This comment is misleading then:
> > > /* Is this guest fully privileged (aka dom0)? */
> > >bool is_privileged;
> >
> > Yes, but it's likely going to remain that way until further
> > disaggregation work would happen.
> >
> > >> >> > +domid_t cur_dom = current->domain->domain_id;
> > >> >> > +
> > >> >> > +if ( ldom == DOMID_SELF )
> > >> >> > +ldom = cur_dom;
> > >> >> > +if ( rdom == DOMID_SELF )
> > >> >> > +rdom = cur_dom;
> > >> >> > +
> > >> >> > +return (hd_dom == cur_dom || hd_dom == ldom || hd_dom ==
> > >> >> > + rdom
> > >> ||
> > >> >> > +ldom == rdom);
> > >> >> > +}
> > >> >> > +
> > >> >> > +static int silo_evtchn_unbound(struct domain *d1, struct evtchn
> > >> >> > *chn,
> > >> >> > + domid_t id2) {
> > >> >> > +if ( silo_mode_dom_check(d1->domain_id, id2) )
> > >> >> > +return dummy_xsm_ops.evtchn_unbound(d1, chn, id2);
> > >> >>
> > >> >> Urgh. Why is this not xsm_evtchn_unbound() from dummy.h? It
> > >> >> would be really nice to avoid such extra indirect calls here.
> > >> >
> > >> > This makes it clearer that we are calling the counterpart of
> > >> > dummy ops(overriding).
> > >>
> > >> Yes, but the same level of clarity could be achieved when naming
> > >> the function in dummy.h dummy_evtchn_unbound() (aliased to
> > >>
Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
>>> On 23.07.18 at 12:45, wrote: > I think the main questions here are: > 1. Do we need a separated KConfig option for SILO > 2. Can we use indirect call like "dummy_xsm_ops.grant_copy" > Any suggestion? I'm afraid the addressing of your mail is misleading: I've voiced my opinion, so I'm unlikely the one you've meant to be on the To list. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
