[linux-linus test] 151889: regressions - FAIL
flight 151889 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151889/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 build-i386-pvops 6 kernel-build fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 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-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151214 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check
[ovmf test] 151898: all pass - PUSHED
flight 151898 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151898/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 256c4470f86e53661c070f8c64a1052e975f9ef0 baseline version: ovmf 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1 Last test of basis 151881 2020-07-14 03:39:27 Z0 days Testing same since 151898 2020-07-14 17:42:39 Z0 days1 attempts People who touched revisions under test: Michael D Kinney 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 9c6f3545ae..256c4470f8 256c4470f86e53661c070f8c64a1052e975f9ef0 -> xen-tested-master
[xen-unstable test] 151884: tolerable FAIL - PUSHED
flight 151884 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151884/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151854 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151854 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151854 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 151854 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151854 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151854 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151854 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151854 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151854 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151854 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass version targeted for testing: xen 165f3afbfc3db70fcfdccad07085cde0a03c858b baseline version: xen 02d69864b51a4302a148c28d6d391238a6778b4b Last test of basis 151854 2020-07-13 01:51:12 Z1 days Testing same since 151869 2020-07-13 17:06:25 Z1 days2 attempts People who touched revisions under test: Ian Jackson jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [BUG] Xen build for RCAR failing
Hello [Sorry for the possible format issues] On Tue, Jul 14, 2020 at 4:44 PM Manikandan Chockalingam (RBEI/ECF3) < manikandan.chockalin...@in.bosch.com> wrote: > Hello Bertrand, > > I succeeded in building the core minimal image with dunfell and its > compatible branches [except xen-troops (modified some files to complete the > build)]. > > But I face the following error while booting. > > (XEN) > (XEN) Panic on CPU 0: > (XEN) Timer: Unable to retrieve IRQ 0 from the device tree > (XEN) > The reason for that problem *might* be in the arch timer node in your device tree which contains "interrupts-extended" property instead of just "interrupts". As far as I remember Xen v4.12 doesn't have required support to handle "interrupts-extended". It went in a bit later [1]. If this is the real reason, I think you should either switch to the new Xen version or modify your arch timer node in a way to use the "interrupts" property [2]. I would suggest using the new Xen version if possible (at least v4.13). [1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01775.html [2] https://github.com/otyshchenko1/linux/commit/c25044845f2c3678f5df789881e7a125556af6fc -- Regards, Oleksandr Tyshchenko
[qemu-mainline bisection] complete test-amd64-amd64-qemuu-nested-intel
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-qemuu-nested-intel testid debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151897/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-arm...@redhat.com> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install --summary-out=tmp/151897.bisection-summary --basis-template=151065 --blessings=real,real-bisect qemu-mainline test-amd64-amd64-qemuu-nested-intel debian-hvm-install Searching for failure / basis pass: 151874 fail [host=albana0] / 151149 ok. Failure / basis pass flights: 151874 / 151149 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d9a4084544134eea50f62e88d79c466ae91f0455 3c659044118e34603161457db9934a34f816d78b 20c1df5476e1e9b5d3f5b94f9f3ce01d21f14c46 88ab0c15525ced2eefe39220742efe4769089ad8 02d69864b51a4302a148c28d6d391238a6778b4b Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9af1064995d479df92e399a682ba7e4b2fc78415 3c659044118e34603161457db9934a34f816d78b 7d3660e79830a069f1848bb4fa1cdf8f666424fb 2e3de6253422112ae43e608661ba94ea6b345694 b91825f628c9a62cf2a3a0d972ea81484a8b7fce Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#9af1064995d479df92e399a682ba7e4b2fc78415-d9a4084544134eea50f62e88d79c466ae91f0455 git://xenbits.xen.org/qemu-xen-traditional.git#3c659044118e34603161457db99\ 34a34f816d78b-3c659044118e34603161457db9934a34f816d78b git://git.qemu.org/qemu.git#7d3660e79830a069f1848bb4fa1cdf8f666424fb-20c1df5476e1e9b5d3f5b94f9f3ce01d21f14c46 git://xenbits.xen.org/osstest/seabios.git#2e3de6253422112ae43e608661ba94ea6b345694-88ab0c15525ced2eefe39220742efe4769089ad8 git://xenbits.xen.org/xen.git#b91825f628c9a62cf2a3a0d972ea81484a8b7fce-02d69864b51a4302a148c28d6d391238a6778b4b Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of
RE: [BUG] Xen build for RCAR failing
Hello Bertrand, I succeeded in building the core minimal image with dunfell and its compatible branches [except xen-troops (modified some files to complete the build)]. But I face the following error while booting. (XEN) (XEN) Panic on CPU 0: (XEN) Timer: Unable to retrieve IRQ 0 from the device tree (XEN) My Build Configuration: BB_VERSION = "1.46.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-poky-linux" MACHINE = "salvator-x" DISTRO = "poky" DISTRO_VERSION = "3.1.1" TUNE_FEATURES= "aarch64 cortexa57-cortexa53" TARGET_FPU = "" SOC_FAMILY = "rcar-gen3:r8a7795" meta meta-poky meta-yocto-bsp = "tmp:39d7cf1abb2c88baaedb3a627eba8827747b2eb9" meta-rcar-gen3 = "dunfell-dev:2b3b0447fbc6c360a43a13525ae63a253fe3e5b7" meta-oe meta-python meta-filesystems meta-networking = "tmp:cc6fc6b1641ab23089c1e3bba11e0c6394f0867c" meta-selinux = "dunfell:7af62c91d7d00a260cf28e7908955539304d100d" meta-virtualization = "dunfell:ffd787fb850e5a1657a01febc8402c74832147a1" meta-rcar-gen3-xen = "master:60699c631d541aeeaebaeec9a087efed9385ee42" May I know the reason for this error? Am I missing something here? Attaching complete logs for reference. Mit freundlichen Grüßen / Best regards Chockalingam Manikandan ES-CM Core fn,ADIT (RBEI/ECF3) Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | www.bosch.com Tel. +91 80 6136-4452 | Fax +91 80 6617-0711 | manikandan.chockalin...@in.bosch.com Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung, Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller -Original Message- From: Manikandan Chockalingam (RBEI/ECF3) Sent: Friday, July 10, 2020 9:56 AM To: 'Bertrand Marquis' Cc: xen-de...@lists.xen.org; nd Subject: RE: [BUG] Xen build for RCAR failing Hello Bertrand, I couldn't find dunfell branch in the following repos 1. meta-selinux 2. xen-troops 3. meta-renesas [I took dunfell-dev] Mit freundlichen Grüßen / Best regards Chockalingam Manikandan ES-CM Core fn,ADIT (RBEI/ECF3) Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | www.bosch.com Tel. +91 80 6136-4452 | Fax +91 80 6617-0711 | manikandan.chockalin...@in.bosch.com Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung, Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller -Original Message- From: Bertrand Marquis Sent: Tuesday, July 7, 2020 5:18 PM To: Manikandan Chockalingam (RBEI/ECF3) Cc: xen-de...@lists.xen.org; nd Subject: Re: [BUG] Xen build for RCAR failing > On 7 Jul 2020, at 11:18, Manikandan Chockalingam (RBEI/ECF3) > wrote: > > Hello Bertrand, > > Thank you. I will try a fresh build with dunfell branch. All layers in the > sense [poky, meta-openembedded, meta-linaro, meta-rensas, > meta-virtualisation, meta-selinux, xen-troops] right? right > > Also, Can I use the same proprietary drivers which I used for > yocto2.19[R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20170427.zip] > for this branch? I have no idea what is in that but i would guess it will probably not work that easily. You might need to get in contact with Renesas to get more up-to-date instructions on how to build that. Bertrand [0.000149] NOTICE: BL2: R-Car H3 Initial Program Loader(CA57) [0.004585] NOTICE: BL2: Initial Program Loader(Rev.2.0.6) [0.010119] NOTICE: BL2: PRR is R-Car H3 Ver.2.0 [0.014787] NOTICE: BL2: Board is Salvator-X Rev.1.0 [0.019814] NOTICE: BL2: Boot device is HyperFlash(160MHz) [0.025325] NOTICE: BL2: LCM state is CM [0.029368] NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x53 [0.035384] NOTICE: BL2: DDR3200(rev.0.40) [0.050722] NOTICE: BL2: [COLD_BOOT] [0.059497] NOTICE: BL2: DRAM Split is 4ch [0.062192] NOTICE: BL2: QoS is default setting(rev.0.21) [0.067635] NOTICE: BL2: DRAM refresh interval 1.95 usec [0.072992] NOTICE: BL2: Periodic Write DQ Training [0.078023] NOTICE: BL2: v1.5(release):af9f429 [0.082410] NOTICE: BL2: Built : 07:07:22, Jul 14 2020 [0.087597] NOTICE: BL2: Normal boot [0.091238] NOTICE: BL2: dst=0xe6325100 src=0x818 len=512(0x200) [0.097623] NOTICE: BL2: dst=0x43f0 src=0x8180400 len=6144(0x1800) [0.104233]
[ovmf test] 151881: all pass - PUSHED
flight 151881 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151881/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1 baseline version: ovmf d9a4084544134eea50f62e88d79c466ae91f0455 Last test of basis 151867 2020-07-13 16:09:22 Z1 days Testing same since 151881 2020-07-14 03:39:27 Z0 days1 attempts People who touched revisions under test: Ray Ni 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 d9a4084544..9c6f3545ae 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1 -> xen-tested-master
[libvirt test] 151883: regressions - FAIL
flight 151883 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151883/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-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-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: libvirt 2f470a4fb1edbe2da702e398314b9db201bb991e baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z4 days Failing since151818 2020-07-11 04:18:52 Z3 days4 attempts Testing same since 151883 2020-07-14 04:19:11 Z0 days1 attempts People who touched revisions under test: Bastien Orivel Boris Fiuczynski Daniel Henrique Barboza Jin Yan Laine Stump Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Prathamesh Chavan 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 test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1010 lines long.)
[xen-4.14-testing baseline test] 151892: tolerable FAIL
"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 151892 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151892/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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 13 migrate-support-checkfail never pass test-arm64-arm64-xl 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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-win7-amd64 17 guest-stop fail 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-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 02d69864b51a4302a148c28d6d391238a6778b4b baseline version: xen 02d69864b51a4302a148c28d6d391238a6778b4b Last test of basis 151892 2020-07-14 09:21:35 Z0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [PATCH v6 00/11] Implement support for external IPT monitoring
On Tue, Jul 14, 2020 at 03:11:55PM +0200, Michał Leszczyński wrote: > Kind reminder about this new patch version for external IPT monitoring. It's on my queue, but with XenSummit I haven't been able to take a look, will try to do between today and tomorrow. Roger.
Re: [PATCH v2 7/7] x86: only generate compat headers actually needed
On Wed, Jul 01, 2020 at 12:28:27PM +0200, Jan Beulich wrote: > As was already the case for XSM/Flask, avoid generating compat headers > when they're not going to be needed. To address resulting build issues > - move compat/hvm/dm_op.h inclusion to the only source file needing it, > - add a little bit of #ifdef-ary. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné TBH I wouldn't mind generating the compat headers even when not actually used by the build, sometimes is useful to have them for review context without having to play with the build options. Thanks.
Re: [PATCH v2 6/7] flask: drop dead compat translation code
On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote: > Translation macros aren't needed at all (or else a devicetree_label > entry would have been missing), and userlist has been removed quite some > time ago. > > No functional change. > > Signed-off-by: Jan Beulich > > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -148,14 +148,11 @@ > ?xenoprof_init xenoprof.h > ?xenoprof_passivexenoprof.h > ?flask_accessxsm/flask_op.h > -!flask_boolean xsm/flask_op.h > ?flask_cache_stats xsm/flask_op.h > ?flask_hash_statsxsm/flask_op.h > -!flask_load xsm/flask_op.h > ?flask_ocontext xsm/flask_op.h > ?flask_peersid xsm/flask_op.h > ?flask_relabel xsm/flask_op.h > ?flask_setavc_threshold xsm/flask_op.h > ?flask_setenforcexsm/flask_op.h > -!flask_sid_context xsm/flask_op.h > ?flask_transitionxsm/flask_op.h Shouldn't those become checks then? Sorry I realize my knowledge of all this compat stuff is very poor. Thanks.
Re: [PATCH v2 3/7] x86/mce: bring hypercall subop compat checking in sync again
On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote: > Use a typedef in struct xen_mc also for the two subops "manually" > translated in the handler, just for consistency. No functional > change. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Thanks.
Re: [PATCH v2 3/7] x86/mce: bring hypercall subop compat checking in sync again
On Tue, Jul 14, 2020 at 01:47:11PM +0200, Jan Beulich wrote: > On 14.07.2020 13:19, Roger Pau Monné wrote: > > On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote: > >> Use a typedef in struct xen_mc also for the two subops "manually" > >> translated in the handler, just for consistency. No functional > >> change. > > > > I'm slightly puzzled by the fact that mc_fetch is marked as needs > > checking while mc_physcpuinfo is marked as needs translation, > > shouldn't both be marked as needing translation? (since both need to > > handle a guest pointer using XEN_GUEST_HANDLE) > > I guess I'm confused - I see an exclamation mark on both respective No, I was the one confused, you are right that both are marked as need translation. Roger.
Re: [PATCH v2 2/7] x86/mce: add compat struct checking for XEN_MC_inject_v2
On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
> 84e364f2eda2 ("x86: add CMCI software injection interface") merely made
> sure things would build, without any concern about things actually
> working:
> - despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
> wasn't invoked anywhere (which would have lead to recognizing that the
> structure appeared to have no fully compatible layout, despite the use
> of a 64-bit handle),
> - the interface struct itself was neither added to xlat.lst (and the
> resulting macro then invoked) nor was any manual checking of
> individual fields added.
>
> Adjust compat header generation logic to retain XEN_GUEST_HANDLE_64(),
> which is intentionally layed out to be compatible between different size
> guests. Invoke the missing checking (implicitly through CHECK_mc).
>
> No change in the resulting generated code.
>
> Fixes: 84e364f2eda2 ("x86: add CMCI software injection interface")
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
Re: [PATCH v2 5/7] x86: generalize padding field handling
On Wed, Jul 01, 2020 at 12:27:37PM +0200, Jan Beulich wrote: > The original intention was to ignore padding fields, but the pattern > matched only ones whose names started with an underscore. Also match > fields whose names are in line with the C spec by not having a leading > underscore. (Note that the leading ^ in the sed regexps was pointless > and hence get dropped.) > > This requires adjusting some vNUMA macros, to avoid triggering > "enumeration value ... not handled in switch" warnings, which - due to > -Werror - would cause the build to fail. (I have to admit that I find > these padding fields odd, when translation of the containing structure > is needed anyway.) > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné > --- > While for translation macros skipping padding fields pretty surely is a > reasonable thing to do, we may want to consider not ignoring them when > generating checking macros. > > --- a/xen/common/compat/memory.c > +++ b/xen/common/compat/memory.c > @@ -354,10 +354,13 @@ int compat_memory_op(unsigned int cmd, X > return -EFAULT; > > #define XLAT_vnuma_topology_info_HNDL_vdistance_h(_d_, _s_) \ > +case XLAT_vnuma_topology_info_vdistance_pad:\ > guest_from_compat_handle((_d_)->vdistance.h, (_s_)->vdistance.h) > #define XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h(_d_, _s_) > \ > +case XLAT_vnuma_topology_info_vcpu_to_vnode_pad:\ > guest_from_compat_handle((_d_)->vcpu_to_vnode.h, > (_s_)->vcpu_to_vnode.h) > #define XLAT_vnuma_topology_info_HNDL_vmemrange_h(_d_, _s_) \ > +case XLAT_vnuma_topology_info_vmemrange_pad:\ > guest_from_compat_handle((_d_)->vmemrange.h, (_s_)->vmemrange.h) I find this quite ugly, would it be better to just handle them with a default case in the XLAT_ macros? AFAICT it will also set (_d_)->vmemrange.h twice? > > XLAT_vnuma_topology_info(nat.vnuma, ); > --- a/xen/tools/get-fields.sh > +++ b/xen/tools/get-fields.sh > @@ -218,7 +218,7 @@ for line in sys.stdin.readlines(): > fi > ;; > [\,\;]) > - if [ $level = 2 -a -n "$(echo $id | $SED > 's,^_pad[[:digit:]]*,,')" ] > + if [ $level = 2 -a -n "$(echo $id | $SED > 's,_\?pad[[:digit:]]*,,')" ] > then > if [ $kind = union ] > then > @@ -347,7 +347,7 @@ build_body () > fi > ;; > [\,\;]) > - if [ $level = 2 -a -n "$(echo $id | $SED > 's,^_pad[[:digit:]]*,,')" ] > + if [ $level = 2 -a -n "$(echo $id | $SED > 's,_\?pad[[:digit:]]*,,')" ] > then > if [ -z "$array" -a -z "$array_type" ] > then > @@ -437,7 +437,7 @@ check_field () > id=$token > ;; > [\,\;]) > - if [ $level = 2 -a -n "$(echo $id | $SED > 's,^_pad[[:digit:]]*,,')" ] > + if [ $level = 2 -a -n "$(echo $id | $SED > 's,_\?pad[[:digit:]]*,,')" ] > then > check_field $1 $2 $3.$id "$fields" > test "$token" != ";" || fields= id= > @@ -491,7 +491,7 @@ build_check () > test $level != 2 -o $arrlvl != 1 || id=$token > ;; > [\,\;]) > - if [ $level = 2 -a -n "$(echo $id | $SED > 's,^_pad[[:digit:]]*,,')" ] > + if [ $level = 2 -a -n "$(echo $id | $SED > 's,_\?pad[[:digit:]]*,,')" ] > then > check_field $kind $1 $id "$fields" > test "$token" != ";" || fields= id= I have to admit I'm not overly happy with this level of repetition (not that you introduce it here), but I would prefer to have the regexp in a single place if possible, it's easy to miss instances IMO. Thanks.
Re: [PATCH v6 00/11] Implement support for external IPT monitoring
- 7 lip 2020 o 21:39, Michał Leszczyński michal.leszczyn...@cert.pl napisał(a): > Intel Processor Trace is an architectural extension available in modern Intel > family CPUs. It allows recording the detailed trace of activity while the > processor executes the code. One might use the recorded trace to reconstruct > the code flow. It means, to find out the executed code paths, determine > branches taken, and so forth. > > The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures > Software Developer's Manual Volume 3C: System Programming Guide, Part 3, > Chapter 36: "Intel Processor Trace." > > This patch series implements an interface that Dom0 could use in order to > enable IPT for particular vCPUs in DomU, allowing for external monitoring. > Such > a feature has numerous applications like malware monitoring, fuzzing, or > performance testing. > > Also thanks to Tamas K Lengyel for a few preliminary hints before > first version of this patch was submitted to xen-devel. > > Changed since v1: > * MSR_RTIT_CTL is managed using MSR load lists > * other PT-related MSRs are modified only when vCPU goes out of context > * trace buffer is now acquired as a resource > * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer >must be specified in the moment of domain creation > * trace buffers are allocated on domain creation, destructed on >domain destruction > * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling PT >these calls don't manage buffer memory anymore > * lifted 32 MFN/GFN array limit when acquiring resources > * minor code style changes according to review > > Changed since v2: > * trace buffer is now allocated on domain creation (in v2 it was >allocated when hvm param was set) > * restored 32-item limit in mfn/gfn arrays in acquire_resource >and instead implemented hypercall continuations > * code changes according to Jan's and Roger's review > > Changed since v3: > * vmtrace HVMOPs are not implemented as DOMCTLs > * patches splitted up according to Andrew's comments > * code changes according to v3 review on the mailing list > > Changed since v4: > * rebased to commit be63d9d4 > * fixed dependencies between patches >(earlier patches don't reference further patches) > * introduced preemption check in acquire_resource > * moved buffer allocation to common code > * splitted some patches according to code review > * minor fixes according to code review > > Changed since v5: > * trace buffer size is now dynamically determined by the proctrace >tool > * trace buffer size variable is uniformly defined as uint32_t >processor_trace_buf_kb in hypervisor, toolstack and ABI > * buffer pages are not freed explicitly but reference count is >now used instead > * minor fixes according to code review > > This patch series is available on GitHub: > https://github.com/icedevml/xen/tree/ipt-patch-v6 > > > Michal Leszczynski (11): > memory: batch processing in acquire_resource() > x86/vmx: add Intel PT MSR definitions > x86/vmx: add IPT cpu feature > common: add vmtrace_pt_size domain parameter > tools/libxl: add vmtrace_pt_size parameter > x86/hvm: processor trace interface in HVM > x86/vmx: implement IPT in VMX > x86/mm: add vmtrace_buf resource type > x86/domctl: add XEN_DOMCTL_vmtrace_op > tools/libxc: add xc_vmtrace_* functions > tools/proctrace: add proctrace tool > > docs/man/xl.cfg.5.pod.in| 13 ++ > tools/golang/xenlight/helpers.gen.go| 2 + > tools/golang/xenlight/types.gen.go | 1 + > tools/libxc/Makefile| 1 + > tools/libxc/include/xenctrl.h | 40 + > tools/libxc/xc_vmtrace.c| 87 ++ > tools/libxl/libxl.h | 8 + > tools/libxl/libxl_create.c | 1 + > tools/libxl/libxl_types.idl | 4 + > tools/proctrace/Makefile| 45 + > tools/proctrace/proctrace.c | 179 > tools/xl/xl_parse.c | 22 +++ > xen/arch/x86/domain.c | 27 +++ > xen/arch/x86/domctl.c | 50 ++ > xen/arch/x86/hvm/vmx/vmcs.c | 15 +- > xen/arch/x86/hvm/vmx/vmx.c | 110 > xen/common/domain.c | 46 + > xen/common/memory.c | 80 - > xen/include/asm-x86/cpufeature.h| 1 + > xen/include/asm-x86/hvm/hvm.h | 20 +++ > xen/include/asm-x86/hvm/vmx/vmcs.h | 4 + > xen/include/asm-x86/hvm/vmx/vmx.h | 14 ++ > xen/include/asm-x86/msr-index.h | 24 +++ > xen/include/public/arch-x86/cpufeatureset.h | 1 + > xen/include/public/domctl.h | 29 > xen/include/public/memory.h | 1 + > xen/include/xen/domain.h| 2 + >
Re: [PATCH v7 09/15] efi: use new page table APIs in copy_mapping
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> After inspection ARM doesn't have alloc_xen_pagetable so this function
> is x86 only, which means it is safe for us to change.
Well, it sits inside a "#ifndef CONFIG_ARM" section.
> @@ -1442,29 +1443,42 @@ static __init void copy_mapping(unsigned long mfn,
> unsigned long end,
> unsigned long emfn))
> {
> unsigned long next;
> +l3_pgentry_t *l3src = NULL, *l3dst = NULL;
>
> for ( ; mfn < end; mfn = next )
> {
> l4_pgentry_t l4e = efi_l4_pgtable[l4_table_offset(mfn <<
> PAGE_SHIFT)];
> -l3_pgentry_t *l3src, *l3dst;
> unsigned long va = (unsigned long)mfn_to_virt(mfn);
>
> +if ( !((mfn << PAGE_SHIFT) & ((1UL << L4_PAGETABLE_SHIFT) - 1)) )
To be in line with ...
> +{
> +UNMAP_DOMAIN_PAGE(l3src);
> +UNMAP_DOMAIN_PAGE(l3dst);
> +}
> next = mfn + (1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT));
... this, please avoid the left shift of mfn in the if(). Judging from
code further down I also think the zapping of l3src would better be
dependent upon va than upon mfn.
> if ( !is_valid(mfn, min(next, end)) )
> continue;
> -if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
> +if ( !l3dst )
> {
> -l3dst = alloc_xen_pagetable();
> -BUG_ON(!l3dst);
> -clear_page(l3dst);
> -efi_l4_pgtable[l4_table_offset(mfn << PAGE_SHIFT)] =
> -l4e_from_paddr(virt_to_maddr(l3dst), __PAGE_HYPERVISOR);
> +if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
> +{
> +mfn_t l3mfn;
> +
> +l3dst = alloc_map_clear_xen_pt();
> +BUG_ON(!l3dst);
> +efi_l4_pgtable[l4_table_offset(mfn << PAGE_SHIFT)] =
> +l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR);
> +}
> +else
> +l3dst = map_l3t_from_l4e(l4e);
> }
> -else
> -l3dst = l4e_to_l3e(l4e);
As for the earlier patch, maybe again neater if you started with
if ( l3dst )
/* nothing */;
else if ...
Would also save a level of indentation as it seems.
Jan
Re: [PATCH v7 08/15] x86_64/mm: switch to new APIs in setup_m2p_table
On 29.05.2020 13:11, Hongyan Xia wrote: > From: Wei Liu > > Avoid repetitive mapping of l2_ro_mpt by keeping it across loops, and > only unmap and map it when crossing 1G boundaries. Oh, one other thing: This reads as if there were such repetitive mapping operations, and the patch took care of them. How about starting this with "While doing so, avoid making ..."? Jan
Re: [PATCH v7 08/15] x86_64/mm: switch to new APIs in setup_m2p_table
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Avoid repetitive mapping of l2_ro_mpt by keeping it across loops, and
> only unmap and map it when crossing 1G boundaries.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
I do think, however, that ...
> @@ -438,32 +443,29 @@ static int setup_m2p_table(struct mem_hotadd_info *info)
>
> ASSERT(!(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
>_PAGE_PSE));
> -if ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
> - _PAGE_PRESENT )
> -l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]) +
> - l2_table_offset(va);
> -else
> +if ( (l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
> + _PAGE_PRESENT) && !l2_ro_mpt)
> +l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
> +else if ( !l2_ro_mpt )
> {
... this would be slightly neater as
if ( l2_ro_mpt )
/* nothing */;
else if ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
_PAGE_PRESENT )
l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]);
else
{
...
My R-b holds if you would change it like this.
Jan
[qemu-mainline test] 151874: regressions - FAIL
flight 151874 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151874/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151065 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151065 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-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
Re: [PATCH v7 07/15] x86_64/mm: switch to new APIs in paging_init
On 29.05.2020 13:11, Hongyan Xia wrote: > From: Wei Liu > > Map and unmap pages instead of relying on the direct map. > > Signed-off-by: Wei Liu > Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich albeit preferably with ... > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -481,6 +481,7 @@ void __init paging_init(void) > l3_pgentry_t *l3_ro_mpt; > l2_pgentry_t *pl2e = NULL, *l2_ro_mpt = NULL; > struct page_info *l1_pg; > +mfn_t l3_ro_mpt_mfn, l2_ro_mpt_mfn; ... just a single variable named "mfn" here. Afaics the life ranges allow for this (imo) readability improvement. Jan
Re: [PATCH v7 06/15] x86_64/mm: introduce pl2e in paging_init
On 29.05.2020 13:11, Hongyan Xia wrote: > From: Wei Liu > > We will soon map and unmap pages in paging_init(). Introduce pl2e so > that we can use l2_ro_mpt to point to the page table itself. > > No functional change. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich
Re: [PATCH v7 05/15] x86/mm: switch to new APIs in modify_xen_mappings
On 29.05.2020 13:11, Hongyan Xia wrote: > From: Wei Liu > > Page tables allocated in that function should be mapped and unmapped > now. > > Note that pl2e now maybe mapped and unmapped in different iterations, so > we need to add clean-ups for that. > > Signed-off-by: Wei Liu > Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich
Re: [PATCH v7 04/15] x86/mm: switch to new APIs in map_pages_to_xen
On 29.05.2020 13:11, Hongyan Xia wrote: > From: Wei Liu > > Page tables allocated in that function should be mapped and unmapped > now. > > Signed-off-by: Wei Liu > Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich
Re: [PATCH v2 3/7] x86/mce: bring hypercall subop compat checking in sync again
On 14.07.2020 13:19, Roger Pau Monné wrote: > On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote: >> Use a typedef in struct xen_mc also for the two subops "manually" >> translated in the handler, just for consistency. No functional >> change. > > I'm slightly puzzled by the fact that mc_fetch is marked as needs > checking while mc_physcpuinfo is marked as needs translation, > shouldn't both be marked as needing translation? (since both need to > handle a guest pointer using XEN_GUEST_HANDLE) I guess I'm confused - I see an exclamation mark on both respective lines in xlat.lst. Jan
Re: [PATCH v2 2/7] x86/mce: add compat struct checking for XEN_MC_inject_v2
On 14.07.2020 12:24, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
>> --- a/xen/tools/compat-build-header.py
>> +++ b/xen/tools/compat-build-header.py
>> @@ -19,6 +19,7 @@ pats = [
>> [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ],
>> [ r"(^|[^\w])XEN_?", r"\1COMPAT_" ],
>> [ r"(^|[^\w])Xen_?", r"\1Compat_" ],
>> + [ r"(^|[^\w])COMPAT_HANDLE_64\(", r"\1XEN_GUEST_HANDLE_64(" ],
>
> Why do you need to match with the opening parenthesis?
>
> Is this for the #ifndef XEN_GUEST_HANDLE_64 instances? Don't they need
> to also be replaced with the compat types?
Well, I wanted to be as strict as possible, i.e. along with
the matching of a non-identifier char at the beginning I
also wanted the other side to be delimited.
Jan
Re: [PATCH v2 4/7] x86/dmop: add compat struct checking for XEN_DMOP_map_mem_type_to_ioreq_server
On Wed, Jul 01, 2020 at 12:27:16PM +0200, Jan Beulich wrote:
> This was forgotten when the subop was added.
>
> Also take the opportunity and move the dm_op_relocate_memory entry in
> xlat.lst to its designated place.
>
> No change in the resulting generated code.
>
> Fixes: ca2b511d3ff4 ("x86/ioreq server: add DMOP to map guest ram with
> p2m_ioreq_server to an ioreq server")
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
Re: [PATCH v2 3/7] x86/mce: bring hypercall subop compat checking in sync again
On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote: > Use a typedef in struct xen_mc also for the two subops "manually" > translated in the handler, just for consistency. No functional > change. I'm slightly puzzled by the fact that mc_fetch is marked as needs checking while mc_physcpuinfo is marked as needs translation, shouldn't both be marked as needing translation? (since both need to handle a guest pointer using XEN_GUEST_HANDLE) Thanks, Roger.
[xen-unstable-smoke test] 151891: tolerable all pass - PUSHED
flight 151891 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151891/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 1969576661f3e34318e9b0a61a1a38f9a5aee16f baseline version: xen 165f3afbfc3db70fcfdccad07085cde0a03c858b Last test of basis 151863 2020-07-13 14:00:24 Z0 days Testing same since 151891 2020-07-14 09:00:47 Z0 days1 attempts People who touched revisions under test: Jan Beulich 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-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 165f3afbfc..1969576661 1969576661f3e34318e9b0a61a1a38f9a5aee16f -> smoke
Re: [PATCH v7 03/15] x86/mm: rewrite virt_to_xen_l*e
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Rewrite those functions to use the new APIs. Modify its callers to unmap
> the pointer returned. Since alloc_xen_pagetable_new() is almost never
> useful unless accompanied by page clearing and a mapping, introduce a
> helper alloc_map_clear_xen_pt() for this sequence.
>
> Note that the change of virt_to_xen_l1e() also requires vmap_to_mfn() to
> unmap the page, which requires domain_page.h header in vmap.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
with two further small adjustments:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4948,8 +4948,28 @@ void free_xen_pagetable_new(mfn_t mfn)
> free_xenheap_page(mfn_to_virt(mfn_x(mfn)));
> }
>
> +void *alloc_map_clear_xen_pt(mfn_t *pmfn)
> +{
> +mfn_t mfn = alloc_xen_pagetable_new();
> +void *ret;
> +
> +if ( mfn_eq(mfn, INVALID_MFN) )
> +return NULL;
> +
> +if ( pmfn )
> +*pmfn = mfn;
> +ret = map_domain_page(mfn);
> +clear_page(ret);
> +
> +return ret;
> +}
> +
> static DEFINE_SPINLOCK(map_pgdir_lock);
>
> +/*
> + * For virt_to_xen_lXe() functions, they take a virtual address and return a
> + * pointer to Xen's LX entry. Caller needs to unmap the pointer.
> + */
> static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
May I suggest s/virtual/linear/ to at least make the new comment
correct?
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -291,7 +291,13 @@ void copy_page_sse2(void *, const void *);
> #define pfn_to_paddr(pfn) __pfn_to_paddr(pfn)
> #define paddr_to_pfn(pa)__paddr_to_pfn(pa)
> #define paddr_to_pdx(pa)pfn_to_pdx(paddr_to_pfn(pa))
> -#define vmap_to_mfn(va) _mfn(l1e_get_pfn(*virt_to_xen_l1e((unsigned
> long)(va
> +
> +#define vmap_to_mfn(va) ({ \
> +const l1_pgentry_t *pl1e_ = virt_to_xen_l1e((unsigned long)(va)); \
> +mfn_t mfn_ = l1e_get_mfn(*pl1e_); \
> +unmap_domain_page(pl1e_); \
> +mfn_; })
Just like is already the case in domain_page_map_to_mfn() I think
you want to add "BUG_ON(!pl1e)" here to limit the impact of any
problem to DoS (rather than a possible privilege escalation).
Or actually, considering the only case where virt_to_xen_l1e()
would return NULL, returning INVALID_MFN here would likely be
even more robust. There looks to be just a single caller, which
would need adjusting to cope with an error coming back. In fact -
it already ASSERT()s, despite NULL right now never coming back
from vmap_to_page(). I think the loop there would better be
for ( i = 0; i < pages; i++ )
{
struct page_info *page = vmap_to_page(va + i * PAGE_SIZE);
if ( page )
page_list_add(page, _list);
else
printk_once(...);
}
Thoughts?
Jan
Re: [PATCH v2 2/7] x86/mce: add compat struct checking for XEN_MC_inject_v2
On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
> 84e364f2eda2 ("x86: add CMCI software injection interface") merely made
> sure things would build, without any concern about things actually
> working:
> - despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
> wasn't invoked anywhere (which would have lead to recognizing that the
> structure appeared to have no fully compatible layout, despite the use
> of a 64-bit handle),
> - the interface struct itself was neither added to xlat.lst (and the
> resulting macro then invoked) nor was any manual checking of
> individual fields added.
>
> Adjust compat header generation logic to retain XEN_GUEST_HANDLE_64(),
> which is intentionally layed out to be compatible between different size
> guests. Invoke the missing checking (implicitly through CHECK_mc).
>
> No change in the resulting generated code.
>
> Fixes: 84e364f2eda2 ("x86: add CMCI software injection interface")
> Signed-off-by: Jan Beulich
LGTM, just one question below.
> --- a/xen/tools/compat-build-header.py
> +++ b/xen/tools/compat-build-header.py
> @@ -19,6 +19,7 @@ pats = [
> [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ],
> [ r"(^|[^\w])XEN_?", r"\1COMPAT_" ],
> [ r"(^|[^\w])Xen_?", r"\1Compat_" ],
> + [ r"(^|[^\w])COMPAT_HANDLE_64\(", r"\1XEN_GUEST_HANDLE_64(" ],
Why do you need to match with the opening parenthesis?
Is this for the #ifndef XEN_GUEST_HANDLE_64 instances? Don't they need
to also be replaced with the compat types?
Thanks, Roger.
[PATCH v2] x86emul: avoid assembler warning about .type not taking effect in test harness
gcc re-orders top level blocks by default when optimizing. This re-ordering results in all our .type directives to get emitted to the assembly file first, followed by gcc's. The assembler warns about attempts to change the type of a symbol when it was already set (and when there's no intervening setting to "notype"). Signed-off-by: Jan Beulich --- v2: Refine description to no longer claim a gcc change to be the reason. --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -295,4 +295,9 @@ x86-emulate.o cpuid.o test_x86_emulator. x86-emulate.o: x86_emulate/x86_emulate.c x86-emulate.o: HOSTCFLAGS += -D__XEN_TOOLS__ +# In order for our custom .type assembler directives to reliably land after +# gcc's, we need to keep it from re-ordering top-level constructs. +$(call cc-option-add,HOSTCFLAGS-toplevel,HOSTCC,-fno-toplevel-reorder) +test_x86_emulator.o: HOSTCFLAGS += $(HOSTCFLAGS-toplevel) + test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK))
[linux-linus test] 151870: regressions - FAIL
flight 151870 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151870/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 build-i386-pvops 6 kernel-build fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm1 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-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 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-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 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-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 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-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151214 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check
Re: [PATCH v2] efi: avoid error message when booting under Xen
On 7/10/20 4:22 PM, Juergen Gross wrote:
> efifb_probe() will issue an error message in case the kernel is booted
> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
>
> Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
> mapping the FB")
> Signed-off-by: Juergen Gross
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/efifb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 65491ae74808..e57c00824965 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
> info->apertures->ranges[0].base = efifb_fix.smem_start;
> info->apertures->ranges[0].size = size_remap;
>
> - if (efi_enabled(EFI_BOOT) &&
> + if (efi_enabled(EFI_MEMMAP) &&
> !efi_mem_desc_lookup(efifb_fix.smem_start, )) {
> if ((efifb_fix.smem_start + efifb_fix.smem_len) >
> (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
>
