[ovmf test] 169848: regressions - FAIL
flight 169848 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169848/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 59 days 690 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days 11 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[xen-unstable-smoke test] 169840: regressions - FAIL
flight 169840 xen-unstable-smoke real [real] flight 169847 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169840/ http://logs.test-lab.xenproject.org/osstest/logs/169847/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169824 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen e57477359071ab91429b0ebcbf7ff162242e2831 baseline version: xen d711a8e5279d830d2e4f0f55246ed0c6e4a6bbed Last test of basis 169824 2022-04-28 16:00:24 Z0 days Testing same since 169840 2022-04-29 00:00:26 Z0 days1 attempts People who touched revisions under test: Julien Grall Rahul Singh Stefano Stabellini Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit e57477359071ab91429b0ebcbf7ff162242e2831 Author: Stefano Stabellini Date: Tue Apr 26 13:27:32 2022 -0700 MAINTAINERS: add Rahul as SMMU maintainer Add Rahul as ARM SMMU maintainer. Create a new explicit entry for "ARM SMMU" also with Julien which is the original contributor of the code and continues to maintain it. Signed-off-by: Stefano Stabellini Reviewed-by: Bertrand Marquis Acked-by: Rahul Singh Acked-by: Julien Grall (qemu changes not included)
Re: Virtio on Xen with Rust
On 29-04-22, 09:18, Viresh Kumar wrote: > Now, it was just yesterday that I started looking into MMIO modern stuff as > the > GPIO device needs it and you sent me working code to look how to do it as > well. > You saved at least 1-2 days of my time :) One question though, do we need to support Legacy mode at all in the work we are doing ? -- viresh
Re: Virtio on Xen with Rust
On 28-04-22, 16:52, Oleksandr Tyshchenko wrote: > Great work! Thanks Oleksandr. > I skimmed through your toolstack patches, awesome, you created a completely > new virtual device "I2C". I have also created GPIO now :) What should I do about these patches ? Send them to xen list ? I can at least send the stuff which doesn't depend on your series ? > FYI, I have updated "Virtio support for toolstack on Arm" [1] since (to > make it more generic), now V7 is available and I have a plan to push V8 > soon. I will surely have a look, thanks. > FYI, currently we are working on one feature to restrict memory access > using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1]. > And there is a working PoC on Arm based on an updated virtio-disk. As for > libraries, there is a new dependency on "xengnttab" library. In comparison > with Xen foreign mappings model (xenforeignmemory), > the Xen grant mappings model is a good fit into the Xen security model, > this is a safe mechanism to share pages between guests. Right, I was aware of this work but didn't dive into it yet. We will surely need to do that eventually, lets see when I will be able to get to that. The current focus is the get the solution a bit more robust (so it can be used with any device) and upstream it to rust-vmm space on github. > With Xen grant mappings, if I am not mistaken, it is going to be almost the > same: mmap() then ioctl(). But the file will be "/dev/xen/gntdev". Okay, the problem (for us) still exists then :) > FYI, new branch "virtio_grant" besides supporting Xen grant mappings also > supports virtio-mmio modern transport. Somehow the timing of your emails have been spot on. Last time, when you told me about the "dev" branch, I have already started to reinvent the wheel and your branch really helped. Now, it was just yesterday that I started looking into MMIO modern stuff as the GPIO device needs it and you sent me working code to look how to do it as well. You saved at least 1-2 days of my time :) Thanks Oleksandr. -- viresh
[qemu-mainline test] 169827: tolerable FAIL - PUSHED
flight 169827 qemu-mainline real [real] flight 169846 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169827/ http://logs.test-lab.xenproject.org/osstest/logs/169846/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 19 guest-localmigrate/x10 fail pass in 169846-retest Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 169801 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169801 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169801 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169801 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169801 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169801 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169801 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169801 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169801 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: qemuu6071ff6087208bf1d8e488dca43037b41d5ad764 baseline version: qemuucf6f26d6f9b2015ee12b4604b79359e76784163a Last test of basis 169801 2022-04-28 00:08:30 Z1 days Testing
[ovmf test] 169845: regressions - FAIL
flight 169845 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169845/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 59 days 689 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days 10 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[ovmf test] 169842: regressions - FAIL
flight 169842 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169842/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 59 days 688 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days9 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[ovmf test] 169841: regressions - FAIL
flight 169841 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169841/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 59 days 687 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days8 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[ovmf test] 169839: regressions - FAIL
flight 169839 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169839/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 686 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days7 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
Re: [xen-unstable-smoke test] 169781: regressions - FAIL
On Thu, 28 Apr 2022, Julien Grall wrote: > On 28/04/2022 01:47, Stefano Stabellini wrote: > > On Thu, 28 Apr 2022, Julien Grall wrote: > > > Hi Stefano, > > > > > > On Thu, 28 Apr 2022, 00:02 Stefano Stabellini, > > > wrote > > >It seems to me that it is acceptable to allocate memory with > > > interrupt > > >disabled during __init. I cannot see any drawbacks with it. I think > > > we > > >should change the ASSERT to only trigger after __init: system_state > > > == > > >SYS_STATE_active. > > > > > >What do you think? > > > > > > > > > This would solve the immediate problem but not the long term one (i.e cpu > > > hotplug). > > > > > > So I think it would be better to properly fix it right away. > > > > Yeah, you are right about cpu hotplug. I think both statements are true: > > > > - it is true that this is supposed to work with cpu hotplug and these > >functions might be directly affected by cpu hotplug (by a CPU coming > >online later on) > > > > - it is also true that it might not make sense to ASSERT at __init time > >if IRQs are disabled. There might be other places, not affected by cpu > >hotplug, where we do memory allocation at __init time with IRQ > >disabled. It might still be a good idea to add the system_state == > >SYS_STATE_active check in the ASSERT, not to solve this specific > >problem but to avoid other issues. > > AFAIU, it is not safe on x86 to do TLB flush with interrupts disabled *and* > multiple CPUs running. So we can't generically relax the check. > > Looking at the OSSTest results, both Arm32 and Arm64 without GICv3 ITS tests > have passed. So it seems unnecessary to me to preemptively relax the check > just for Arm. It is good news that it works already (GICv3 aside) on ARM. If you prefer not to relax it, I am OK with it (although it makes me a bit worried about future breakages). > > In regard to gicv3_lpi_allocate_pendtable, I haven't thought about the > > implications of cpu hotplug for LPIs and GICv3 before. Do you envision > > that in a CPU hotplug scenario gicv3_lpi_init_rdist would be called when > > the extra CPU comes online? > > It is already called per-CPU. See gicv3_secondary_cpu_init() -> > gicv3_cpu_init() -> gicv3_populate_rdist(). Got it, thanks! > > Today gicv3_lpi_init_rdist is called based on the number of > > rdist_regions without checking if the CPU is online or offline (I think ?) > > The re-distributors are not banked and therefore accessible by everyone. > However, in Xen case, each pCPU will only touch its own re-distributor (well > aside TYPER to figure out the ID). > > The loop in gicv3_populate_rdist() will walk throught all the > re-distributor to find which one corresponds to the current pCPU. Once we > found it, we will call gicv3_lpi_init_rdist() to fully initialize the > re-distributor. > > I don't think we want to populate the memory for each re-distributor in > advance. I agree. Currently we do: start_secondary [...] gic_init_secondary_cpu() [...] gicv3_lpi_init_rdist() [...] local_irq_enable(); Which seems to be the right sequence to me. There must be an early boot phase where interrupts are disabled on a CPU but memory allocations are possible. If this was x86 with the tlbflush limitation, I would suggest to have per-cpu memory mapping areas so that we don't have to do any global tlb flushes with interrupts disabled. On ARM, we don't have the tlbflush limitation so we could do that but we wouldn't have much to gain from it. Also, this seems to be a bit of a special case, because in general we can move drivers initializations later after local_irq_enable(). But this is the interrupt controller driver itself -- we cannot move it after local_irq_enable(). So maybe an ad-hoc solution could be acceptable? The only one I can think of is to check on system_state == SYS_STATE_active now. In the future for CPU hotplug we could have a per-CPU system_state, like cpu_system_state, and do a similar check. I am totally open to other ideas, I couldn't come up with anything better at the moment.
Re: [PATCH] cirrus-ci: add myself as maintainer
On Thu, 28 Apr 2022, Andrew Cooper wrote: > On 28/04/2022 10:55, Roger Pau Monne wrote: > > Given the testing done by Cirrus-CI is FreeBSD only introduce a new > > section in the MAINTAINERS file to cover it and add myself as the > > maintainer. > > > > Requested-by: Stefano Stabellini > > Signed-off-by: Roger Pau Monné > > --- > > FWIW, I wouldn't mind it being part of the "Continuous Integration > > (CI)" section, but I understand maintainers there could prefer a > > separate section since this is ATM FreeBSD only testing. > > I don't think we have enough review bandwidth to separate things like > this. Plenty of changes to CI are dependency tweaks which cover all CI > files in one go, so wouldn't be directly relevant to being FreeBSD. > Also some CI changes need superpowers in other systems. Today, gitlab-ci and cirrus-ci are entirely different systems: they don't share any containers or any other artifacts. So my preference is to have a separate entry in the MAINTAINERS file as Roger did in this patch. That would be more accurate in terms of roles, responsibilities and expectations. If someone sends a patch for .cirrus.yml, I definitely think Roger should be the one to have a look. My recommendation is to go ahead with this patch. We can always merge the sections in the future if the CI systems become more integrated. Acked-by: Stefano Stabellini
[ovmf test] 169837: regressions - FAIL
flight 169837 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169837/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 685 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days6 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT
On Thu, Apr 28, 2022 at 08:47:49AM +0200, Jan Beulich wrote: > On 27.04.2022 21:08, Demi Marie Obenour wrote: > > On Wed, Apr 27, 2022 at 10:56:34AM +0200, Jan Beulich wrote: > >> On 19.04.2022 17:49, Demi Marie Obenour wrote: > >>> This hypercall can be used to get the ESRT from the hypervisor. It > >>> returning successfully also indicates that Xen has reserved the ESRT and > >>> it can safely be parsed by dom0. > >> > >> I'm not convinced of the need, and I view such an addition as inconsistent > >> with the original intentions. The pointer comes from the config table, > >> which Dom0 already has access to. All a Dom0 kernel may need to know in > >> addition is whether the range was properly reserved. This could be achieved > >> by splitting the EFI memory map entry in patch 2, instead of only splitting > >> the E820 derivation, as then XEN_FW_EFI_MEM_INFO can be used to find out > >> the range's type. Another way to find out would be for Dom0 to attempt to > >> map this area as MMIO, after first checking that no part of the range is in > >> its own memory allocation. This 2nd approach may, however, not really be > >> suitable for PVH Dom0, I think. > > > > On further thought, I think the hypercall approach is actually better > > than reserving the ESRT. I really do not want XEN_FW_EFI_MEM_INFO to > > return anything other than the actual firmware-provided memory > > information, and the current approach seems to require more and more > > special-casing of the ESRT, not to mention potentially wasting memory > > and splitting a potentially large memory region into two smaller ones. > > By copying the entire ESRT into memory owned by Xen, the logic becomes > > significantly simpler on both the Xen and dom0 sides. > > I actually did consider the option of making a private copy when you did > send the initial version of this, but I'm not convinced this simplifies > things from a kernel perspective: They'd now need to discover the table > by some entirely different means. In Linux at least such divergence > "just for Xen" hasn't been liked in the past. > > There's also the question of how to propagate the information across > kexec. But I guess that question exists even outside of Xen, with the > area living in memory which the OS is expected to recycle. Indeed it does. A simple rule might be, “Only trust the ESRT if it is in memory of type EfiRuntimeServicesData.” That is easy to achieve by monkeypatching the config table as you suggested below. I *am* worried that the config table might be mapped read-only on some systems, in which case the overwrite would cause a fatal page fault. Is there a way for Xen to check for this? It could also be undefined behavior to modify it. > > Is using ebmalloc() to allocate a copy of the ESRT a reasonable option? > > I'd suggest to try hard to avoid ebmalloc(). It ought to be possible to > make the copy before ExitBootServices(), via normal EFI allocation. If > replacing a pointer in the config table was okay(ish), this could even > be utilized to overcome the kexec problem. What type should I use for the allocation? EfiLoaderData looks like the most consistent choice, but I am not sure if memory so allocated remains valid when Xen hands off to the OS, so EfiRuntimeServicesData might be a better choice. To avoid memory leaks from repeated kexec(), this could be made conditional on the ESRT not being in memory of type EfiRuntimeServicesData to begin with. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
On Thu, 28 Apr 2022, Boris Ostrovsky wrote: > On 4/28/22 5:49 PM, Stefano Stabellini wrote: > > On Thu, 28 Apr 2022, Christoph Hellwig wrote: > > > On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote: > > > > > Reported-by: Rahul Singh > > > > > Signed-off-by: Christoph Hellwig > > > > Reviewed-by: Stefano Stabellini > > > Do you want to take this through the Xen tree or should I pick it up? > > > Either way I'd love to see some testing on x86 as well. > > I agree on the x86 testing. Juergen, Boris? > > > > I'd say to take this patch via the Xen tree but Juergen has just sent a > > Xen pull request to Linux last Saturday. Juergen do you plan to send > > another one? Do you have something else lined up? If not, it might be > > better to let Christoph pick it up. > > > We don't have anything pending. > > > I can test it but at best tomorrow so not sure we can get this into rc5. Do > you consider this an urgent fix or can we wait until 5.19? Because it's a bit > too much IMO for rc6. On one hand, Linux doesn't boot on a platform without this fix. On the other hand, I totally see that this patch could introduce regressions on x86 so I think it is fair that we are careful with it. >From my point of view, it might be better to wait for 5.19 and mark it as backport.
Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
On 4/28/22 5:49 PM, Stefano Stabellini wrote: On Thu, 28 Apr 2022, Christoph Hellwig wrote: On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote: Reported-by: Rahul Singh Signed-off-by: Christoph Hellwig Reviewed-by: Stefano Stabellini Do you want to take this through the Xen tree or should I pick it up? Either way I'd love to see some testing on x86 as well. I agree on the x86 testing. Juergen, Boris? I'd say to take this patch via the Xen tree but Juergen has just sent a Xen pull request to Linux last Saturday. Juergen do you plan to send another one? Do you have something else lined up? If not, it might be better to let Christoph pick it up. We don't have anything pending. I can test it but at best tomorrow so not sure we can get this into rc5. Do you consider this an urgent fix or can we wait until 5.19? Because it's a bit too much IMO for rc6. -boris
[ovmf test] 169835: regressions - FAIL
flight 169835 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169835/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 684 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days5 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
On Thu, 28 Apr 2022, Christoph Hellwig wrote: > On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote: > > > Reported-by: Rahul Singh > > > Signed-off-by: Christoph Hellwig > > > > Reviewed-by: Stefano Stabellini > > Do you want to take this through the Xen tree or should I pick it up? > Either way I'd love to see some testing on x86 as well. I agree on the x86 testing. Juergen, Boris? I'd say to take this patch via the Xen tree but Juergen has just sent a Xen pull request to Linux last Saturday. Juergen do you plan to send another one? Do you have something else lined up? If not, it might be better to let Christoph pick it up.
[linux-linus test] 169809: tolerable FAIL - PUSHED
flight 169809 linux-linus real [real] flight 169833 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169809/ http://logs.test-lab.xenproject.org/osstest/logs/169833/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 169833-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169792 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169792 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169792 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169792 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169792 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169792 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169792 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169792 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux8f4dd16603ce834d1c5c4da67803ea82dd282511 baseline version: linuxe4d8a29997731b3bb14059024b24df9f784288d0 Last test of basis 169792 2022-04-27 19:09:50 Z1 days Testing same since 169809 2022-04-28 09:42:57 Z0 days1 attempts People who touched revisions under test: Akira Yokosawa Andrew Morton Linus Torvalds Zqiang jobs: build-amd64-xsm
Re: x86/PV: (lack of) MTRR exposure
On 4/28/22 11:53 AM, Jan Beulich wrote: Hello, in the course of analyzing the i915 driver causing boot to fail in Linux 5.18 I found that Linux, for all the years, has been running in PV mode as if PAT was (mostly) disabled. This is a result of them tying PAT initialization to MTRR initialization, while we offer PAT but not MTRR in CPUID output. This was different before our moving to CPU featuresets, and as such one could view this behavior as a regression from that change. The first question here is whether not exposing MTRR as a feature was really intended, in particular also for PV Dom0. The XenoLinux kernel and its forward ports did make use of XENPF_*_memtype to deal with MTRRs. That's functionality which (maybe for a good reason) never made it into the pvops kernel. Note that PVH Dom0 does have access to the original settings, as the host values are used as initial state there. Initially MTRR was supposed to be supported but it was shot down by x86 maintainers who strongly suggested to use PAT. https://lists.xen.org/archives/html/xen-devel/2010-09/msg01634.html -boris The next question would be how we could go about improving the situation. For the particular issue in 5.18 I've found a relatively simple solution [1] (which also looks to help graphics performance on other systems, according to my initial observations with using the change), albeit its simplicity likely means it either is wrong in some way, or might not be liked for looking hacky and/or abusive. We can't, for example, simply turn on the MTRR bit in CPUID, as that would implicitly lead to the kernel trying to write the PAT MSR (if, see below, it didn't itself zap the bit). We also can't simply ignore PAT MSR writes, as the kernel won't check whether writes actually took effect. (All of that did work on top of old Xen apparently only because xen_init_capabilities() itself also forces the MTRR feature to off.) Jan [1] https://lists.xen.org/archives/html/xen-devel/2022-04/msg02392.html
[PATCH net-next v2 01/15] eth: remove copies of the NAPI_POLL_WEIGHT define
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact reviewability.
Signed-off-by: Jakub Kicinski
---
CC: ulli.kr...@googlemail.com
CC: linus.wall...@linaro.org
CC: mlind...@marvell.com
CC: step...@networkplumber.org
CC: n...@nbd.name
CC: j...@phrozen.org
CC: sean.w...@mediatek.com
CC: mark-mc@mediatek.com
CC: matthias@gmail.com
CC: grygorii.stras...@ti.com
CC: wei@kernel.org
CC: p...@xen.org
CC: prabhakar.mahadev-lad...@bp.renesas.com
CC: linux-arm-ker...@lists.infradead.org
CC: linux-media...@lists.infradead.org
CC: linux-o...@vger.kernel.org
CC: xen-devel@lists.xenproject.org
---
drivers/net/ethernet/cortina/gemini.c | 4 +---
drivers/net/ethernet/marvell/skge.c | 3 +--
drivers/net/ethernet/marvell/sky2.c | 3 +--
drivers/net/ethernet/mediatek/mtk_star_emac.c | 3 +--
drivers/net/ethernet/ti/davinci_emac.c| 3 +--
drivers/net/ethernet/ti/netcp_core.c | 5 ++---
drivers/net/xen-netback/interface.c | 3 +--
7 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c
b/drivers/net/ethernet/cortina/gemini.c
index 8014eb33937c..9e6de2f968fa 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -68,7 +68,6 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
#define DEFAULT_GMAC_RXQ_ORDER 9
#define DEFAULT_GMAC_TXQ_ORDER 8
#define DEFAULT_RX_BUF_ORDER 11
-#define DEFAULT_NAPI_WEIGHT64
#define TX_MAX_FRAGS 16
#define TX_QUEUE_NUM 1 /* max: 6 */
#define RX_MAX_ALLOC_ORDER 2
@@ -2472,8 +2471,7 @@ static int gemini_ethernet_port_probe(struct
platform_device *pdev)
netdev->max_mtu = 10236 - VLAN_ETH_HLEN;
port->freeq_refill = 0;
- netif_napi_add(netdev, >napi, gmac_napi_poll,
- DEFAULT_NAPI_WEIGHT);
+ netif_napi_add(netdev, >napi, gmac_napi_poll, NAPI_POLL_WEIGHT);
ret = of_get_mac_address(np, mac);
if (!ret) {
diff --git a/drivers/net/ethernet/marvell/skge.c
b/drivers/net/ethernet/marvell/skge.c
index cf03c67fbf40..c1e985416c0e 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -50,7 +50,6 @@
#define PHY_RETRIES1000
#define ETH_JUMBO_MTU 9000
#define TX_WATCHDOG(5 * HZ)
-#define NAPI_WEIGHT64
#define BLINK_MS 250
#define LINK_HZHZ
@@ -3833,7 +3832,7 @@ static struct net_device *skge_devinit(struct skge_hw
*hw, int port,
dev->features |= NETIF_F_HIGHDMA;
skge = netdev_priv(dev);
- netif_napi_add(dev, >napi, skge_poll, NAPI_WEIGHT);
+ netif_napi_add(dev, >napi, skge_poll, NAPI_POLL_WEIGHT);
skge->netdev = dev;
skge->hw = hw;
skge->msg_enable = netif_msg_init(debug, default_msg);
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index ea16b1dd6a98..a1e907c85217 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -63,7 +63,6 @@
#define TX_DEF_PENDING 63
#define TX_WATCHDOG(5 * HZ)
-#define NAPI_WEIGHT64
#define PHY_RETRIES1000
#define SKY2_EEPROM_MAGIC 0x9955aabb
@@ -4938,7 +4937,7 @@ static int sky2_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
}
}
- netif_napi_add(dev, >napi, sky2_poll, NAPI_WEIGHT);
+ netif_napi_add(dev, >napi, sky2_poll, NAPI_POLL_WEIGHT);
err = register_netdev(dev);
if (err) {
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c
b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 4cd0747edaff..95839fd84dab 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -30,7 +30,6 @@
#define MTK_STAR_WAIT_TIMEOUT 300
#define MTK_STAR_MAX_FRAME_SIZE1514
#define MTK_STAR_SKB_ALIGNMENT 16
-#define MTK_STAR_NAPI_WEIGHT 64
#define MTK_STAR_HASHTABLE_MC_LIMIT256
#define MTK_STAR_HASHTABLE_SIZE_MAX512
@@ -1551,7 +1550,7 @@ static int mtk_star_probe(struct platform_device *pdev)
ndev->netdev_ops = _star_netdev_ops;
ndev->ethtool_ops = _star_ethtool_ops;
- netif_napi_add(ndev, >napi, mtk_star_poll, MTK_STAR_NAPI_WEIGHT);
+ netif_napi_add(ndev, >napi, mtk_star_poll, NAPI_POLL_WEIGHT);
return devm_register_netdev(dev, ndev);
}
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index 9d1e98db308b..2a3e4e842fa5 100644
---
[ovmf test] 169832: regressions - FAIL
flight 169832 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169832/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 683 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days4 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[xen-unstable-smoke test] 169824: tolerable all pass - PUSHED
flight 169824 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169824/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen d711a8e5279d830d2e4f0f55246ed0c6e4a6bbed baseline version: xen da28439ba55b8a571032b3358af567cff749f612 Last test of basis 169800 2022-04-27 23:01:43 Z0 days Failing since169807 2022-04-28 09:01:41 Z0 days2 attempts Testing same since 169824 2022-04-28 16:00:24 Z0 days1 attempts People who touched revisions under test: Artem Bityutskiy Jan Beulich Juergen Gross Rafael J. Wysocki Roger Pau Monné Tamas K Lengyel 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 da28439ba5..d711a8e527 d711a8e5279d830d2e4f0f55246ed0c6e4a6bbed -> smoke
[ovmf test] 169828: regressions - FAIL
flight 169828 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169828/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 682 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days3 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF
On Thu, Apr 28, 2022 at 11:28 AM Juergen Gross wrote:
Hello Juergen
[sorry for the possible format issue]
Instead of using a private macro for an invalid grant reference use
> the common one.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/xen-front-pgdir-shbuf.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/xen/xen-front-pgdir-shbuf.c
> b/drivers/xen/xen-front-pgdir-shbuf.c
> index a959dee21134..fa2921d4fbfc 100644
> --- a/drivers/xen/xen-front-pgdir-shbuf.c
> +++ b/drivers/xen/xen-front-pgdir-shbuf.c
> @@ -21,15 +21,6 @@
>
> #include
>
> -#ifndef GRANT_INVALID_REF
> -/*
> - * FIXME: usage of grant reference 0 as invalid grant reference:
> - * grant reference 0 is valid, but never exposed to a PV driver,
> - * because of the fact it is already in use/reserved by the PV console.
> - */
> -#define GRANT_INVALID_REF 0
> -#endif
> -
> /**
> * This structure represents the structure of a shared page
> * that contains grant references to the pages of the shared
> @@ -83,7 +74,7 @@ grant_ref_t
> xen_front_pgdir_shbuf_get_dir_start(struct xen_front_pgdir_shbuf *buf)
> {
> if (!buf->grefs)
> - return GRANT_INVALID_REF;
> + return INVALID_GRANT_REF;
>
> return buf->grefs[0];
> }
> @@ -142,7 +133,7 @@ void xen_front_pgdir_shbuf_free(struct
> xen_front_pgdir_shbuf *buf)
> int i;
>
> for (i = 0; i < buf->num_grefs; i++)
> - if (buf->grefs[i] != GRANT_INVALID_REF)
> + if (buf->grefs[i] != INVALID_GRANT_REF)
> gnttab_end_foreign_access(buf->grefs[i],
> 0UL);
> }
> kfree(buf->grefs);
> @@ -355,7 +346,7 @@ static void backend_fill_page_dir(struct
> xen_front_pgdir_shbuf *buf)
> }
> /* Last page must say there is no more pages. */
> page_dir = (struct xen_page_directory *)ptr;
> - page_dir->gref_dir_next_page = GRANT_INVALID_REF;
> + page_dir->gref_dir_next_page = INVALID_GRANT_REF;
> }
>
> /**
> @@ -384,7 +375,7 @@ static void guest_fill_page_dir(struct
> xen_front_pgdir_shbuf *buf)
>
> if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
> to_copy = grefs_left;
> - page_dir->gref_dir_next_page = GRANT_INVALID_REF;
> + page_dir->gref_dir_next_page = INVALID_GRANT_REF;
>
I faced an issue with testing PV Sound with the current series.
root@salvator-x-h3-4x2g-xt-domu:~# aplay /media/MoodyLoop.wav
Playing WAVE '/media/MoodyLoop.wav' : Signed 16 bit Little Endian, Rate
44100 Hz, Stereo
(XEN) common/grant_table.c:1053:d1v2 Bad ref 0x for d6
Here we have an interesting situation. PV Sound frontend uses this
xen-front-pgdir-shbuf framework. Technically, this patch changes
page_dir->gref_dir_next_page (reference to the next page describing page
directory) from 0 to 0x here.
#define INVALID_GRANT_REF ((grant_ref_t)-1)
But according to the protocol (sndif.h), "0" means that there are no more
pages in the list and the user space backend expects only that value. So
receiving 0x it assumes there are pages in the list and trying to
process...
https://elixir.bootlin.com/linux/v5.18-rc4/source/include/xen/interface/io/sndif.h#L650
I think, the same is relevant to backend_fill_page_dir() as well.
} else {
> to_copy = XEN_NUM_GREFS_PER_PAGE;
> page_dir->gref_dir_next_page = buf->grefs[i + 1];
> --
> 2.34.1
>
>
>
--
Regards,
Oleksandr Tyshchenko
[ovmf test] 169821: regressions - FAIL
flight 169821 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169821/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 681 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days2 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
Re: [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path
On 4/28/22 00:49, Guilherme G. Piccoli wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
> spinlock, there's a risk of deadlock.
>
> This patch refactors the panic notifier of parisc/power driver
> to make use of spin_trylock - for that, we've added a second
> version of the soft-power function. Also, some comments were
> reorganized and trailing white spaces, useless header inclusion
> and blank lines were removed.
>
> Cc: Helge Deller
> Cc: "James E.J. Bottomley"
> Signed-off-by: Guilherme G. Piccoli
You may add:
Acked-by: Helge Deller # parisc
Helge
> ---
> arch/parisc/include/asm/pdc.h | 1 +
> arch/parisc/kernel/firmware.c | 27 +++
> drivers/parisc/power.c| 17 ++---
> 3 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
> index b643092d4b98..7a106008e258 100644
> --- a/arch/parisc/include/asm/pdc.h
> +++ b/arch/parisc/include/asm/pdc.h
> @@ -83,6 +83,7 @@ int pdc_do_firm_test_reset(unsigned long ftc_bitmap);
> int pdc_do_reset(void);
> int pdc_soft_power_info(unsigned long *power_reg);
> int pdc_soft_power_button(int sw_control);
> +int pdc_soft_power_button_panic(int sw_control);
> void pdc_io_reset(void);
> void pdc_io_reset_devices(void);
> int pdc_iodc_getc(void);
> diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
> index 6a7e315bcc2e..0e2f70b592f4 100644
> --- a/arch/parisc/kernel/firmware.c
> +++ b/arch/parisc/kernel/firmware.c
> @@ -1232,15 +1232,18 @@ int __init pdc_soft_power_info(unsigned long
> *power_reg)
> }
>
> /*
> - * pdc_soft_power_button - Control the soft power button behaviour
> - * @sw_control: 0 for hardware control, 1 for software control
> + * pdc_soft_power_button{_panic} - Control the soft power button behaviour
> + * @sw_control: 0 for hardware control, 1 for software control
> *
> *
> * This PDC function places the soft power button under software or
> * hardware control.
> - * Under software control the OS may control to when to allow to shut
> - * down the system. Under hardware control pressing the power button
> + * Under software control the OS may control to when to allow to shut
> + * down the system. Under hardware control pressing the power button
> * powers off the system immediately.
> + *
> + * The _panic version relies in spin_trylock to prevent deadlock
> + * on panic path.
> */
> int pdc_soft_power_button(int sw_control)
> {
> @@ -1254,6 +1257,22 @@ int pdc_soft_power_button(int sw_control)
> return retval;
> }
>
> +int pdc_soft_power_button_panic(int sw_control)
> +{
> + int retval;
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(_lock, flags)) {
> + pr_emerg("Couldn't enable soft power button\n");
> + return -EBUSY; /* ignored by the panic notifier */
> + }
> +
> + retval = mem_pdc_call(PDC_SOFT_POWER, PDC_SOFT_POWER_ENABLE,
> __pa(pdc_result), sw_control);
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return retval;
> +}
> +
> /*
> * pdc_io_reset - Hack to avoid overlapping range registers of Bridges
> devices.
> * Primarily a problem on T600 (which parisc-linux doesn't support) but
> diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
> index 456776bd8ee6..8512884de2cf 100644
> --- a/drivers/parisc/power.c
> +++ b/drivers/parisc/power.c
> @@ -37,7 +37,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -175,16 +174,21 @@ static void powerfail_interrupt(int code, void *x)
>
>
>
> -/* parisc_panic_event() is called by the panic handler.
> - * As soon as a panic occurs, our tasklets above will not be
> - * executed any longer. This function then re-enables the
> - * soft-power switch and allows the user to switch off the system
> +/*
> + * parisc_panic_event() is called by the panic handler.
> + *
> + * As soon as a panic occurs, our tasklets above will not
> + * be executed any longer. This function then re-enables
> + * the soft-power switch and allows the user to switch off
> + * the system. We rely in pdc_soft_power_button_panic()
> + * since this version spin_trylocks (instead of regular
> + * spinlock), preventing deadlocks on panic path.
> */
> static int parisc_panic_event(struct notifier_block *this,
> unsigned long event, void *ptr)
> {
> /* re-enable the soft-power switch */
> - pdc_soft_power_button(0);
> + pdc_soft_power_button_panic(0);
> return NOTIFY_DONE;
> }
>
> @@ -193,7 +197,6 @@ static struct notifier_block parisc_panic_block = {
> .priority = INT_MAX,
> };
>
> -
> static int __init power_init(void)
> {
> unsigned long ret;
[qemu-mainline test] 169801: tolerable FAIL - PUSHED
flight 169801 qemu-mainline real [real] flight 169825 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169801/ http://logs.test-lab.xenproject.org/osstest/logs/169825/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-coresched-i386-xl 14 guest-start fail pass in 169825-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169779 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169779 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169779 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169779 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169779 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169779 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169779 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169779 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: qemuucf6f26d6f9b2015ee12b4604b79359e76784163a baseline version: qemuu34723f59371f3fd02ea59b94674314b875504426 Last test of basis 169779 2022-04-27 10:34:36 Z
Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list
On Wed, Apr 27, 2022 at 07:49:15PM -0300, Guilherme G. Piccoli wrote: > This patch renames the panic_notifier_list to panic_pre_reboot_list; > the idea is that a subsequent patch will refactor the panic path > in order to better split the notifiers, running some of them very > early, some of them not so early [but still before kmsg_dump()] and > finally, the rest should execute late, after kdump. The latter ones > are now in the panic pre-reboot list - the name comes from the idea > that these notifiers execute before panic() attempts rebooting the > machine (if that option is set). > > We also took the opportunity to clean-up useless header inclusions, > improve some notifier block declarations (e.g. in ibmasm/heartbeat.c) > and more important, change some priorities - we hereby set 2 notifiers > to run late in the list [iss_panic_event() and the IPMI panic_event()] > due to the risks they offer (may not return, for example). > Proper documentation is going to be provided in a subsequent patch, > that effectively refactors the panic path. For the IPMI portion: Acked-by: Corey Minyard Note that the IPMI panic_event() should always return, but it may take some time, especially if the IPMI controller is no longer functional. So the risk of a long delay is there and it makes sense to move it very late. -corey > > Cc: Alex Elder > Cc: Alexander Gordeev > Cc: Anton Ivanov > Cc: Benjamin Herrenschmidt > Cc: Bjorn Andersson > Cc: Boris Ostrovsky > Cc: Chris Zankel > Cc: Christian Borntraeger > Cc: Corey Minyard > Cc: Dexuan Cui > Cc: "H. Peter Anvin" > Cc: Haiyang Zhang > Cc: Heiko Carstens > Cc: Helge Deller > Cc: Ivan Kokshaysky > Cc: "James E.J. Bottomley" > Cc: James Morse > Cc: Johannes Berg > Cc: Juergen Gross > Cc: "K. Y. Srinivasan" > Cc: Mathieu Poirier > Cc: Matt Turner > Cc: Mauro Carvalho Chehab > Cc: Max Filippov > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Pavel Machek > Cc: Richard Henderson > Cc: Richard Weinberger > Cc: Robert Richter > Cc: Stefano Stabellini > Cc: Stephen Hemminger > Cc: Sven Schnelle > Cc: Tony Luck > Cc: Vasily Gorbik > Cc: Wei Liu > Signed-off-by: Guilherme G. Piccoli > --- > > Notice that, with this name change, out-of-tree code that relies in the global > exported "panic_notifier_list" will fail to build. We could easily keep the > retro-compatibility by making the old symbol to still exist and point to the > pre_reboot list (or even, keep the old naming). > > But our design choice was to allow the breakage, making users rethink their > notifiers, adding them in the list that fits best. If that wasn't a good > decision, we're open to change it, of course. > Thanks in advance for the review! > > arch/alpha/kernel/setup.c | 4 ++-- > arch/parisc/kernel/pdc_chassis.c | 3 +-- > arch/powerpc/kernel/setup-common.c| 2 +- > arch/s390/kernel/ipl.c| 4 ++-- > arch/um/drivers/mconsole_kern.c | 2 +- > arch/um/kernel/um_arch.c | 2 +- > arch/x86/xen/enlighten.c | 2 +- > arch/xtensa/platforms/iss/setup.c | 4 ++-- > drivers/char/ipmi/ipmi_msghandler.c | 12 +++- > drivers/edac/altera_edac.c| 3 +-- > drivers/hv/vmbus_drv.c| 4 ++-- > drivers/leds/trigger/ledtrig-panic.c | 3 +-- > drivers/misc/ibmasm/heartbeat.c | 16 +--- > drivers/net/ipa/ipa_smp2p.c | 5 ++--- > drivers/parisc/power.c| 4 ++-- > drivers/remoteproc/remoteproc_core.c | 6 -- > drivers/s390/char/con3215.c | 2 +- > drivers/s390/char/con3270.c | 2 +- > drivers/s390/char/sclp_con.c | 2 +- > drivers/s390/char/sclp_vt220.c| 2 +- > drivers/staging/olpc_dcon/olpc_dcon.c | 6 -- > drivers/video/fbdev/hyperv_fb.c | 4 ++-- > include/linux/panic_notifier.h| 2 +- > kernel/panic.c| 9 - > 24 files changed, 54 insertions(+), 51 deletions(-) > > diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c > index d88bdf852753..8ace0d7113b6 100644 > --- a/arch/alpha/kernel/setup.c > +++ b/arch/alpha/kernel/setup.c > @@ -472,8 +472,8 @@ setup_arch(char **cmdline_p) > } > > /* Register a call for panic conditions. */ > - atomic_notifier_chain_register(_notifier_list, > - _panic_block); > + atomic_notifier_chain_register(_pre_reboot_list, > + _panic_block); > > #ifndef alpha_using_srm > /* Assume that we've booted from SRM if we haven't booted from MILO. > diff --git a/arch/parisc/kernel/pdc_chassis.c > b/arch/parisc/kernel/pdc_chassis.c > index da154406d368..0fd8d87fb4f9 100644 > --- a/arch/parisc/kernel/pdc_chassis.c > +++ b/arch/parisc/kernel/pdc_chassis.c > @@ -22,7 +22,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -135,7 +134,7 @@ void __init
Re: [PATCH] MAINTAINERS: add Rahul as SMMU maintainer
Hi, On 26/04/2022 21:27, Stefano Stabellini wrote: Add Rahul as ARM SMMU maintainer. Create a new explicit entry for "ARM SMMU" also with Julien which is the original contributor of the code and continues to maintain it. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v4 1/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
On 27.04.2022 12:47, Roger Pau Monne wrote: > Use the logic to set shadow SPEC_CTRL values in order to implement > support for VIRT_SPEC_CTRL (signaled by VIRT_SSBD CPUID flag) for HVM > guests. This includes using the spec_ctrl vCPU MSR variable to store > the guest set value of VIRT_SPEC_CTRL.SSBD, which will be OR'ed with > any SPEC_CTRL values being set by the guest. > > On hardware having SPEC_CTRL VIRT_SPEC_CTRL will not be offered by > default to guests. VIRT_SPEC_CTRL will only be part of the max CPUID > policy so it can be enabled for compatibility purposes. > > Use '!' to annotate the feature in order to express that the presence > of the bit is not directly tied to its value in the host policy. > > Suggested-by: Andrew Cooper > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich
x86/PV: (lack of) MTRR exposure
Hello, in the course of analyzing the i915 driver causing boot to fail in Linux 5.18 I found that Linux, for all the years, has been running in PV mode as if PAT was (mostly) disabled. This is a result of them tying PAT initialization to MTRR initialization, while we offer PAT but not MTRR in CPUID output. This was different before our moving to CPU featuresets, and as such one could view this behavior as a regression from that change. The first question here is whether not exposing MTRR as a feature was really intended, in particular also for PV Dom0. The XenoLinux kernel and its forward ports did make use of XENPF_*_memtype to deal with MTRRs. That's functionality which (maybe for a good reason) never made it into the pvops kernel. Note that PVH Dom0 does have access to the original settings, as the host values are used as initial state there. The next question would be how we could go about improving the situation. For the particular issue in 5.18 I've found a relatively simple solution [1] (which also looks to help graphics performance on other systems, according to my initial observations with using the change), albeit its simplicity likely means it either is wrong in some way, or might not be liked for looking hacky and/or abusive. We can't, for example, simply turn on the MTRR bit in CPUID, as that would implicitly lead to the kernel trying to write the PAT MSR (if, see below, it didn't itself zap the bit). We also can't simply ignore PAT MSR writes, as the kernel won't check whether writes actually took effect. (All of that did work on top of old Xen apparently only because xen_init_capabilities() itself also forces the MTRR feature to off.) Jan [1] https://lists.xen.org/archives/html/xen-devel/2022-04/msg02392.html
[xen-unstable-smoke test] 169807: regressions - FAIL
flight 169807 xen-unstable-smoke real [real] flight 169817 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169807/ http://logs.test-lab.xenproject.org/osstest/logs/169817/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169800 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 2c992810854a15b41be920519ce83a4a328d5168 baseline version: xen da28439ba55b8a571032b3358af567cff749f612 Last test of basis 169800 2022-04-27 23:01:43 Z0 days Testing same since 169807 2022-04-28 09:01:41 Z0 days1 attempts People who touched revisions under test: Artem Bityutskiy Jan Beulich Juergen Gross Rafael J. Wysocki 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 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 2c992810854a15b41be920519ce83a4a328d5168 Author: Jan Beulich Date: Thu Apr 28 10:00:49 2022 +0200 x86+libxl: correct p2m (shadow) memory pool size calculation The reference "to shadow the resident processes" is applicable to domains (potentially) running in shadow mode only. Adjust the calculations accordingly. This, however, requires further parameters. Since the original function is deprecated anyway, and since it can't be changed (for being part of a stable ABI), introduce a new (internal only) function, with the deprecated one simply becoming a wrapper. In dom0_paging_pages() also take the opportunity and stop open-coding DIV_ROUND_UP(). Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Reviewed-by: Anthony PERARD commit 9c432b876bf518866d431bda73f2be1250f688eb Author: Artem Bityutskiy Date: Thu Apr 28 10:00:18 2022 +0200 x86/mwait-idle: add SPR support Add Sapphire Rapids Xeon support. Up until very recently, the C1 and C1E C-states were independent, but this has changed in some new chips, including Sapphire Rapids Xeon (SPR). In these chips the C1 and C1E states cannot be enabled at the same time. The "C1E promotion" bit in 'MSR_IA32_POWER_CTL' also has its semantics changed a bit. Here are the C1, C1E, and "C1E promotion" bit rules on Xeons before SPR. 1. If C1E promotion bit is disabled. a. C1 requests end up with C1 C-state. b. C1E requests end up with C1E C-state. 2. If C1E promotion bit is enabled. a. C1 requests end up with C1E C-state. b. C1E requests end up with C1E C-state. Here are the C1, C1E, and "C1E promotion" bit rules on Sapphire Rapids Xeon. 1. If C1E promotion bit is disabled. a. C1 requests end up with C1 C-state. b. C1E requests end up with C1 C-state. 2. If C1E promotion bit is enabled. a. C1 requests end up with C1E C-state. b. C1E requests end up with C1E C-state. Before SPR Xeon, the 'intel_idle' driver was disabling C1E promotion and was exposing C1 and C1E as independent C-states. But on SPR, C1 and C1E cannot be enabled at the same time. This patch adds both C1 and C1E states. However, C1E is marked as with the "CPUIDLE_FLAG_UNUSABLE" flag, which means that in won't be registered by default. The C1E promotion bit will be cleared, which means that by default only C1 and C6 will be registered on SPR. The next patch will add an option for
[ovmf test] 169816: regressions - FAIL
flight 169816 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169816/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d372ab585a2cdc5348af5f701c56c631235fe698 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 680 attempts Testing same since 169816 2022-04-28 14:41:38 Z0 days1 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5844 lines long.)
[xen-unstable test] 169798: regressions - FAIL
flight 169798 xen-unstable real [real] flight 169813 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169798/ http://logs.test-lab.xenproject.org/osstest/logs/169813/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 169775 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 169775 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 169775 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 169775 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 169775 Tests which are failing intermittently (not blocking): test-amd64-i386-examine 6 xen-install fail pass in 169813-retest Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169775 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169775 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169775 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169775 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169775 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169775 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169775 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169775 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169775 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169775 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169775 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169775 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169775 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass
Re: [PATCH v3 1/2] xsm: create idle domain privileged and demote after setup
On 4/26/22 03:12, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 12:39:17PM -0400, Daniel P. Smith wrote:
>> On 4/25/22 05:44, Roger Pau Monné wrote:
>>> On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..e71fa3f860 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1048,6 +1048,9 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Hide UART from DOM0 if we're using it */
serial_endboot();
+if ( xsm_set_system_active() != 0)
+panic("xsm: unable to set hypervisor to SYSTEM_ACTIVE
privilege\n");
+
system_state = SYS_STATE_active;
for_each_domain( d )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6f20e17892..a3ce288ef9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -621,6 +621,9 @@ static void noreturn init_done(void)
void *va;
unsigned long start, end;
+if ( xsm_set_system_active() != 0)
>>>^ extra space.
>>>
>>> Since the function returns an error code you might as well add it to
>>> the panic message, or else just make the function return bool instead.
>>>
>>> Or just make the function void and panic in the handler itself (like
>>> in previous versions), as I don't think it's sensible to continue
>>> normal execution if xsm_set_system_active fails.
>>
>> After reflecting on it, I believe that was not the correct action. The
>> policy should handle setting/checking all access control state and fail
>> with an error of why and then allow the hypervisor logic decided what to
>> do with that failure. For the policies that are present today, yes it is
>> an immediate panic. Ultimately this will future proof the interface
>> should a future policy type be introduced with a more varied result that
>> could allow the hypervisor to continue to boot, for instance to a
>> limited and/or debug state.
>
> That's all fine, but if you return an error code, please print it as
> part of the panic message. The more information we can add in case of
> panic, the better.
Ack.
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8c044ef615..e6ffa948f7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -14,6 +14,7 @@
#include
static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
+.set_system_active = xsm_set_system_active,
.security_domaininfo = xsm_security_domaininfo,
.domain_create = xsm_domain_create,
.getdomaininfo = xsm_getdomaininfo,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0bf63ffa84..8a62de2fd6 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -186,6 +186,26 @@ static int cf_check
flask_domain_alloc_security(struct domain *d)
return 0;
}
+static int cf_check flask_set_system_active(void)
+{
+struct domain *d = current->domain;
>>>
>>> Nit: you should also add the assert for d->is_privileged, I don't see
>>> a reason for the xsm and flask functions to differ in that regard.
>>
>> This goes back to an issued I have raised before, is_privileged really
>> encompasses two properties of a domain. Whether the domain is filling
>> the special control domain role versus what accesses the domain has
>> based on the context under which is_control_domain() is called. For
>> instance the function init_domain_msr_policy() uses is_control_domain()
>> not to make an access control decision but configure behavior. Under
>> flask is_privileged no longer reflects the accesses a domain with it set
>> will have, thus whether it is cleared when flask is enabled is
>> irrelevant as far as flask is concerned. For the ASSERT, what matters is
>> that the label was set to xenboot_t on construction and that it was not
>> changed before reaching this point. Or in a short form, when under the
>> default policy the expected state is concerned with is_privilege while
>> for flask it is only the SID.
>
> I certainly don't care that much, but you do set d->is_privileged =
> false in flask_set_system_active, hence it would seem logic to expect
> d->is_privileged == true also?
Yes, I did this just for consistency not because there is any
significance of is_privilege on the idle domain, in both contexts for
which is_privileged is used, when flask is the enforcing policy.
> If not for anything else, just to assert that the function is not
> called twice.
Under this patch flask_set_system_active() is effectively a no-op, so
calling it twice has no effect. In the next patch flask_set_system()
becomes a real check and there is an ASSERT on the SID as that is the
relevant context under flask and will ensure calling only once.
In the end I can add the ASSERT but it
Re: [PATCH] cirrus-ci: add myself as maintainer
On 28/04/2022 10:55, Roger Pau Monne wrote: > Given the testing done by Cirrus-CI is FreeBSD only introduce a new > section in the MAINTAINERS file to cover it and add myself as the > maintainer. > > Requested-by: Stefano Stabellini > Signed-off-by: Roger Pau Monné > --- > FWIW, I wouldn't mind it being part of the "Continuous Integration > (CI)" section, but I understand maintainers there could prefer a > separate section since this is ATM FreeBSD only testing. I don't think we have enough review bandwidth to separate things like this. Plenty of changes to CI are dependency tweaks which cover all CI files in one go, so wouldn't be directly relevant to being FreeBSD. Also some CI changes need superpowers in other systems. I'd just add yourself to the general section. It's not as if you're an unknown person to the project... (and tbh, I should be in their too.) Tangentially, we should prune the final bits of Travis, and add .github/. ~Andrew
[PATCH] x86/PAT: have pat_enabled() properly reflect state when running on e.g. Xen
The latest with commit bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT
with pat_enabled()") pat_enabled() returning false (because of PAT
initialization being suppressed in the absence of MTRRs being announced
to be available) has become a problem: The i915 driver now fails to
initialize when running PV on Xen (i915_gem_object_pin_map() is where I
located the induced failure), and its error handling is flaky enough to
(at least sometimes) result in a hung system.
Yet even beyond that problem the keying of the use of WC mappings to
pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
graphics frame buffer accesses would have been quite a bit less
performant than possible.
Arrange for the function to return true in such environments, without
undermining the rest of PAT MSR management logic considering PAT to be
disabled: Specifically, no writes to the PAT MSR should occur.
For the new boolean to live in .init.data, init_cache_modes() also needs
moving to .init.text (where it could/should have lived already before).
Signed-off-by: Jan Beulich
---
On the system where I observed the issue, a knock-on effect of driver
initialization failing was that the SATA-controller also started to
report failures.
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -62,6 +62,7 @@
static bool __read_mostly pat_bp_initialized;
static bool __read_mostly pat_disabled = !IS_ENABLED(CONFIG_X86_PAT);
+static bool __initdata pat_force_disabled = !IS_ENABLED(CONFIG_X86_PAT);
static bool __read_mostly pat_bp_enabled;
static bool __read_mostly pat_cm_initialized;
@@ -86,6 +87,7 @@ void pat_disable(const char *msg_reason)
static int __init nopat(char *str)
{
pat_disable("PAT support disabled via boot option.");
+ pat_force_disabled = true;
return 0;
}
early_param("nopat", nopat);
@@ -272,7 +274,7 @@ static void pat_ap_init(u64 pat)
wrmsrl(MSR_IA32_CR_PAT, pat);
}
-void init_cache_modes(void)
+void __init init_cache_modes(void)
{
u64 pat = 0;
@@ -313,6 +315,13 @@ void init_cache_modes(void)
*/
pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
+ } else if (!pat_force_disabled &&
+ boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+ /*
+* Clearly PAT is enabled underneath. Allow pat_enabled() to
+* reflect this.
+*/
+ pat_bp_enabled = true;
}
__init_cache_modes(pat);
[libvirt test] 169805: regressions - FAIL
flight 169805 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169805/ 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 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 381498796cb45dfa80cbfe3f9834072808c691f6 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 657 days Failing since151818 2020-07-11 04:18:52 Z 656 days 638 attempts Testing same since 169805 2022-04-28 04:20:08 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Praveen K
Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list
On 4/27/22 5:49 PM, Guilherme G. Piccoli wrote: This patch renames the panic_notifier_list to panic_pre_reboot_list; the idea is that a subsequent patch will refactor the panic path in order to better split the notifiers, running some of them very early, some of them not so early [but still before kmsg_dump()] and finally, the rest should execute late, after kdump. The latter ones are now in the panic pre-reboot list - the name comes from the idea that these notifiers execute before panic() attempts rebooting the machine (if that option is set). We also took the opportunity to clean-up useless header inclusions, improve some notifier block declarations (e.g. in ibmasm/heartbeat.c) and more important, change some priorities - we hereby set 2 notifiers to run late in the list [iss_panic_event() and the IPMI panic_event()] due to the risks they offer (may not return, for example). Proper documentation is going to be provided in a subsequent patch, that effectively refactors the panic path. Cc: Alex Elder For "drivers/net/ipa/ipa_smp2p.c": Acked-by: Alex Elder Cc: Alexander Gordeev Cc: Anton Ivanov Cc: Benjamin Herrenschmidt Cc: Bjorn Andersson Cc: Boris Ostrovsky Cc: Chris Zankel Cc: Christian Borntraeger Cc: Corey Minyard Cc: Dexuan Cui Cc: "H. Peter Anvin" Cc: Haiyang Zhang Cc: Heiko Carstens Cc: Helge Deller Cc: Ivan Kokshaysky Cc: "James E.J. Bottomley" Cc: James Morse Cc: Johannes Berg Cc: Juergen Gross Cc: "K. Y. Srinivasan" Cc: Mathieu Poirier Cc: Matt Turner Cc: Mauro Carvalho Chehab Cc: Max Filippov Cc: Michael Ellerman Cc: Paul Mackerras Cc: Pavel Machek Cc: Richard Henderson Cc: Richard Weinberger Cc: Robert Richter Cc: Stefano Stabellini Cc: Stephen Hemminger Cc: Sven Schnelle Cc: Tony Luck Cc: Vasily Gorbik Cc: Wei Liu Signed-off-by: Guilherme G. Piccoli --- . . .
[ovmf test] 169815: regressions - FAIL
flight 169815 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169815/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 679 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 51 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
Re: [PATCH] arm/its: enable LPIs before mapping the collection table
Hi Julien,
> On 28 Apr 2022, at 1:59 pm, Julien Grall wrote:
>
>
>
> On 28/04/2022 11:00, Rahul Singh wrote:
>> Hi Julien,
>>> On 27 Apr 2022, at 6:59 pm, Julien Grall wrote:
>>>
>>> Hi Rahul,
>>>
>>> On 27/04/2022 17:14, Rahul Singh wrote:
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
>>>
>>> Looking at the spec (ARM IHI 0069H), I can't find a command error named
>>> MAPC_LPI_OFF. Is it something specific to your HW?
>> I found the issue on HW that implements GIC-600 and GIC-600 TRM specify the
>> MAPC_LPI_OFF its command error.
>> https://developer.arm.com/documentation/100336/0106/introduction/about-the-gic-600
>> {Table 3-15 ITS command and translation errors, records 13+ page 3-89}
>
> Please provide a pointer to the spec in the commit message. This would help
> the reviewer to know where MAPC_LPI_OFF come from.
Ok.
>
>>>
not enabled before mapping the collection table using MAPC command.
Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
table.
Signed-off-by: Rahul Singh
---
xen/arch/arm/gic-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 3c472ed768..8fb0014b16 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -812,11 +812,11 @@ static int gicv3_cpu_init(void)
/* If the host has any ITSes, enable LPIs now. */
if ( gicv3_its_host_has_its() )
{
+ if ( !gicv3_enable_lpis() )
+ return -EBUSY;
ret = gicv3_its_setup_collection(smp_processor_id());
if ( ret )
return ret;
- if ( !gicv3_enable_lpis() )
- return -EBUSY;
>>>
>>> AFAICT, Linux is using the same ordering as your are proposing. It seems to
>>> have been introduced from the start, so it is not clear why we chose this
>>> approach.
>> Yes I also confirmed that before sending the patch for review. I think this
>> is okay if we enable the enable LPIs before mapping the collection table.
>
> In general, I expect change touching the GICv3 code based on the
> specification rather than "we think this is okay". This reduce the risk to
> make modification that could break other platforms (we can't possibly test
> all of them).
>
> Reading through the spec, the definition of GICR.EnableLPIs contains the
> following:
>
> "
> 0b0 LPI support is disabled. Any doorbell interrupt generated as a result of
> a write to a virtual LPI register must be discarded, and any ITS translation
> requests or commands involving LPIs in this Redistributor are ignored.
>
> 0b1 LPI support is enabled.
> "
>
> So your change is correct. But the commit message needs to be updated with
> more details on which GIC HW the issue was seen and why your proposal is
> correct (i.e. quoting the spec).
Ok. I will modify the commit msg as below.Please let me know if it is okay.
arm/its: enable LPIs before mapping the collection table
When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is oberved.
As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be reported if the ITS MAPC command has tried to map a collection to a core
that does not have LPIs enabled.
To fix this issue, enable the LPIs using GICR_CTLR.EnableLPIs before
mapping the collection table.
Regards,
Rahul
Re: [PATCH 3/3] x86/monitor: Add new monitor event to catch all vmexits
On Thu, Apr 28, 2022 at 9:56 AM Roger Pau Monné wrote: > > On Wed, Apr 27, 2022 at 11:34:20AM -0400, Tamas K Lengyel wrote: > > Add monitor event that hooks the vmexit handler allowing for both sync and > > async monitoring of events. With async monitoring an event is placed on the > > monitor ring for each exit and the rest of the vmexit handler resumes > > normally. > > If there are additional monitor events configured those will also place > > their > > respective events on the monitor ring. > > > > With the sync version an event is placed on the monitor ring but the handler > > does not get resumed, thus the sync version is only useful when the VM is > > not > > expected to resume normally after the vmexit. Our use-case is primarily with > > the sync version with VM forks where the fork gets reset after sync vmexit > > event, thus the rest of the vmexit handler can be safely skipped. This is > > very useful when we want to avoid Xen crashing the VM under any > > circumstance, > > for example during fuzzing. Collecting all vmexit information regardless of > > the root cause makes it easier to reason about the state of the VM on the > > monitor side, hence we opt to receive all events, even for external > > interrupt > > and NMI exits and let the monitor agent decide how to proceed. > > > > Signed-off-by: Tamas K Lengyel > > Reviewed-by: Roger Pau Monné > > Thanks, Roger. Thank you! Tamas
Re: [PATCH 3/3] x86/monitor: Add new monitor event to catch all vmexits
On Wed, Apr 27, 2022 at 11:34:20AM -0400, Tamas K Lengyel wrote: > Add monitor event that hooks the vmexit handler allowing for both sync and > async monitoring of events. With async monitoring an event is placed on the > monitor ring for each exit and the rest of the vmexit handler resumes > normally. > If there are additional monitor events configured those will also place their > respective events on the monitor ring. > > With the sync version an event is placed on the monitor ring but the handler > does not get resumed, thus the sync version is only useful when the VM is not > expected to resume normally after the vmexit. Our use-case is primarily with > the sync version with VM forks where the fork gets reset after sync vmexit > event, thus the rest of the vmexit handler can be safely skipped. This is > very useful when we want to avoid Xen crashing the VM under any circumstance, > for example during fuzzing. Collecting all vmexit information regardless of > the root cause makes it easier to reason about the state of the VM on the > monitor side, hence we opt to receive all events, even for external interrupt > and NMI exits and let the monitor agent decide how to proceed. > > Signed-off-by: Tamas K Lengyel Reviewed-by: Roger Pau Monné Thanks, Roger.
Re: Virtio on Xen with Rust
On Thu, Apr 14, 2022 at 12:15 PM Viresh Kumar wrote: > Hello, > Hello Viresh [Cc Juergen and Julien] [sorry for the possible format issues and for the late response] > > We verified our hypervisor-agnostic Rust based vhost-user backends with > Qemu > based setup earlier, and there was growing concern if they were truly > hypervisor-agnostic. > > In order to prove that, we decided to give it a try with Xen, a type-1 > bare-metal hypervisor. > > We are happy to announce that we were able to make progress on that front > and > have a working setup where we can test our existing Rust based backends, > like > I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > Great work! > > Key components: > -- > > - Xen: https://github.com/vireshk/xen > > Xen requires MMIO and device specific support in order to populate the > required devices at the guest. This tree contains four patches on the > top of > mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > I skimmed through your toolstack patches, awesome, you created a completely new virtual device "I2C". FYI, I have updated "Virtio support for toolstack on Arm" [1] since (to make it more generic), now V7 is available and I have a plan to push V8 soon. > > - libxen-sys: https://github.com/vireshk/libxen-sys > > We currently depend on the userspace tools/libraries provided by Xen, > like > xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides > Rust > wrappers over those calls, generated automatically with help of bindgen > utility in Rust, that allow us to use the installed Xen libraries. > Though we > plan to replace this with Rust based "oxerun" (find below) in longer run. > - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > > This is Rust based implementations for Ioctl and hypercalls to Xen. This > is WIP > and should eventually replace "libxen-sys" crate entirely (which are C > based > implementation of the same). > FYI, currently we are working on one feature to restrict memory access using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1]. And there is a working PoC on Arm based on an updated virtio-disk. As for libraries, there is a new dependency on "xengnttab" library. In comparison with Xen foreign mappings model (xenforeignmemory), the Xen grant mappings model is a good fit into the Xen security model, this is a safe mechanism to share pages between guests. > > - vhost-device: https://github.com/vireshk/vhost-device > > These are Rust based vhost-user backends, maintained inside the rust-vmm > project. This already contain support for I2C and RNG, while GPIO is > under > review. These are not required to be modified based on hypervisor and are > truly hypervisor-agnostic. > > Ideally the backends are hypervisor agnostic, as explained earlier, but > because of the way Xen maps the guest memory currently, we need a minor > update > for the backends to work. Xen maps the memory via a kernel file > /dev/xen/privcmd, which needs calls to mmap() followed by an ioctl() to > make > it work. For this a hack has been added to one of the rust-vmm crates, > vm-virtio, which is used by vhost-user. > > > https://github.com/vireshk/vm-memory/commit/54b56c4dd7293428edbd7731c4dbe5739a288abd > > The update to vm-memory is responsible to do ioctl() after the already > present > mmap(). > With Xen grant mappings, if I am not mistaken, it is going to be almost the same: mmap() then ioctl(). But the file will be "/dev/xen/gntdev". > > - vhost-user-master (WIP): https://github.com/vireshk/vhost-user-master > > This implements the master side interface of the vhost protocol, and is > like > the vhost-user-backend (https://github.com/rust-vmm/vhost-user-backend) > crate > maintained inside the rust-vmm project, which provides similar > infrastructure > for the backends to use. This shall be hypervisor independent and > provide APIs > for the hypervisor specific implementations. This will eventually be > maintained inside the rust-vmm project and used by all Rust based > hypervisors. > > - xen-vhost-master (WIP): https://github.com/vireshk/xen-vhost-master > > This is the Xen specific implementation and uses the APIs provided by > "vhost-user-master", "oxerun" and "libxen-sys" crates for its > functioning. > > This is designed based on the EPAM's "virtio-disk" repository > (https://github.com/xen-troops/virtio-disk/) and is pretty much similar > to it. > FYI, new branch "virtio_grant" besides supporting Xen grant mappings also supports virtio-mmio modern transport. > > One can see the analogy as: > > Virtio-disk == "Xen-vhost-master" + "vhost-user-master" + "oxerun" + > "libxen-sys" + "vhost-device". > > > > Test setup: > -- > > 1. Build Xen: > > $ ./configure --libdir=/usr/lib --build=x86_64-unknown-linux-gnu > --host=aarch64-linux-gnu --disable-docs --disable-golang >
[ovmf test] 169814: regressions - FAIL
flight 169814 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169814/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 678 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 50 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote: > > Reported-by: Rahul Singh > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Stefano Stabellini Do you want to take this through the Xen tree or should I pick it up? Either way I'd love to see some testing on x86 as well.
Re: [PATCH] arm/its: enable LPIs before mapping the collection table
On 28/04/2022 11:00, Rahul Singh wrote:
Hi Julien,
On 27 Apr 2022, at 6:59 pm, Julien Grall wrote:
Hi Rahul,
On 27/04/2022 17:14, Rahul Singh wrote:
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
Looking at the spec (ARM IHI 0069H), I can't find a command error named
MAPC_LPI_OFF. Is it something specific to your HW?
I found the issue on HW that implements GIC-600 and GIC-600 TRM specify the
MAPC_LPI_OFF its command error.
https://developer.arm.com/documentation/100336/0106/introduction/about-the-gic-600
{Table 3-15 ITS command and translation errors, records 13+ page 3-89}
Please provide a pointer to the spec in the commit message. This would
help the reviewer to know where MAPC_LPI_OFF come from.
not enabled before mapping the collection table using MAPC command.
Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
table.
Signed-off-by: Rahul Singh
---
xen/arch/arm/gic-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 3c472ed768..8fb0014b16 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -812,11 +812,11 @@ static int gicv3_cpu_init(void)
/* If the host has any ITSes, enable LPIs now. */
if ( gicv3_its_host_has_its() )
{
+ if ( !gicv3_enable_lpis() )
+ return -EBUSY;
ret = gicv3_its_setup_collection(smp_processor_id());
if ( ret )
return ret;
- if ( !gicv3_enable_lpis() )
- return -EBUSY;
AFAICT, Linux is using the same ordering as your are proposing. It seems to
have been introduced from the start, so it is not clear why we chose this
approach.
Yes I also confirmed that before sending the patch for review. I think this is
okay if we enable the enable LPIs before mapping the collection table.
In general, I expect change touching the GICv3 code based on the
specification rather than "we think this is okay". This reduce the risk
to make modification that could break other platforms (we can't possibly
test all of them).
Reading through the spec, the definition of GICR.EnableLPIs contains the
following:
"
0b0 LPI support is disabled. Any doorbell interrupt generated as a
result of a write to a virtual LPI register must be discarded, and any
ITS translation requests or commands involving LPIs in this
Redistributor are ignored.
0b1 LPI support is enabled.
"
So your change is correct. But the commit message needs to be updated
with more details on which GIC HW the issue was seen and why your
proposal is correct (i.e. quoting the spec).
Cheers,
--
Julien Grall
[ovmf test] 169812: regressions - FAIL
flight 169812 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169812/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 677 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 49 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
[ovmf test] 169811: regressions - FAIL
flight 169811 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169811/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 676 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 48 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
Re: [PATCH v3] x86/msr: handle reads to MSR_P5_MC_{ADDR,TYPE}
On 28.04.2022 13:20, Roger Pau Monne wrote:
> Windows Server 2019 Essentials will unconditionally attempt to read
> P5_MC_ADDR MSR at boot and throw a BSOD if injected a #GP.
>
> Fix this by mapping MSR_P5_MC_{ADDR,TYPE} to
> MSR_IA32_MCi_{ADDR,STATUS}, as reported also done by hardware in Intel
> SDM "Mapping of the Pentium Processor Machine-Check Errors to the
> Machine-Check Architecture" section.
>
> Reported-by: Steffen Einsle
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
[PATCH v3] x86/msr: handle reads to MSR_P5_MC_{ADDR,TYPE}
Windows Server 2019 Essentials will unconditionally attempt to read
P5_MC_ADDR MSR at boot and throw a BSOD if injected a #GP.
Fix this by mapping MSR_P5_MC_{ADDR,TYPE} to
MSR_IA32_MCi_{ADDR,STATUS}, as reported also done by hardware in Intel
SDM "Mapping of the Pentium Processor Machine-Check Errors to the
Machine-Check Architecture" section.
Reported-by: Steffen Einsle
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Use fallthrough pseudo keyword.
- Expand comment about bank 0 quirk.
- Change condition for early exit from vmce_intel_rdmsr.
Changes since v1:
- Implement in vmce_rdmsr.
---
xen/arch/x86/cpu/mcheck/mce.h| 6 ++
xen/arch/x86/cpu/mcheck/mce_intel.c | 19 +++
xen/arch/x86/cpu/mcheck/vmce.c | 2 ++
xen/arch/x86/include/asm/msr-index.h | 3 +++
xen/arch/x86/msr.c | 2 ++
5 files changed, 32 insertions(+)
diff --git a/xen/arch/x86/cpu/mcheck/mce.h b/xen/arch/x86/cpu/mcheck/mce.h
index 535d0abf8f..bea08bdc74 100644
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -169,6 +169,12 @@ static inline int mce_vendor_bank_msr(const struct vcpu
*v, uint32_t msr)
if (msr >= MSR_IA32_MC0_CTL2 &&
msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) )
return 1;
+fallthrough;
+
+case X86_VENDOR_CENTAUR:
+case X86_VENDOR_SHANGHAI:
+if (msr == MSR_P5_MC_ADDR || msr == MSR_P5_MC_TYPE)
+return 1;
break;
case X86_VENDOR_AMD:
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c
b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 50198e0c29..28a605a5cb 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1008,8 +1008,27 @@ int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr,
uint64_t val)
int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
{
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
unsigned int bank = msr - MSR_IA32_MC0_CTL2;
+switch ( msr )
+{
+case MSR_P5_MC_ADDR:
+/*
+ * Bank 0 is used for the 'bank 0 quirk' on older processors.
+ * See vcpu_fill_mc_msrs() for reference.
+ */
+*val = v->arch.vmce.bank[1].mci_addr;
+return 1;
+
+case MSR_P5_MC_TYPE:
+*val = v->arch.vmce.bank[1].mci_status;
+return 1;
+}
+
+if ( !(cp->x86_vendor & X86_VENDOR_INTEL) )
+return 0;
+
if ( bank < GUEST_MC_BANK_NUM )
{
*val = v->arch.vmce.bank[bank].mci_ctl2;
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 458120f9ad..af30811afd 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -150,6 +150,8 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t
msr, uint64_t *val)
default:
switch ( boot_cpu_data.x86_vendor )
{
+case X86_VENDOR_CENTAUR:
+case X86_VENDOR_SHANGHAI:
case X86_VENDOR_INTEL:
ret = vmce_intel_rdmsr(v, msr, val);
break;
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 3e038db618..31964b88af 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -15,6 +15,9 @@
* abbreviated name. Exceptions will be considered on a case-by-case basis.
*/
+#define MSR_P5_MC_ADDR 0
+#define MSR_P5_MC_TYPE 0x0001
+
#define MSR_APIC_BASE 0x001b
#define APIC_BASE_BSP (_AC(1, ULL) << 8)
#define APIC_BASE_EXTD (_AC(1, ULL) << 10)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index a1e268eea9..d87317e989 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -283,6 +283,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
*val = msrs->misc_features_enables.raw;
break;
+case MSR_P5_MC_ADDR:
+case MSR_P5_MC_TYPE:
case MSR_IA32_MCG_CAP ... MSR_IA32_MCG_CTL: /* 0x179 -> 0x17b */
case MSR_IA32_MCx_CTL2(0) ... MSR_IA32_MCx_CTL2(31): /* 0x280 -> 0x29f */
case MSR_IA32_MCx_CTL(0) ... MSR_IA32_MCx_MISC(31): /* 0x400 -> 0x47f */
--
2.35.1
Re: [xen-unstable-smoke test] 169781: regressions - FAIL
Hi Stefano, On 28/04/2022 01:47, Stefano Stabellini wrote: On Thu, 28 Apr 2022, Julien Grall wrote: Hi Stefano, On Thu, 28 Apr 2022, 00:02 Stefano Stabellini, wrote It seems to me that it is acceptable to allocate memory with interrupt disabled during __init. I cannot see any drawbacks with it. I think we should change the ASSERT to only trigger after __init: system_state == SYS_STATE_active. What do you think? This would solve the immediate problem but not the long term one (i.e cpu hotplug). So I think it would be better to properly fix it right away. Yeah, you are right about cpu hotplug. I think both statements are true: - it is true that this is supposed to work with cpu hotplug and these functions might be directly affected by cpu hotplug (by a CPU coming online later on) - it is also true that it might not make sense to ASSERT at __init time if IRQs are disabled. There might be other places, not affected by cpu hotplug, where we do memory allocation at __init time with IRQ disabled. It might still be a good idea to add the system_state == SYS_STATE_active check in the ASSERT, not to solve this specific problem but to avoid other issues. AFAIU, it is not safe on x86 to do TLB flush with interrupts disabled *and* multiple CPUs running. So we can't generically relax the check. Looking at the OSSTest results, both Arm32 and Arm64 without GICv3 ITS tests have passed. So it seems unnecessary to me to preemptively relax the check just for Arm. In regard to gicv3_lpi_allocate_pendtable, I haven't thought about the implications of cpu hotplug for LPIs and GICv3 before. Do you envision that in a CPU hotplug scenario gicv3_lpi_init_rdist would be called when the extra CPU comes online? It is already called per-CPU. See gicv3_secondary_cpu_init() -> gicv3_cpu_init() -> gicv3_populate_rdist(). Today gicv3_lpi_init_rdist is called based on the number of rdist_regions without checking if the CPU is online or offline (I think ?) The re-distributors are not banked and therefore accessible by everyone. However, in Xen case, each pCPU will only touch its own re-distributor (well aside TYPER to figure out the ID). The loop in gicv3_populate_rdist() will walk throught all the re-distributor to find which one corresponds to the current pCPU. Once we found it, we will call gicv3_lpi_init_rdist() to fully initialize the re-distributor. I don't think we want to populate the memory for each re-distributor in advance. Cheers, -- Julien Grall
[ovmf test] 169810: regressions - FAIL
flight 169810 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 59 days Failing since168258 2022-03-01 01:55:31 Z 58 days 675 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 47 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
Re: [PATCH v2] x86/msr: handle reads to MSR_P5_MC_{ADDR,TYPE}
On Thu, Apr 28, 2022 at 12:39:19PM +0200, Jan Beulich wrote:
> On 28.04.2022 11:13, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> > @@ -1008,8 +1008,24 @@ int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr,
> > uint64_t val)
> >
> > int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> > {
> > +const struct cpuid_policy *cp = v->domain->arch.cpuid;
> > unsigned int bank = msr - MSR_IA32_MC0_CTL2;
> >
> > +switch ( msr )
> > +{
> > +case MSR_P5_MC_ADDR:
> > +/* Bank 0 is used for the 'bank 0 quirk' on older processors. */
> > +*val = v->arch.vmce.bank[1].mci_addr;
> > +return 1;
> > +
> > +case MSR_P5_MC_TYPE:
> > +*val = v->arch.vmce.bank[1].mci_status;
> > +return 1;
> > +}
>
> Could I ask you to add a reference to vcpu_fill_mc_msrs() in the comment?
Sure.
Thanks, Roger.
Re: [PATCH v2] x86/msr: handle reads to MSR_P5_MC_{ADDR,TYPE}
On 28.04.2022 11:13, Roger Pau Monne wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -169,6 +169,11 @@ static inline int mce_vendor_bank_msr(const struct vcpu
> *v, uint32_t msr)
> if (msr >= MSR_IA32_MC0_CTL2 &&
> msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) )
> return 1;
> +
> +case X86_VENDOR_CENTAUR:
> +case X86_VENDOR_SHANGHAI:
> +if (msr == MSR_P5_MC_ADDR || msr == MSR_P5_MC_TYPE)
> +return 1;
> break;
You want to have some fall-through annotation there, perhaps preferably
the pseudo-keyword one.
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -1008,8 +1008,24 @@ int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr,
> uint64_t val)
>
> int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> {
> +const struct cpuid_policy *cp = v->domain->arch.cpuid;
> unsigned int bank = msr - MSR_IA32_MC0_CTL2;
>
> +switch ( msr )
> +{
> +case MSR_P5_MC_ADDR:
> +/* Bank 0 is used for the 'bank 0 quirk' on older processors. */
> +*val = v->arch.vmce.bank[1].mci_addr;
> +return 1;
> +
> +case MSR_P5_MC_TYPE:
> +*val = v->arch.vmce.bank[1].mci_status;
> +return 1;
> +}
Could I ask you to add a reference to vcpu_fill_mc_msrs() in the comment?
> +if ( cp->x86_vendor & (X86_VENDOR_CENTAUR | X86_VENDOR_SHANGHAI) )
> +return 0;
I think this better would be !(cp->x86_vendor & X86_VENDOR_INTEL).
Jan
[PATCH v2] xen/arm: p2m don't fall over on FEAT_LPA enabled hw
When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying across the max supported range.
Unsurprisingly when the page tables aren't set up for these greater
ranges hilarity ensues and the hypervisor crashes fairly early on in
the boot-up sequence. This happens when we write to the control
register in enable_mmu().
Attempt to fix this the same way as the Linux kernel does by gating
PARange to the maximum the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.
Signed-off-by: Alex Bennée
Cc: Richard Henderson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Volodymyr Babchuk
Cc: Bertrand Marquis
---
v2
- clamp p2m_ipa_bits = PADDR_BIT instead
---
xen/arch/arm/arm64/head.S | 6 ++
xen/arch/arm/p2m.c| 10 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index aa1f88c764..057dd5d925 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -473,6 +473,12 @@ cpu_init:
ldr x0,
=(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48))
/* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] (PS)
*/
mrs x1, ID_AA64MMFR0_EL1
+/* Limit to 48 bits, 256TB PA range (#5) */
+ubfm x1, x1, #0, #3
+mov x2, #5
+cmp x1, x2
+csel x1, x1, x2, lt
+
bfi x0, x1, #16, #3
msr tcr_el2, x0
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fb71fa4c1c..3349b464a3 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -32,10 +32,10 @@ static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
#define P2M_ROOT_PAGES(1<= ARRAY_SIZE(pa_range_info) ||
!pa_range_info[pa_range].pabits )
panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);
--
2.30.2
Re: [PATCH] x86/cet: Support cet= on the command line
On 28.04.2022 10:52, Andrew Cooper wrote:
> @@ -283,6 +283,8 @@ CET is incompatible with 32bit PV guests. If any CET
> sub-options are active,
> they will override the `pv=32` boolean to `false`. Backwards compatibility
> can be maintained with the pv-shim mechanism.
>
> +* An unqualified boolean is shorthand for setting all suboptions at once.
You're the native speaker, but I wonder whether there an "a" missing
before "shorthand".
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -117,7 +117,20 @@ static int __init cf_check parse_cet(const char *s)
> if ( !ss )
> ss = strchr(s, '\0');
>
> -if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
> +if ( (val = parse_bool(s, ss)) >= 0 )
> +{
> +#ifdef CONFIG_XEN_SHSTK
> +opt_xen_shstk = val;
> +#else
> +no_config_param("XEN_SHSTK", "cet", s, ss);
> +#endif
> +#ifdef CONFIG_XEN_IBT
> +opt_xen_ibt = val;
> +#else
> +no_config_param("XEN_IBT", "cet", s, ss);
> +#endif
There shouldn't be two invocations of no_config_param() here; imo if
either CONFIG_* is defined, use of the option shouldn't produce any
warning at all.
> +}
> +else if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
> {
> #ifdef CONFIG_XEN_SHSTK
> opt_xen_shstk = val;
Having seen Roger's reply, I'd like to make explicit that I don't
mind us allowing strange option combinations to be used, so long as
what we do matches the sequence in which they were provided.
Jan
Re: [PATCH v2] xen/arm: gnttab: cast unused macro arguments to void
On 28.04.2022 11:46, Michal Orzel wrote: > @@ -89,10 +90,12 @@ int replace_grant_host_mapping(unsigned long gpaddr, > mfn_t mfn, > }) > > #define gnttab_shared_gfn(d, t, i) \ > -(((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i]) > +((void)(d), \ > + ((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i]) > > -#define gnttab_status_gfn(d, t, i) \ > -(((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i]) > +#define gnttab_status_gfn(d, t, i)\ > +((void)(d), \ > + ((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i]) Just as a note (I don't mind changing these too): If a macro cares to evaluate all its arguments, I think it should also care to evaluate all of them exactly once. Jan
Re: [PATCH] arm/its: enable LPIs before mapping the collection table
Hi Julien,
> On 27 Apr 2022, at 6:59 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 27/04/2022 17:14, Rahul Singh wrote:
>> MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
>
> Looking at the spec (ARM IHI 0069H), I can't find a command error named
> MAPC_LPI_OFF. Is it something specific to your HW?
I found the issue on HW that implements GIC-600 and GIC-600 TRM specify the
MAPC_LPI_OFF its command error.
https://developer.arm.com/documentation/100336/0106/introduction/about-the-gic-600
{Table 3-15 ITS command and translation errors, records 13+ page 3-89}
>
>> not enabled before mapping the collection table using MAPC command.
>> Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
>> table.
>> Signed-off-by: Rahul Singh
>> ---
>> xen/arch/arm/gic-v3.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 3c472ed768..8fb0014b16 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -812,11 +812,11 @@ static int gicv3_cpu_init(void)
>> /* If the host has any ITSes, enable LPIs now. */
>> if ( gicv3_its_host_has_its() )
>> {
>> + if ( !gicv3_enable_lpis() )
>> + return -EBUSY;
>> ret = gicv3_its_setup_collection(smp_processor_id());
>> if ( ret )
>> return ret;
>> - if ( !gicv3_enable_lpis() )
>> - return -EBUSY;
>
> AFAICT, Linux is using the same ordering as your are proposing. It seems to
> have been introduced from the start, so it is not clear why we chose this
> approach.
Yes I also confirmed that before sending the patch for review. I think this is
okay if we enable the enable LPIs before mapping the collection table.
>
> However, given this works on some HW, can you clarify whether this is
> mandated by the spec or this is a bug in your HW?
Regards,
Rahul
[PATCH] cirrus-ci: add myself as maintainer
Given the testing done by Cirrus-CI is FreeBSD only introduce a new section in the MAINTAINERS file to cover it and add myself as the maintainer. Requested-by: Stefano Stabellini Signed-off-by: Roger Pau Monné --- FWIW, I wouldn't mind it being part of the "Continuous Integration (CI)" section, but I understand maintainers there could prefer a separate section since this is ATM FreeBSD only testing. --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2a47fafe85..6248d07aea 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -260,6 +260,11 @@ R: Community Manager S: Maintained F: CHANGELOG.md +Cirrus-CI Integration +M: Roger Pau Monné +S: Supported +F: .cirrus.yml + Continuous Integration (CI) M: Doug Goldstein M: Stefano Stabellini -- 2.35.1
Re: [PATCH] cirrus-ci: add FreeBSD 14 task
On Wed, Apr 27, 2022 at 03:13:13PM -0700, Stefano Stabellini wrote: > On Wed, 27 Apr 2022, Roger Pau Monne wrote: > > Introduce a task that uses a FreeBSD 14 (HEAD) snapshot. > > > > Signed-off-by: Roger Pau Monné > > Acked-by: Stefano Stabellini > > > Roger, should you add an entry to MAINTAINERS to set yourself as > maintainer of .cirrus.yml ? It would seem a natural fit to place it in the "Continuous Integration (CI)" section, but then it being FreeBSD only (at least ATM) I assume current maintainers won't feel comfortable having it there. Thanks, Roger.
[ovmf test] 169808: regressions - FAIL
flight 169808 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169808/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 58 days Failing since168258 2022-03-01 01:55:31 Z 58 days 674 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 46 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
[PATCH v2] xen/arm: gnttab: cast unused macro arguments to void
Function unmap_common_complete (common/grant_table.c) defines and sets a variable ld that is later on passed to a macro: gnttab_host_mapping_get_page_type(). On Arm this macro does not make use of any arguments causing a compiler to warn about unused-but-set variable (when -Wunused-but-set-variable is enabled). Fix it by casting the arguments to void in macro's body. While there, take the opportunity to modify other macros in this file that do not make use of all the arguments to prevent similar issues in the future. Signed-off-by: Michal Orzel --- Changes since v1: -standalone patch carved out from a series (other patches already merged) -v1 was ([3/8] gnttab: Remove unused-but-set variable) -modify macro on Arm instead of removing ld variable --- xen/arch/arm/include/asm/grant_table.h | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h index d31a4d6805..5bcd1ec528 100644 --- a/xen/arch/arm/include/asm/grant_table.h +++ b/xen/arch/arm/include/asm/grant_table.h @@ -31,10 +31,11 @@ static inline void gnttab_mark_dirty(struct domain *d, mfn_t mfn) int create_grant_host_mapping(unsigned long gpaddr, mfn_t mfn, unsigned int flags, unsigned int cache_flags); -#define gnttab_host_mapping_get_page_type(ro, ld, rd) (0) +#define gnttab_host_mapping_get_page_type(ro, ld, rd) \ +((void)(ro), (void)(ld), (void)(rd), 0) int replace_grant_host_mapping(unsigned long gpaddr, mfn_t mfn, unsigned long new_gpaddr, unsigned int flags); -#define gnttab_release_host_mappings(domain) 1 +#define gnttab_release_host_mappings(domain) ((void)(domain), 1) /* * The region used by Xen on the memory will never be mapped in DOM0 @@ -89,10 +90,12 @@ int replace_grant_host_mapping(unsigned long gpaddr, mfn_t mfn, }) #define gnttab_shared_gfn(d, t, i) \ -(((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i]) +((void)(d), \ + ((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i]) -#define gnttab_status_gfn(d, t, i) \ -(((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i]) +#define gnttab_status_gfn(d, t, i)\ +((void)(d), \ + ((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i]) #define gnttab_need_iommu_mapping(d)\ (is_domain_direct_mapped(d) && is_iommu_enabled(d)) -- 2.25.1
Re: [PATCH v3] codeql: add support for analyzing C, Python and Go
Ping?
On Wed, Mar 23, 2022 at 11:18:56AM +0100, Roger Pau Monne wrote:
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
>
> Note than when analyzing Python or Go we avoid building the hypervisor
> and only build the tools.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> Changes since v2:
> - Remove explicit 'staging' branch checkout.
> - Remove explicit query.
> - Remove ignored paths.
> - Remove 'on schedule' trigger, or else it would be run against the
>master branch instead of staging.
>
> Changes since v1:
> - Rename to note it's x86 specific right now.
> - Merge the ignored path patch.
> ---
> .github/workflows/codeql-x86.yml | 54
> 1 file changed, 54 insertions(+)
> create mode 100644 .github/workflows/codeql-x86.yml
>
> diff --git a/.github/workflows/codeql-x86.yml
> b/.github/workflows/codeql-x86.yml
> new file mode 100644
> index 00..6ddd445c79
> --- /dev/null
> +++ b/.github/workflows/codeql-x86.yml
> @@ -0,0 +1,54 @@
> +name: CodeQL x86
> +
> +on:
> + workflow_dispatch:
> + push:
> +branches: [staging]
> +
> +jobs:
> + analyse:
> +
> +strategy:
> + matrix:
> +language: [ 'cpp', 'python', 'go' ]
> +
> +runs-on: ubuntu-latest
> +
> +steps:
> +- name: Install build dependencies
> + run: |
> +sudo apt-get install -y wget git \
> + libbz2-dev build-essential \
> + zlib1g-dev libncurses5-dev iasl \
> + libbz2-dev e2fslibs-dev uuid-dev libyajl-dev \
> + autoconf libtool liblzma-dev \
> + python3-dev golang python-dev libsystemd-dev
> +
> +- uses: actions/checkout@v2
> +
> +- name: Configure Xen
> + run: |
> +./configure --with-system-qemu=/bin/true \
> +--with-system-seabios=/bin/true \
> +--with-system-ovmf=/bin/true
> +
> +- name: Pre build stuff
> + run: |
> +make -j`nproc` mini-os-dir
> +
> +- uses: github/codeql-action/init@v1
> + with:
> +languages: ${{matrix.language}}
> +
> +- if: matrix.language == 'cpp'
> + name: Full Build
> + run: |
> +make -j`nproc` build-xen build-tools
> +make -j`nproc` -C extras/mini-os/
> +
> +- if: matrix.language == 'python' || matrix.language == 'go'
> + name: Tools Build
> + run: |
> +make -j`nproc` build-tools
> +
> +- uses: github/codeql-action/analyze@v1
> --
> 2.35.1
>
[linux-linus test] 169792: tolerable FAIL - PUSHED
flight 169792 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/169792/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169767 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169767 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169767 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169767 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169767 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169767 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169767 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169767 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linuxe4d8a29997731b3bb14059024b24df9f784288d0 baseline version: linux46cf2c613f4b10eb12f749207b0fd2c1bfae3088 Last test of basis 169767 2022-04-27 04:01:30 Z1 days Testing same since 169792 2022-04-27 19:09:50 Z0 days1 attempts People who touched revisions under test: Chuanhong Guo Damien Le Moal Denis Efremov Linus Torvalds Md Sadre Alam Miaoqian Lin Mikulas Patocka Miquel Raynal Oleksandr Ocheretnyi Sricharan R Willy Tarreau jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [PATCH] x86/cet: Support cet= on the command line
On Thu, Apr 28, 2022 at 09:52:09AM +0100, Andrew Cooper wrote: > ... as a shorthand for setting both suboptions at once. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné >From the implementation below we would support settings like: cet=true,shstk=false Which I think it's indented? Have a global default for all options, set some to a different value. Thanks, Roger.
[PATCH v2] x86/msr: handle reads to MSR_P5_MC_{ADDR,TYPE}
Windows Server 2019 Essentials will unconditionally attempt to read
P5_MC_ADDR MSR at boot and throw a BSOD if injected a #GP.
Fix this by mapping MSR_P5_MC_{ADDR,TYPE} to
MSR_IA32_MCi_{ADDR,STATUS}, as reported also done by hardware in Intel
SDM "Mapping of the Pentium Processor Machine-Check Errors to the
Machine-Check Architecture" section.
Reported-by: Steffen Einsle
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Implement in vmce_rdmsr.
---
xen/arch/x86/cpu/mcheck/mce.h| 5 +
xen/arch/x86/cpu/mcheck/mce_intel.c | 16
xen/arch/x86/cpu/mcheck/vmce.c | 2 ++
xen/arch/x86/include/asm/msr-index.h | 3 +++
xen/arch/x86/msr.c | 2 ++
5 files changed, 28 insertions(+)
diff --git a/xen/arch/x86/cpu/mcheck/mce.h b/xen/arch/x86/cpu/mcheck/mce.h
index 535d0abf8f..7c6df6df7c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -169,6 +169,11 @@ static inline int mce_vendor_bank_msr(const struct vcpu
*v, uint32_t msr)
if (msr >= MSR_IA32_MC0_CTL2 &&
msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) )
return 1;
+
+case X86_VENDOR_CENTAUR:
+case X86_VENDOR_SHANGHAI:
+if (msr == MSR_P5_MC_ADDR || msr == MSR_P5_MC_TYPE)
+return 1;
break;
case X86_VENDOR_AMD:
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c
b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 50198e0c29..63fedff418 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1008,8 +1008,24 @@ int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr,
uint64_t val)
int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
{
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
unsigned int bank = msr - MSR_IA32_MC0_CTL2;
+switch ( msr )
+{
+case MSR_P5_MC_ADDR:
+/* Bank 0 is used for the 'bank 0 quirk' on older processors. */
+*val = v->arch.vmce.bank[1].mci_addr;
+return 1;
+
+case MSR_P5_MC_TYPE:
+*val = v->arch.vmce.bank[1].mci_status;
+return 1;
+}
+
+if ( cp->x86_vendor & (X86_VENDOR_CENTAUR | X86_VENDOR_SHANGHAI) )
+return 0;
+
if ( bank < GUEST_MC_BANK_NUM )
{
*val = v->arch.vmce.bank[bank].mci_ctl2;
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 458120f9ad..af30811afd 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -150,6 +150,8 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t
msr, uint64_t *val)
default:
switch ( boot_cpu_data.x86_vendor )
{
+case X86_VENDOR_CENTAUR:
+case X86_VENDOR_SHANGHAI:
case X86_VENDOR_INTEL:
ret = vmce_intel_rdmsr(v, msr, val);
break;
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 3e038db618..31964b88af 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -15,6 +15,9 @@
* abbreviated name. Exceptions will be considered on a case-by-case basis.
*/
+#define MSR_P5_MC_ADDR 0
+#define MSR_P5_MC_TYPE 0x0001
+
#define MSR_APIC_BASE 0x001b
#define APIC_BASE_BSP (_AC(1, ULL) << 8)
#define APIC_BASE_EXTD (_AC(1, ULL) << 10)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index a1e268eea9..d87317e989 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -283,6 +283,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
*val = msrs->misc_features_enables.raw;
break;
+case MSR_P5_MC_ADDR:
+case MSR_P5_MC_TYPE:
case MSR_IA32_MCG_CAP ... MSR_IA32_MCG_CTL: /* 0x179 -> 0x17b */
case MSR_IA32_MCx_CTL2(0) ... MSR_IA32_MCx_CTL2(31): /* 0x280 -> 0x29f */
case MSR_IA32_MCx_CTL(0) ... MSR_IA32_MCx_MISC(31): /* 0x400 -> 0x47f */
--
2.35.1
Re: [PATCH v2 1/2] PCI: replace stray uses of PCI_{DEVFN,BDF}2()
Hi Jan, > On 21 Apr 2022, at 15:26, Jan Beulich wrote: > > There's no good reason to use these when we already have a pci_sbdf_t > type object available. This extends to the use of PCI_BUS() in > pci_ecam_map_bus() as well. > > No change to generated code (with gcc11 at least, and I have to admit > that I didn't expect compilers to necessarily be able to spot the > optimization potential on the original code). > > Signed-off-by: Jan Beulich > Reviewed-by: Roger Pau Monné > Reviewed-by: Kevin Tian Reviewed-by: Bertrand Marquis Sorry I missed it. Cheers Bertrand > --- > Note that the Arm changes are "blind": I haven't been able to spot a way > to at least compile test the changes there; the code looks to be > entirely dead. > --- > v2: Arm build fix (for those who actually have ways to build the Arm >code being changed here). > > --- a/xen/arch/arm/pci/ecam.c > +++ b/xen/arch/arm/pci/ecam.c > @@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc > container_of(bridge->ops, const struct pci_ecam_ops, pci_ops); > unsigned int devfn_shift = ops->bus_shift - 8; > void __iomem *base; > - > -unsigned int busn = PCI_BUS(sbdf.bdf); > +unsigned int busn = sbdf.bus; > > if ( busn < cfg->busn_start || busn > cfg->busn_end ) > return NULL; > @@ -37,7 +36,7 @@ void __iomem *pci_ecam_map_bus(struct pc > busn -= cfg->busn_start; > base = cfg->win + (busn << ops->bus_shift); > > -return base + (PCI_DEVFN2(sbdf.bdf) << devfn_shift) + where; > +return base + (sbdf.devfn << devfn_shift) + where; > } > > bool __init pci_ecam_need_p2m_hwdom_mapping(struct domain *d, > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -839,7 +839,7 @@ static int msix_capability_init(struct p > pbus = dev->info.physfn.bus; > pslot = PCI_SLOT(dev->info.physfn.devfn); > pfunc = PCI_FUNC(dev->info.physfn.devfn); > -vf = PCI_BDF2(dev->bus, dev->devfn); > +vf = dev->sbdf.bdf; > } > > table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf); > --- a/xen/drivers/passthrough/vtd/qinval.c > +++ b/xen/drivers/passthrough/vtd/qinval.c > @@ -267,7 +267,7 @@ int qinval_device_iotlb_sync(struct vtd_ > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_1 = 0; > qinval_entry->q.dev_iotlb_inv_dsc.lo.max_invs_pend = > pdev->ats.queue_depth; > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_2 = 0; > -qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = PCI_BDF2(pdev->bus, > pdev->devfn); > +qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = pdev->sbdf.bdf; > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_3 = 0; > > qinval_entry->q.dev_iotlb_inv_dsc.hi.size = size; >
[PATCH] x86/cet: Support cet= on the command line
... as a shorthand for setting both suboptions at once.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
I think this wants backporting. cet=0 is "so obviously" the way to turn off
both that I tried using it to debug a problem. It's absence was an oversight
of the original CET logic.
---
docs/misc/xen-command-line.pandoc | 4 +++-
xen/arch/x86/setup.c | 15 ++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 1dc7e1ca0706..1720cb216824 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -271,7 +271,7 @@ enough. Setting this to a high value may cause boot
failure, particularly if
the NMI watchdog is also enabled.
### cet
-= List of [ shstk=, ibt= ]
+= List of [ , shstk=, ibt= ]
Applicability: x86
@@ -283,6 +283,8 @@ CET is incompatible with 32bit PV guests. If any CET
sub-options are active,
they will override the `pv=32` boolean to `false`. Backwards compatibility
can be maintained with the pv-shim mechanism.
+* An unqualified boolean is shorthand for setting all suboptions at once.
+
* The `shstk=` boolean controls whether Xen uses Shadow Stacks for its own
protection.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 53a73010e029..090abfd71754 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -117,7 +117,20 @@ static int __init cf_check parse_cet(const char *s)
if ( !ss )
ss = strchr(s, '\0');
-if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
+if ( (val = parse_bool(s, ss)) >= 0 )
+{
+#ifdef CONFIG_XEN_SHSTK
+opt_xen_shstk = val;
+#else
+no_config_param("XEN_SHSTK", "cet", s, ss);
+#endif
+#ifdef CONFIG_XEN_IBT
+opt_xen_ibt = val;
+#else
+no_config_param("XEN_IBT", "cet", s, ss);
+#endif
+}
+else if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
{
#ifdef CONFIG_XEN_SHSTK
opt_xen_shstk = val;
--
2.11.0
Re: [xen-unstable-smoke test] 169781: regressions - FAIL
Hi Jan, On 28/04/2022 08:45, Jan Beulich wrote: On 27.04.2022 19:10, Julien Grall wrote: Hi, On 27/04/2022 17:38, osstest service owner wrote: flight 169781 xen-unstable-smoke real [real] flight 169785 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169781/ http://logs.test-lab.xenproject.org/osstest/logs/169785/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169773 Well, I was overly optimistic :(. This now breaks in the ITS code: Apr 27 13:23:14.324831 (XEN) Xen call trace: Apr 27 13:23:14.324855 (XEN)[<0022a678>] alloc_xenheap_pages+0x178/0x194 (PC) Apr 27 13:23:14.336856 (XEN)[<0022a670>] alloc_xenheap_pages+0x170/0x194 (LR) Apr 27 13:23:14.336886 (XEN)[<00237770>] _xmalloc+0x144/0x294 Apr 27 13:23:14.348773 (XEN)[<002378d4>] _xzalloc+0x14/0x30 Apr 27 13:23:14.348808 (XEN)[<0027b4e4>] gicv3_lpi_init_rdist+0x54/0x324 Apr 27 13:23:14.348835 (XEN)[<00279898>] arch/arm/gic-v3.c#gicv3_cpu_init+0x128/0x46c Apr 27 13:23:14.360799 (XEN)[<00279bfc>] arch/arm/gic-v3.c#gicv3_secondary_cpu_init+0x20/0x50 Apr 27 13:23:14.372796 (XEN)[<00277054>] gic_init_secondary_cpu+0x18/0x30 Apr 27 13:23:14.372829 (XEN)[<00284518>] start_secondary+0x1a8/0x234 Apr 27 13:23:14.372856 (XEN)[<010722aa4200>] 010722aa4200 Apr 27 13:23:14.384793 (XEN) Apr 27 13:23:14.384823 (XEN) Apr 27 13:23:14.384845 (XEN) Apr 27 13:23:14.384869 (XEN) Panic on CPU 2: Apr 27 13:23:14.384891 (XEN) Assertion '!in_irq() && (local_irq_is_enabled() || num_online_cpus() <= 1)' failed at common/page_alloc.c:2212 Apr 27 13:23:14.396805 (XEN) The GICv3 LPI code contains a few calls to xmalloc() that will be done while initializing the GIC CPU interface. I don't think we can delay the initialization of the LPI part past local_irq_enable(). So I think we will need to allocate the memory when preparing the CPU. Do you have an explanation why the next flight (169800) passed? The flight 169800 ran on laxtonX (Softiron) which doesn't have a GICv3 ITS. I thought OSSTest would try to run the next flight on the same HW to check heisenbug, but maybe this doesn't happen for the smoke test? Cheers, -- Julien Grall
[ovmf test] 169806: regressions - FAIL
flight 169806 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169806/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-amd64 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 916f90baa547b3ebef8fa87c530e2f0c8e35e1e3 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 58 days Failing since168258 2022-03-01 01:55:31 Z 58 days 673 attempts Testing same since 169718 2022-04-25 21:41:52 Z2 days 45 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5828 lines long.)
[PATCH v2 18/19] xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify sndfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
sound/xen/xen_snd_front_evtchnl.c | 44 +++
1 file changed, 10 insertions(+), 34 deletions(-)
diff --git a/sound/xen/xen_snd_front_evtchnl.c
b/sound/xen/xen_snd_front_evtchnl.c
index 3e21369c8216..26d1b3987887 100644
--- a/sound/xen/xen_snd_front_evtchnl.c
+++ b/sound/xen/xen_snd_front_evtchnl.c
@@ -143,12 +143,12 @@ void xen_snd_front_evtchnl_flush(struct
xen_snd_front_evtchnl *channel)
static void evtchnl_free(struct xen_snd_front_info *front_info,
struct xen_snd_front_evtchnl *channel)
{
- unsigned long page = 0;
+ void *page = NULL;
if (channel->type == EVTCHNL_TYPE_REQ)
- page = (unsigned long)channel->u.req.ring.sring;
+ page = channel->u.req.ring.sring;
else if (channel->type == EVTCHNL_TYPE_EVT)
- page = (unsigned long)channel->u.evt.page;
+ page = channel->u.evt.page;
if (!page)
return;
@@ -167,10 +167,7 @@ static void evtchnl_free(struct xen_snd_front_info
*front_info,
xenbus_free_evtchn(front_info->xb_dev, channel->port);
/* End access and free the page. */
- if (channel->gref != INVALID_GRANT_REF)
- gnttab_end_foreign_access(channel->gref, page);
- else
- free_page(page);
+ xenbus_teardown_ring(, 1, >gref);
memset(channel, 0, sizeof(*channel));
}
@@ -196,8 +193,7 @@ static int evtchnl_alloc(struct xen_snd_front_info
*front_info, int index,
enum xen_snd_front_evtchnl_type type)
{
struct xenbus_device *xb_dev = front_info->xb_dev;
- unsigned long page;
- grant_ref_t gref;
+ void *page;
irq_handler_t handler;
char *handler_name = NULL;
int ret;
@@ -207,12 +203,9 @@ static int evtchnl_alloc(struct xen_snd_front_info
*front_info, int index,
channel->index = index;
channel->front_info = front_info;
channel->state = EVTCHNL_STATE_DISCONNECTED;
- channel->gref = INVALID_GRANT_REF;
- page = get_zeroed_page(GFP_KERNEL);
- if (!page) {
- ret = -ENOMEM;
+ ret = xenbus_setup_ring(xb_dev, GFP_KERNEL, , 1, >gref);
+ if (ret)
goto fail;
- }
handler_name = kasprintf(GFP_KERNEL, "%s-%s", XENSND_DRIVER_NAME,
type == EVTCHNL_TYPE_REQ ?
@@ -226,33 +219,18 @@ static int evtchnl_alloc(struct xen_snd_front_info
*front_info, int index,
mutex_init(>ring_io_lock);
if (type == EVTCHNL_TYPE_REQ) {
- struct xen_sndif_sring *sring = (struct xen_sndif_sring *)page;
+ struct xen_sndif_sring *sring = page;
init_completion(>u.req.completion);
mutex_init(>u.req.req_io_lock);
- SHARED_RING_INIT(sring);
- FRONT_RING_INIT(>u.req.ring, sring, XEN_PAGE_SIZE);
-
- ret = xenbus_grant_ring(xb_dev, sring, 1, );
- if (ret < 0) {
- channel->u.req.ring.sring = NULL;
- goto fail;
- }
+ XEN_FRONT_RING_INIT(>u.req.ring, sring, XEN_PAGE_SIZE);
handler = evtchnl_interrupt_req;
} else {
- ret = gnttab_grant_foreign_access(xb_dev->otherend_id,
- virt_to_gfn((void *)page), 0);
- if (ret < 0)
- goto fail;
-
- channel->u.evt.page = (struct xensnd_event_page *)page;
- gref = ret;
+ channel->u.evt.page = page;
handler = evtchnl_interrupt_evt;
}
- channel->gref = gref;
-
ret = xenbus_alloc_evtchn(xb_dev, >port);
if (ret < 0)
goto fail;
@@ -279,8 +257,6 @@ static int evtchnl_alloc(struct xen_snd_front_info
*front_info, int index,
return 0;
fail:
- if (page)
- free_page(page);
kfree(handler_name);
dev_err(_dev->dev, "Failed to allocate ring: %d\n", ret);
return ret;
--
2.34.1
[PATCH v2 19/19] xen/xenbus: eliminate xenbus_grant_ring()
There is no external user of xenbus_grant_ring() left, so merge it into
the only caller xenbus_setup_ring().
Signed-off-by: Juergen Gross
---
V2:
- make error message more precise (Andrew Cooper)
---
drivers/xen/xenbus/xenbus_client.c | 65 +-
include/xen/xenbus.h | 2 -
2 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 1a2e0d94ccd1..d6fdd2d209d3 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -363,50 +363,6 @@ static void xenbus_switch_fatal(struct xenbus_device *dev,
int depth, int err,
__xenbus_switch_state(dev, XenbusStateClosing, 1);
}
-/**
- * xenbus_grant_ring
- * @dev: xenbus device
- * @vaddr: starting virtual address of the ring
- * @nr_pages: number of pages to be granted
- * @grefs: grant reference array to be filled in
- *
- * Grant access to the given @vaddr to the peer of the given device.
- * Then fill in @grefs with grant references. Return 0 on success, or
- * -errno on error. On error, the device will switch to
- * XenbusStateClosing, and the error will be saved in the store.
- */
-int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
- unsigned int nr_pages, grant_ref_t *grefs)
-{
- int err;
- unsigned int i;
- grant_ref_t gref_head;
-
- err = gnttab_alloc_grant_references(nr_pages, _head);
- if (err) {
- xenbus_dev_fatal(dev, err, "granting access to ring page");
- return err;
- }
-
- for (i = 0; i < nr_pages; i++) {
- unsigned long gfn;
-
- if (is_vmalloc_addr(vaddr))
- gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
- else
- gfn = virt_to_gfn(vaddr);
-
- grefs[i] = gnttab_claim_grant_reference(_head);
- gnttab_grant_foreign_access_ref(grefs[i], dev->otherend_id,
- gfn, 0);
-
- vaddr = vaddr + XEN_PAGE_SIZE;
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(xenbus_grant_ring);
-
/*
* xenbus_setup_ring
* @dev: xenbus device
@@ -424,6 +380,7 @@ int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp,
void **vaddr,
unsigned int nr_pages, grant_ref_t *grefs)
{
unsigned long ring_size = nr_pages * XEN_PAGE_SIZE;
+ grant_ref_t gref_head;
unsigned int i;
int ret;
@@ -433,9 +390,25 @@ int xenbus_setup_ring(struct xenbus_device *dev, gfp_t
gfp, void **vaddr,
goto err;
}
- ret = xenbus_grant_ring(dev, *vaddr, nr_pages, grefs);
- if (ret)
+ ret = gnttab_alloc_grant_references(nr_pages, _head);
+ if (ret) {
+ xenbus_dev_fatal(dev, ret, "granting access to %u ring pages",
+nr_pages);
goto err;
+ }
+
+ for (i = 0; i < nr_pages; i++) {
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(*vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr[i]));
+ else
+ gfn = virt_to_gfn(vaddr[i]);
+
+ grefs[i] = gnttab_claim_grant_reference(_head);
+ gnttab_grant_foreign_access_ref(grefs[i], dev->otherend_id,
+ gfn, 0);
+ }
return 0;
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index b533b4adc835..eaa932b99d8a 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -224,8 +224,6 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct
xenbus_watch *watch,
const char *pathfmt, ...);
int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state
new_state);
-int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
- unsigned int nr_pages, grant_ref_t *grefs);
int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, void **vaddr,
unsigned int nr_pages, grant_ref_t *grefs);
void xenbus_teardown_ring(void **vaddr, unsigned int nr_pages,
--
2.34.1
[PATCH v2 05/19] xen/drm: switch xen_drm_front to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/gpu/drm/xen/xen_drm_front.h | 9 -
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index cefafe859aba..a987c78abe41 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -80,15 +80,6 @@ struct drm_pending_vblank_event;
/* timeout in ms to wait for backend to respond */
#define XEN_DRM_FRONT_WAIT_BACK_MS 3000
-#ifndef GRANT_INVALID_REF
-/*
- * Note on usage of grant reference 0 as invalid grant reference:
- * grant reference 0 is valid, but never exposed to a PV driver,
- * because of the fact it is already in use/reserved by the PV console.
- */
-#define GRANT_INVALID_REF 0
-#endif
-
struct xen_drm_front_info {
struct xenbus_device *xb_dev;
struct xen_drm_front_drm_info *drm_info;
diff --git a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
index 08b526eeec16..4006568b9e32 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
@@ -147,7 +147,7 @@ static void evtchnl_free(struct xen_drm_front_info
*front_info,
xenbus_free_evtchn(front_info->xb_dev, evtchnl->port);
/* end access and free the page */
- if (evtchnl->gref != GRANT_INVALID_REF)
+ if (evtchnl->gref != INVALID_GRANT_REF)
gnttab_end_foreign_access(evtchnl->gref, page);
memset(evtchnl, 0, sizeof(*evtchnl));
@@ -168,7 +168,7 @@ static int evtchnl_alloc(struct xen_drm_front_info
*front_info, int index,
evtchnl->index = index;
evtchnl->front_info = front_info;
evtchnl->state = EVTCHNL_STATE_DISCONNECTED;
- evtchnl->gref = GRANT_INVALID_REF;
+ evtchnl->gref = INVALID_GRANT_REF;
page = get_zeroed_page(GFP_NOIO | __GFP_HIGH);
if (!page) {
--
2.34.1
[PATCH v2 17/19] xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify xen-hcd's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
Acked-by: Greg Kroah-Hartman
---
drivers/usb/host/xen-hcd.c | 61 ++
1 file changed, 15 insertions(+), 46 deletions(-)
diff --git a/drivers/usb/host/xen-hcd.c b/drivers/usb/host/xen-hcd.c
index 9cbc7c2dab02..de1b09158318 100644
--- a/drivers/usb/host/xen-hcd.c
+++ b/drivers/usb/host/xen-hcd.c
@@ -1098,19 +1098,10 @@ static void xenhcd_destroy_rings(struct xenhcd_info
*info)
unbind_from_irqhandler(info->irq, info);
info->irq = 0;
- if (info->urb_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(info->urb_ring_ref,
- (unsigned long)info->urb_ring.sring);
- info->urb_ring_ref = INVALID_GRANT_REF;
- }
- info->urb_ring.sring = NULL;
-
- if (info->conn_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(info->conn_ring_ref,
- (unsigned long)info->conn_ring.sring);
- info->conn_ring_ref = INVALID_GRANT_REF;
- }
- info->conn_ring.sring = NULL;
+ xenbus_teardown_ring((void **)>urb_ring.sring, 1,
+>urb_ring_ref);
+ xenbus_teardown_ring((void **)>conn_ring.sring, 1,
+>conn_ring_ref);
}
static int xenhcd_setup_rings(struct xenbus_device *dev,
@@ -1118,46 +1109,24 @@ static int xenhcd_setup_rings(struct xenbus_device *dev,
{
struct xenusb_urb_sring *urb_sring;
struct xenusb_conn_sring *conn_sring;
- grant_ref_t gref;
int err;
- info->urb_ring_ref = INVALID_GRANT_REF;
info->conn_ring_ref = INVALID_GRANT_REF;
-
- urb_sring = (struct xenusb_urb_sring *)get_zeroed_page(
- GFP_NOIO | __GFP_HIGH);
- if (!urb_sring) {
- xenbus_dev_fatal(dev, -ENOMEM, "allocating urb ring");
- return -ENOMEM;
- }
- SHARED_RING_INIT(urb_sring);
- FRONT_RING_INIT(>urb_ring, urb_sring, PAGE_SIZE);
-
- err = xenbus_grant_ring(dev, urb_sring, 1, );
- if (err < 0) {
- free_page((unsigned long)urb_sring);
- info->urb_ring.sring = NULL;
- goto fail;
- }
- info->urb_ring_ref = gref;
-
- conn_sring = (struct xenusb_conn_sring *)get_zeroed_page(
- GFP_NOIO | __GFP_HIGH);
- if (!conn_sring) {
- xenbus_dev_fatal(dev, -ENOMEM, "allocating conn ring");
- err = -ENOMEM;
- goto fail;
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH,
+ (void **)_sring, 1, >urb_ring_ref);
+ if (err) {
+ xenbus_dev_fatal(dev, err, "allocating urb ring");
+ return err;
}
- SHARED_RING_INIT(conn_sring);
- FRONT_RING_INIT(>conn_ring, conn_sring, PAGE_SIZE);
+ XEN_FRONT_RING_INIT(>urb_ring, urb_sring, PAGE_SIZE);
- err = xenbus_grant_ring(dev, conn_sring, 1, );
- if (err < 0) {
- free_page((unsigned long)conn_sring);
- info->conn_ring.sring = NULL;
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH,
+ (void **)_sring, 1, >conn_ring_ref);
+ if (err) {
+ xenbus_dev_fatal(dev, err, "allocating conn ring");
goto fail;
}
- info->conn_ring_ref = gref;
+ XEN_FRONT_RING_INIT(>conn_ring, conn_sring, PAGE_SIZE);
err = xenbus_alloc_evtchn(dev, >evtchn);
if (err) {
--
2.34.1
[PATCH v2 16/19] xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify scsifront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/scsi/xen-scsifront.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 4c55e479fc36..51afc66e839d 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -798,27 +798,15 @@ static int scsifront_alloc_ring(struct vscsifrnt_info
*info)
{
struct xenbus_device *dev = info->dev;
struct vscsiif_sring *sring;
- grant_ref_t gref;
- int err = -ENOMEM;
+ int err;
/* Frontend to Backend ring start */
- sring = (struct vscsiif_sring *)__get_free_page(GFP_KERNEL);
- if (!sring) {
- xenbus_dev_fatal(dev, err,
- "fail to allocate shared ring (Front to Back)");
+ err = xenbus_setup_ring(dev, GFP_KERNEL, (void **), 1,
+ >ring_ref);
+ if (err)
return err;
- }
- SHARED_RING_INIT(sring);
- FRONT_RING_INIT(>ring, sring, PAGE_SIZE);
- err = xenbus_grant_ring(dev, sring, 1, );
- if (err < 0) {
- free_page((unsigned long)sring);
- xenbus_dev_fatal(dev, err,
- "fail to grant shared ring (Front to Back)");
- return err;
- }
- info->ring_ref = gref;
+ XEN_FRONT_RING_INIT(>ring, sring, PAGE_SIZE);
err = xenbus_alloc_evtchn(dev, >evtchn);
if (err) {
@@ -847,8 +835,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
free_irq:
unbind_from_irqhandler(info->irq, info);
free_gnttab:
- gnttab_end_foreign_access(info->ring_ref,
- (unsigned long)info->ring.sring);
+ xenbus_teardown_ring((void **), 1, >ring_ref);
return err;
}
@@ -856,8 +843,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
static void scsifront_free_ring(struct vscsifrnt_info *info)
{
unbind_from_irqhandler(info->irq, info);
- gnttab_end_foreign_access(info->ring_ref,
- (unsigned long)info->ring.sring);
+ xenbus_teardown_ring((void **)>ring.sring, 1, >ring_ref);
}
static int scsifront_init_ring(struct vscsifrnt_info *info)
--
2.34.1
[PATCH v2 12/19] xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify netfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 53 +-
1 file changed, 12 insertions(+), 41 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 966bee2a6902..65ab907aca5a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1921,8 +1921,7 @@ static int setup_netfront(struct xenbus_device *dev,
struct netfront_queue *queue, unsigned int
feature_split_evtchn)
{
struct xen_netif_tx_sring *txs;
- struct xen_netif_rx_sring *rxs = NULL;
- grant_ref_t gref;
+ struct xen_netif_rx_sring *rxs;
int err;
queue->tx_ring_ref = INVALID_GRANT_REF;
@@ -1930,33 +1929,19 @@ static int setup_netfront(struct xenbus_device *dev,
queue->rx.sring = NULL;
queue->tx.sring = NULL;
- txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO |
__GFP_HIGH);
- if (!txs) {
- err = -ENOMEM;
- xenbus_dev_fatal(dev, err, "allocating tx ring page");
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH, (void **),
+ 1, >tx_ring_ref);
+ if (err)
goto fail;
- }
- SHARED_RING_INIT(txs);
- FRONT_RING_INIT(>tx, txs, XEN_PAGE_SIZE);
- err = xenbus_grant_ring(dev, txs, 1, );
- if (err < 0)
- goto fail;
- queue->tx_ring_ref = gref;
+ XEN_FRONT_RING_INIT(>tx, txs, XEN_PAGE_SIZE);
- rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO |
__GFP_HIGH);
- if (!rxs) {
- err = -ENOMEM;
- xenbus_dev_fatal(dev, err, "allocating rx ring page");
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH, (void **),
+ 1, >rx_ring_ref);
+ if (err)
goto fail;
- }
- SHARED_RING_INIT(rxs);
- FRONT_RING_INIT(>rx, rxs, XEN_PAGE_SIZE);
- err = xenbus_grant_ring(dev, rxs, 1, );
- if (err < 0)
- goto fail;
- queue->rx_ring_ref = gref;
+ XEN_FRONT_RING_INIT(>rx, rxs, XEN_PAGE_SIZE);
if (feature_split_evtchn)
err = setup_netfront_split(queue);
@@ -1972,24 +1957,10 @@ static int setup_netfront(struct xenbus_device *dev,
return 0;
- /* If we fail to setup netfront, it is safe to just revoke access to
-* granted pages because backend is not accessing it at this point.
-*/
fail:
- if (queue->rx_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(queue->rx_ring_ref,
- (unsigned long)rxs);
- queue->rx_ring_ref = INVALID_GRANT_REF;
- } else {
- free_page((unsigned long)rxs);
- }
- if (queue->tx_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(queue->tx_ring_ref,
- (unsigned long)txs);
- queue->tx_ring_ref = INVALID_GRANT_REF;
- } else {
- free_page((unsigned long)txs);
- }
+ xenbus_teardown_ring((void **)>rx.sring, 1, >rx_ring_ref);
+ xenbus_teardown_ring((void **)>tx.sring, 1, >tx_ring_ref);
+
return err;
}
--
2.34.1
[PATCH v2 09/19] xen: update ring.h
Update include/xen/interface/io/ring.h to its newest version.
Switch the two improper use cases of RING_HAS_UNCONSUMED_RESPONSES() to
XEN_RING_NR_UNCONSUMED_RESPONSES() in order to avoid the nasty
XEN_RING_HAS_UNCONSUMED_IS_BOOL #define.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/net/xen-netfront.c | 4 ++--
include/xen/interface/io/ring.h | 19 ++-
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index af3d3de7d9fa..966bee2a6902 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -866,7 +866,7 @@ static void xennet_set_rx_rsp_cons(struct netfront_queue
*queue, RING_IDX val)
spin_lock_irqsave(>rx_cons_lock, flags);
queue->rx.rsp_cons = val;
- queue->rx_rsp_unconsumed = RING_HAS_UNCONSUMED_RESPONSES(>rx);
+ queue->rx_rsp_unconsumed = XEN_RING_NR_UNCONSUMED_RESPONSES(>rx);
spin_unlock_irqrestore(>rx_cons_lock, flags);
}
@@ -1498,7 +1498,7 @@ static bool xennet_handle_rx(struct netfront_queue
*queue, unsigned int *eoi)
return false;
spin_lock_irqsave(>rx_cons_lock, flags);
- work_queued = RING_HAS_UNCONSUMED_RESPONSES(>rx);
+ work_queued = XEN_RING_NR_UNCONSUMED_RESPONSES(>rx);
if (work_queued > queue->rx_rsp_unconsumed) {
queue->rx_rsp_unconsumed = work_queued;
*eoi = 0;
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 2470ec45ebb2..ba4c4274b714 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -72,9 +72,8 @@ typedef unsigned int RING_IDX;
* of the shared memory area (PAGE_SIZE, for instance). To initialise
* the front half:
*
- * mytag_front_ring_t front_ring;
- * SHARED_RING_INIT((mytag_sring_t *)shared_page);
- * FRONT_RING_INIT(_ring, (mytag_sring_t *)shared_page, PAGE_SIZE);
+ * mytag_front_ring_t ring;
+ * XEN_FRONT_RING_INIT(, (mytag_sring_t *)shared_page, PAGE_SIZE);
*
* Initializing the back follows similarly (note that only the front
* initializes the shared ring):
@@ -146,6 +145,11 @@ struct __name##_back_ring {
\
#define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s, 0, __size)
+#define XEN_FRONT_RING_INIT(r, s, size) do {\
+SHARED_RING_INIT(s);\
+FRONT_RING_INIT(r, s, size);\
+} while (0)
+
#define BACK_RING_ATTACH(_r, _s, _i, __size) do { \
(_r)->rsp_prod_pvt = (_i); \
(_r)->req_cons = (_i); \
@@ -170,16 +174,21 @@ struct __name##_back_ring {
\
(RING_FREE_REQUESTS(_r) == 0)
/* Test if there are outstanding messages to be processed on a ring. */
-#define RING_HAS_UNCONSUMED_RESPONSES(_r) \
+#define XEN_RING_NR_UNCONSUMED_RESPONSES(_r)\
((_r)->sring->rsp_prod - (_r)->rsp_cons)
-#define RING_HAS_UNCONSUMED_REQUESTS(_r) ({ \
+#define XEN_RING_NR_UNCONSUMED_REQUESTS(_r) ({ \
unsigned int req = (_r)->sring->req_prod - (_r)->req_cons; \
unsigned int rsp = RING_SIZE(_r) - \
((_r)->req_cons - (_r)->rsp_prod_pvt); \
req < rsp ? req : rsp; \
})
+#define RING_HAS_UNCONSUMED_RESPONSES(_r) \
+(!!XEN_RING_NR_UNCONSUMED_RESPONSES(_r))
+#define RING_HAS_UNCONSUMED_REQUESTS(_r) \
+(!!XEN_RING_NR_UNCONSUMED_REQUESTS(_r))
+
/* Direct access to individual ring elements, by index. */
#define RING_GET_REQUEST(_r, _idx) \
(&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))
--
2.34.1
[PATCH v2 07/19] xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/xen/gntdev-dmabuf.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index d5bfd7b867fc..91073b4e4a20 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -24,15 +24,6 @@
MODULE_IMPORT_NS(DMA_BUF);
-#ifndef GRANT_INVALID_REF
-/*
- * Note on usage of grant reference 0 as invalid grant reference:
- * grant reference 0 is valid, but never exposed to a driver,
- * because of the fact it is already in use/reserved by the PV console.
- */
-#define GRANT_INVALID_REF 0
-#endif
-
struct gntdev_dmabuf {
struct gntdev_dmabuf_priv *priv;
struct dma_buf *dmabuf;
@@ -532,7 +523,7 @@ static void dmabuf_imp_end_foreign_access(u32 *refs, int
count)
int i;
for (i = 0; i < count; i++)
- if (refs[i] != GRANT_INVALID_REF)
+ if (refs[i] != INVALID_GRANT_REF)
gnttab_end_foreign_access(refs[i], 0UL);
}
@@ -567,7 +558,7 @@ static struct gntdev_dmabuf *dmabuf_imp_alloc_storage(int
count)
gntdev_dmabuf->nr_pages = count;
for (i = 0; i < count; i++)
- gntdev_dmabuf->u.imp.refs[i] = GRANT_INVALID_REF;
+ gntdev_dmabuf->u.imp.refs[i] = INVALID_GRANT_REF;
return gntdev_dmabuf;
--
2.34.1
[PATCH v2 01/19] xen/blkfront: switch blkfront to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 003056d4f7f5..7f35e30e626a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -229,8 +229,6 @@ static unsigned int nr_minors;
static unsigned long *minors;
static DEFINE_SPINLOCK(minor_lock);
-#define GRANT_INVALID_REF 0
-
#define PARTS_PER_DISK 16
#define PARTS_PER_EXT_DISK 256
@@ -321,7 +319,7 @@ static int fill_grant_buffer(struct blkfront_ring_info
*rinfo, int num)
gnt_list_entry->page = granted_page;
}
- gnt_list_entry->gref = GRANT_INVALID_REF;
+ gnt_list_entry->gref = INVALID_GRANT_REF;
list_add(_list_entry->node, >grants);
i++;
}
@@ -350,7 +348,7 @@ static struct grant *get_free_grant(struct
blkfront_ring_info *rinfo)
node);
list_del(_list_entry->node);
- if (gnt_list_entry->gref != GRANT_INVALID_REF)
+ if (gnt_list_entry->gref != INVALID_GRANT_REF)
rinfo->persistent_gnts_c--;
return gnt_list_entry;
@@ -372,7 +370,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
struct grant *gnt_list_entry = get_free_grant(rinfo);
struct blkfront_info *info = rinfo->dev_info;
- if (gnt_list_entry->gref != GRANT_INVALID_REF)
+ if (gnt_list_entry->gref != INVALID_GRANT_REF)
return gnt_list_entry;
/* Assign a gref to this page */
@@ -396,7 +394,7 @@ static struct grant *get_indirect_grant(grant_ref_t
*gref_head,
struct grant *gnt_list_entry = get_free_grant(rinfo);
struct blkfront_info *info = rinfo->dev_info;
- if (gnt_list_entry->gref != GRANT_INVALID_REF)
+ if (gnt_list_entry->gref != INVALID_GRANT_REF)
return gnt_list_entry;
/* Assign a gref to this page */
@@ -1221,7 +1219,7 @@ static void blkif_free_ring(struct blkfront_ring_info
*rinfo)
list_for_each_entry_safe(persistent_gnt, n,
>grants, node) {
list_del(_gnt->node);
- if (persistent_gnt->gref != GRANT_INVALID_REF) {
+ if (persistent_gnt->gref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(persistent_gnt->gref,
0UL);
rinfo->persistent_gnts_c--;
@@ -1283,9 +1281,9 @@ static void blkif_free_ring(struct blkfront_ring_info
*rinfo)
/* Free resources associated with old device channel. */
for (i = 0; i < info->nr_ring_pages; i++) {
- if (rinfo->ring_ref[i] != GRANT_INVALID_REF) {
+ if (rinfo->ring_ref[i] != INVALID_GRANT_REF) {
gnttab_end_foreign_access(rinfo->ring_ref[i], 0);
- rinfo->ring_ref[i] = GRANT_INVALID_REF;
+ rinfo->ring_ref[i] = INVALID_GRANT_REF;
}
}
free_pages_exact(rinfo->ring.sring,
@@ -1475,7 +1473,7 @@ static int blkif_completion(unsigned long *id,
* to the tail of the list, so it will not be picked
* again unless we run out of persistent grants.
*/
- s->grants_used[i]->gref = GRANT_INVALID_REF;
+ s->grants_used[i]->gref = INVALID_GRANT_REF;
list_add_tail(>grants_used[i]->node, >grants);
}
}
@@ -1500,7 +1498,7 @@ static int blkif_completion(unsigned long *id,
indirect_page =
s->indirect_grants[i]->page;
list_add(_page->lru,
>indirect_pages);
}
- s->indirect_grants[i]->gref = GRANT_INVALID_REF;
+ s->indirect_grants[i]->gref = INVALID_GRANT_REF;
list_add_tail(>indirect_grants[i]->node,
>grants);
}
}
@@ -1687,7 +1685,7 @@ static int setup_blkring(struct xenbus_device *dev,
grant_ref_t gref[XENBUS_MAX_RING_GRANTS];
for (i = 0; i < info->nr_ring_pages; i++)
- rinfo->ring_ref[i] = GRANT_INVALID_REF;
+ rinfo->ring_ref[i] = INVALID_GRANT_REF;
sring = alloc_pages_exact(ring_size, GFP_NOIO);
if (!sring) {
@@ -2544,13 +2542,13 @@ static void purge_persistent_grants(struct
blkfront_info *info)
list_for_each_entry_safe(gnt_list_entry, tmp, >grants,
node) {
-
[PATCH v2 03/19] xen/scsifront: remove unused GRANT_INVALID_REF definition
GRANT_INVALID_REF isn't used in scsifront, so remove it. Signed-off-by: Juergen Gross --- drivers/scsi/xen-scsifront.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c index 56173beecbc6..4c55e479fc36 100644 --- a/drivers/scsi/xen-scsifront.c +++ b/drivers/scsi/xen-scsifront.c @@ -58,9 +58,6 @@ #include - -#define GRANT_INVALID_REF 0 - #define VSCSIFRONT_OP_ADD_LUN 1 #define VSCSIFRONT_OP_DEL_LUN 2 #define VSCSIFRONT_OP_READD_LUN3 -- 2.34.1
[PATCH v2 14/19] xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify drmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 43 ++---
1 file changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
index 4006568b9e32..e52afd792346 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
@@ -123,12 +123,12 @@ static irqreturn_t evtchnl_interrupt_evt(int irq, void
*dev_id)
static void evtchnl_free(struct xen_drm_front_info *front_info,
struct xen_drm_front_evtchnl *evtchnl)
{
- unsigned long page = 0;
+ void *page = NULL;
if (evtchnl->type == EVTCHNL_TYPE_REQ)
- page = (unsigned long)evtchnl->u.req.ring.sring;
+ page = evtchnl->u.req.ring.sring;
else if (evtchnl->type == EVTCHNL_TYPE_EVT)
- page = (unsigned long)evtchnl->u.evt.page;
+ page = evtchnl->u.evt.page;
if (!page)
return;
@@ -147,8 +147,7 @@ static void evtchnl_free(struct xen_drm_front_info
*front_info,
xenbus_free_evtchn(front_info->xb_dev, evtchnl->port);
/* end access and free the page */
- if (evtchnl->gref != INVALID_GRANT_REF)
- gnttab_end_foreign_access(evtchnl->gref, page);
+ xenbus_teardown_ring(, 1, >gref);
memset(evtchnl, 0, sizeof(*evtchnl));
}
@@ -158,8 +157,7 @@ static int evtchnl_alloc(struct xen_drm_front_info
*front_info, int index,
enum xen_drm_front_evtchnl_type type)
{
struct xenbus_device *xb_dev = front_info->xb_dev;
- unsigned long page;
- grant_ref_t gref;
+ void *page;
irq_handler_t handler;
int ret;
@@ -168,44 +166,25 @@ static int evtchnl_alloc(struct xen_drm_front_info
*front_info, int index,
evtchnl->index = index;
evtchnl->front_info = front_info;
evtchnl->state = EVTCHNL_STATE_DISCONNECTED;
- evtchnl->gref = INVALID_GRANT_REF;
- page = get_zeroed_page(GFP_NOIO | __GFP_HIGH);
- if (!page) {
- ret = -ENOMEM;
+ ret = xenbus_setup_ring(xb_dev, GFP_NOIO | __GFP_HIGH, ,
+ 1, >gref);
+ if (ret)
goto fail;
- }
if (type == EVTCHNL_TYPE_REQ) {
struct xen_displif_sring *sring;
init_completion(>u.req.completion);
mutex_init(>u.req.req_io_lock);
- sring = (struct xen_displif_sring *)page;
- SHARED_RING_INIT(sring);
- FRONT_RING_INIT(>u.req.ring, sring, XEN_PAGE_SIZE);
-
- ret = xenbus_grant_ring(xb_dev, sring, 1, );
- if (ret < 0) {
- evtchnl->u.req.ring.sring = NULL;
- free_page(page);
- goto fail;
- }
+ sring = page;
+ XEN_FRONT_RING_INIT(>u.req.ring, sring, XEN_PAGE_SIZE);
handler = evtchnl_interrupt_ctrl;
} else {
- ret = gnttab_grant_foreign_access(xb_dev->otherend_id,
- virt_to_gfn((void *)page), 0);
- if (ret < 0) {
- free_page(page);
- goto fail;
- }
-
- evtchnl->u.evt.page = (struct xendispl_event_page *)page;
- gref = ret;
+ evtchnl->u.evt.page = page;
handler = evtchnl_interrupt_evt;
}
- evtchnl->gref = gref;
ret = xenbus_alloc_evtchn(xb_dev, >port);
if (ret < 0)
--
2.34.1
[PATCH v2 15/19] xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify pcifront's shared page creation and removal via
xenbus_setup_ring() and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/pci/xen-pcifront.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 3edc1565a27c..689271c4245c 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -709,9 +709,8 @@ static struct pcifront_device *alloc_pdev(struct
xenbus_device *xdev)
if (pdev == NULL)
goto out;
- pdev->sh_info =
- (struct xen_pci_sharedinfo *)__get_free_page(GFP_KERNEL);
- if (pdev->sh_info == NULL) {
+ if (xenbus_setup_ring(xdev, GFP_KERNEL, (void **)>sh_info, 1,
+ >gnt_ref)) {
kfree(pdev);
pdev = NULL;
goto out;
@@ -729,7 +728,6 @@ static struct pcifront_device *alloc_pdev(struct
xenbus_device *xdev)
spin_lock_init(>sh_info_lock);
pdev->evtchn = INVALID_EVTCHN;
- pdev->gnt_ref = INVALID_GRANT_REF;
pdev->irq = -1;
INIT_WORK(>op_work, pcifront_do_aer);
@@ -754,11 +752,7 @@ static void free_pdev(struct pcifront_device *pdev)
if (pdev->evtchn != INVALID_EVTCHN)
xenbus_free_evtchn(pdev->xdev, pdev->evtchn);
- if (pdev->gnt_ref != INVALID_GRANT_REF)
- gnttab_end_foreign_access(pdev->gnt_ref,
- (unsigned long)pdev->sh_info);
- else
- free_page((unsigned long)pdev->sh_info);
+ xenbus_teardown_ring((void **)>sh_info, 1, >gnt_ref);
dev_set_drvdata(>xdev->dev, NULL);
@@ -769,13 +763,6 @@ static int pcifront_publish_info(struct pcifront_device
*pdev)
{
int err = 0;
struct xenbus_transaction trans;
- grant_ref_t gref;
-
- err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, );
- if (err < 0)
- goto out;
-
- pdev->gnt_ref = gref;
err = xenbus_alloc_evtchn(pdev->xdev, >evtchn);
if (err)
--
2.34.1
[PATCH v2 13/19] xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify tpmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/char/tpm/xen-tpmfront.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 69df04ae2401..379291826261 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -253,20 +253,12 @@ static int setup_ring(struct xenbus_device *dev, struct
tpm_private *priv)
struct xenbus_transaction xbt;
const char *message = NULL;
int rv;
- grant_ref_t gref;
- priv->shr = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
- if (!priv->shr) {
- xenbus_dev_fatal(dev, -ENOMEM, "allocating shared ring");
- return -ENOMEM;
- }
-
- rv = xenbus_grant_ring(dev, priv->shr, 1, );
+ rv = xenbus_setup_ring(dev, GFP_KERNEL, (void **)>shr, 1,
+ >ring_ref);
if (rv < 0)
return rv;
- priv->ring_ref = gref;
-
rv = xenbus_alloc_evtchn(dev, >evtchn);
if (rv)
return rv;
@@ -331,11 +323,7 @@ static void ring_free(struct tpm_private *priv)
if (!priv)
return;
- if (priv->ring_ref)
- gnttab_end_foreign_access(priv->ring_ref,
- (unsigned long)priv->shr);
- else
- free_page((unsigned long)priv->shr);
+ xenbus_teardown_ring((void **)>shr, 1, >ring_ref);
if (priv->irq)
unbind_from_irqhandler(priv->irq, priv);
--
2.34.1
[PATCH v2 11/19] xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring()
Simplify blkfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 37
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 7f35e30e626a..bd7b34f29193 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1280,15 +1280,8 @@ static void blkif_free_ring(struct blkfront_ring_info
*rinfo)
flush_work(>work);
/* Free resources associated with old device channel. */
- for (i = 0; i < info->nr_ring_pages; i++) {
- if (rinfo->ring_ref[i] != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(rinfo->ring_ref[i], 0);
- rinfo->ring_ref[i] = INVALID_GRANT_REF;
- }
- }
- free_pages_exact(rinfo->ring.sring,
-info->nr_ring_pages * XEN_PAGE_SIZE);
- rinfo->ring.sring = NULL;
+ xenbus_teardown_ring((void **)>ring.sring, info->nr_ring_pages,
+rinfo->ring_ref);
if (rinfo->irq)
unbind_from_irqhandler(rinfo->irq, rinfo);
@@ -1679,30 +1672,16 @@ static int setup_blkring(struct xenbus_device *dev,
struct blkfront_ring_info *rinfo)
{
struct blkif_sring *sring;
- int err, i;
+ int err;
struct blkfront_info *info = rinfo->dev_info;
unsigned long ring_size = info->nr_ring_pages * XEN_PAGE_SIZE;
- grant_ref_t gref[XENBUS_MAX_RING_GRANTS];
-
- for (i = 0; i < info->nr_ring_pages; i++)
- rinfo->ring_ref[i] = INVALID_GRANT_REF;
- sring = alloc_pages_exact(ring_size, GFP_NOIO);
- if (!sring) {
- xenbus_dev_fatal(dev, -ENOMEM, "allocating shared ring");
- return -ENOMEM;
- }
- SHARED_RING_INIT(sring);
- FRONT_RING_INIT(>ring, sring, ring_size);
-
- err = xenbus_grant_ring(dev, rinfo->ring.sring, info->nr_ring_pages,
gref);
- if (err < 0) {
- free_pages_exact(sring, ring_size);
- rinfo->ring.sring = NULL;
+ err = xenbus_setup_ring(dev, GFP_NOIO, (void **),
+ info->nr_ring_pages, rinfo->ring_ref);
+ if (err)
goto fail;
- }
- for (i = 0; i < info->nr_ring_pages; i++)
- rinfo->ring_ref[i] = gref[i];
+
+ XEN_FRONT_RING_INIT(>ring, sring, ring_size);
err = xenbus_alloc_evtchn(dev, >evtchn);
if (err)
--
2.34.1
[PATCH v2 10/19] xen/xenbus: add xenbus_setup_ring() service function
Most PV device frontends share very similar code for setting up shared
ring buffers:
- allocate page(s)
- init the ring admin data
- give the backend access to the ring via grants
Tearing down the ring requires similar actions in all frontends again:
- remove grants
- free the page(s)
Provide service functions xenbus_setup_ring() and xenbus_teardown_ring()
for that purpose.
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_client.c | 69 ++
include/xen/xenbus.h | 4 ++
2 files changed, 73 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index df6890681231..1a2e0d94ccd1 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -407,6 +407,75 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
}
EXPORT_SYMBOL_GPL(xenbus_grant_ring);
+/*
+ * xenbus_setup_ring
+ * @dev: xenbus device
+ * @vaddr: pointer to starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+ * Allocate physically contiguous pages for a shared ring buffer and grant it
+ * to the peer of the given device. The ring buffer is initially filled with
+ * zeroes. The virtual address of the ring is stored at @vaddr and the
+ * grant references are stored in the @grefs array. In case of error @vaddr
+ * will be set to NULL and @grefs will be filled with INVALID_GRANT_REF.
+ */
+int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, void **vaddr,
+ unsigned int nr_pages, grant_ref_t *grefs)
+{
+ unsigned long ring_size = nr_pages * XEN_PAGE_SIZE;
+ unsigned int i;
+ int ret;
+
+ *vaddr = alloc_pages_exact(ring_size, gfp | __GFP_ZERO);
+ if (!*vaddr) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = xenbus_grant_ring(dev, *vaddr, nr_pages, grefs);
+ if (ret)
+ goto err;
+
+ return 0;
+
+ err:
+ if (*vaddr)
+ free_pages_exact(*vaddr, ring_size);
+ for (i = 0; i < nr_pages; i++)
+ grefs[i] = INVALID_GRANT_REF;
+ *vaddr = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(xenbus_setup_ring);
+
+/*
+ * xenbus_teardown_ring
+ * @vaddr: starting virtual address of the ring
+ * @nr_pages: number of pages
+ * @grefs: grant reference array
+ *
+ * Remove grants for the shared ring buffer and free the associated memory.
+ * On return the grant reference array is filled with INVALID_GRANT_REF.
+ */
+void xenbus_teardown_ring(void **vaddr, unsigned int nr_pages,
+ grant_ref_t *grefs)
+{
+ unsigned int i;
+
+ for (i = 0; i < nr_pages; i++) {
+ if (grefs[i] != INVALID_GRANT_REF) {
+ gnttab_end_foreign_access(grefs[i], 0);
+ grefs[i] = INVALID_GRANT_REF;
+ }
+ }
+
+ if (*vaddr)
+ free_pages_exact(*vaddr, nr_pages * XEN_PAGE_SIZE);
+ *vaddr = NULL;
+}
+EXPORT_SYMBOL_GPL(xenbus_teardown_ring);
/**
* Allocate an event channel for the given xenbus_device, assigning the newly
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index b13eb86395e0..b533b4adc835 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -226,6 +226,10 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct
xenbus_watch *watch,
int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state
new_state);
int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
unsigned int nr_pages, grant_ref_t *grefs);
+int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, void **vaddr,
+ unsigned int nr_pages, grant_ref_t *grefs);
+void xenbus_teardown_ring(void **vaddr, unsigned int nr_pages,
+ grant_ref_t *grefs);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr);
--
2.34.1
[PATCH v2 06/19] xen/sound: switch xen_snd_front to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
sound/xen/xen_snd_front_evtchnl.c | 4 ++--
sound/xen/xen_snd_front_evtchnl.h | 9 -
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/sound/xen/xen_snd_front_evtchnl.c
b/sound/xen/xen_snd_front_evtchnl.c
index ecbc294fc59a..3e21369c8216 100644
--- a/sound/xen/xen_snd_front_evtchnl.c
+++ b/sound/xen/xen_snd_front_evtchnl.c
@@ -167,7 +167,7 @@ static void evtchnl_free(struct xen_snd_front_info
*front_info,
xenbus_free_evtchn(front_info->xb_dev, channel->port);
/* End access and free the page. */
- if (channel->gref != GRANT_INVALID_REF)
+ if (channel->gref != INVALID_GRANT_REF)
gnttab_end_foreign_access(channel->gref, page);
else
free_page(page);
@@ -207,7 +207,7 @@ static int evtchnl_alloc(struct xen_snd_front_info
*front_info, int index,
channel->index = index;
channel->front_info = front_info;
channel->state = EVTCHNL_STATE_DISCONNECTED;
- channel->gref = GRANT_INVALID_REF;
+ channel->gref = INVALID_GRANT_REF;
page = get_zeroed_page(GFP_KERNEL);
if (!page) {
ret = -ENOMEM;
diff --git a/sound/xen/xen_snd_front_evtchnl.h
b/sound/xen/xen_snd_front_evtchnl.h
index cbe51fd1ec15..3675fba70564 100644
--- a/sound/xen/xen_snd_front_evtchnl.h
+++ b/sound/xen/xen_snd_front_evtchnl.h
@@ -15,15 +15,6 @@
struct xen_snd_front_info;
-#ifndef GRANT_INVALID_REF
-/*
- * FIXME: usage of grant reference 0 as invalid grant reference:
- * grant reference 0 is valid, but never exposed to a PV driver,
- * because of the fact it is already in use/reserved by the PV console.
- */
-#define GRANT_INVALID_REF 0
-#endif
-
/* Timeout in ms to wait for backend to respond. */
#define VSND_WAIT_BACK_MS 3000
--
2.34.1
[PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/xen/xen-front-pgdir-shbuf.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/xen/xen-front-pgdir-shbuf.c
b/drivers/xen/xen-front-pgdir-shbuf.c
index a959dee21134..fa2921d4fbfc 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -21,15 +21,6 @@
#include
-#ifndef GRANT_INVALID_REF
-/*
- * FIXME: usage of grant reference 0 as invalid grant reference:
- * grant reference 0 is valid, but never exposed to a PV driver,
- * because of the fact it is already in use/reserved by the PV console.
- */
-#define GRANT_INVALID_REF 0
-#endif
-
/**
* This structure represents the structure of a shared page
* that contains grant references to the pages of the shared
@@ -83,7 +74,7 @@ grant_ref_t
xen_front_pgdir_shbuf_get_dir_start(struct xen_front_pgdir_shbuf *buf)
{
if (!buf->grefs)
- return GRANT_INVALID_REF;
+ return INVALID_GRANT_REF;
return buf->grefs[0];
}
@@ -142,7 +133,7 @@ void xen_front_pgdir_shbuf_free(struct
xen_front_pgdir_shbuf *buf)
int i;
for (i = 0; i < buf->num_grefs; i++)
- if (buf->grefs[i] != GRANT_INVALID_REF)
+ if (buf->grefs[i] != INVALID_GRANT_REF)
gnttab_end_foreign_access(buf->grefs[i], 0UL);
}
kfree(buf->grefs);
@@ -355,7 +346,7 @@ static void backend_fill_page_dir(struct
xen_front_pgdir_shbuf *buf)
}
/* Last page must say there is no more pages. */
page_dir = (struct xen_page_directory *)ptr;
- page_dir->gref_dir_next_page = GRANT_INVALID_REF;
+ page_dir->gref_dir_next_page = INVALID_GRANT_REF;
}
/**
@@ -384,7 +375,7 @@ static void guest_fill_page_dir(struct
xen_front_pgdir_shbuf *buf)
if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
to_copy = grefs_left;
- page_dir->gref_dir_next_page = GRANT_INVALID_REF;
+ page_dir->gref_dir_next_page = INVALID_GRANT_REF;
} else {
to_copy = XEN_NUM_GREFS_PER_PAGE;
page_dir->gref_dir_next_page = buf->grefs[i + 1];
--
2.34.1
[PATCH v2 04/19] xen/usb: switch xen-hcd to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
Acked-by: Greg Kroah-Hartman
---
drivers/usb/host/xen-hcd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xen-hcd.c b/drivers/usb/host/xen-hcd.c
index 3e487baf8422..9cbc7c2dab02 100644
--- a/drivers/usb/host/xen-hcd.c
+++ b/drivers/usb/host/xen-hcd.c
@@ -87,8 +87,6 @@ struct xenhcd_info {
bool error;
};
-#define GRANT_INVALID_REF 0
-
#define XENHCD_RING_JIFFIES (HZ/200)
#define XENHCD_SCAN_JIFFIES 1
@@ -1100,17 +1098,17 @@ static void xenhcd_destroy_rings(struct xenhcd_info
*info)
unbind_from_irqhandler(info->irq, info);
info->irq = 0;
- if (info->urb_ring_ref != GRANT_INVALID_REF) {
+ if (info->urb_ring_ref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(info->urb_ring_ref,
(unsigned long)info->urb_ring.sring);
- info->urb_ring_ref = GRANT_INVALID_REF;
+ info->urb_ring_ref = INVALID_GRANT_REF;
}
info->urb_ring.sring = NULL;
- if (info->conn_ring_ref != GRANT_INVALID_REF) {
+ if (info->conn_ring_ref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(info->conn_ring_ref,
(unsigned long)info->conn_ring.sring);
- info->conn_ring_ref = GRANT_INVALID_REF;
+ info->conn_ring_ref = INVALID_GRANT_REF;
}
info->conn_ring.sring = NULL;
}
@@ -1123,8 +1121,8 @@ static int xenhcd_setup_rings(struct xenbus_device *dev,
grant_ref_t gref;
int err;
- info->urb_ring_ref = GRANT_INVALID_REF;
- info->conn_ring_ref = GRANT_INVALID_REF;
+ info->urb_ring_ref = INVALID_GRANT_REF;
+ info->conn_ring_ref = INVALID_GRANT_REF;
urb_sring = (struct xenusb_urb_sring *)get_zeroed_page(
GFP_NOIO | __GFP_HIGH);
--
2.34.1
[PATCH v2 00/19] xen: simplify frontend side ring setup
Many Xen PV frontends share similar code for setting up a ring page (allocating and granting access for the backend) and for tearing it down. Create new service functions doing all needed steps in one go. This requires all frontends to use a common value for an invalid grant reference in order to make the functions idempotent. Changes in V2: - new patch 9 and related changes in patches 10-18 Juergen Gross (19): xen/blkfront: switch blkfront to use INVALID_GRANT_REF xen/netfront: switch netfront to use INVALID_GRANT_REF xen/scsifront: remove unused GRANT_INVALID_REF definition xen/usb: switch xen-hcd to use INVALID_GRANT_REF xen/drm: switch xen_drm_front to use INVALID_GRANT_REF xen/sound: switch xen_snd_front to use INVALID_GRANT_REF xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REF xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF xen: update ring.h xen/xenbus: add xenbus_setup_ring() service function xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/xenbus: eliminate xenbus_grant_ring() drivers/block/xen-blkfront.c| 57 +- drivers/char/tpm/xen-tpmfront.c | 18 + drivers/gpu/drm/xen/xen_drm_front.h | 9 --- drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 43 +++ drivers/net/xen-netfront.c | 85 +++-- drivers/pci/xen-pcifront.c | 19 + drivers/scsi/xen-scsifront.c| 31 ++-- drivers/usb/host/xen-hcd.c | 65 drivers/xen/gntdev-dmabuf.c | 13 +--- drivers/xen/xen-front-pgdir-shbuf.c | 17 + drivers/xen/xenbus/xenbus_client.c | 82 +++- include/xen/interface/io/ring.h | 19 +++-- include/xen/xenbus.h| 4 +- sound/xen/xen_snd_front_evtchnl.c | 44 +++ sound/xen/xen_snd_front_evtchnl.h | 9 --- 15 files changed, 179 insertions(+), 336 deletions(-) -- 2.34.1
[PATCH v2 02/19] xen/netfront: switch netfront to use INVALID_GRANT_REF
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e2b4a1893a13..af3d3de7d9fa 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -78,8 +78,6 @@ struct netfront_cb {
#define RX_COPY_THRESHOLD 256
-#define GRANT_INVALID_REF 0
-
#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, XEN_PAGE_SIZE)
#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, XEN_PAGE_SIZE)
@@ -224,7 +222,7 @@ static grant_ref_t xennet_get_rx_ref(struct netfront_queue
*queue,
{
int i = xennet_rxidx(ri);
grant_ref_t ref = queue->grant_rx_ref[i];
- queue->grant_rx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_rx_ref[i] = INVALID_GRANT_REF;
return ref;
}
@@ -432,7 +430,7 @@ static bool xennet_tx_buf_gc(struct netfront_queue *queue)
}
gnttab_release_grant_reference(
>gref_tx_head, queue->grant_tx_ref[id]);
- queue->grant_tx_ref[id] = GRANT_INVALID_REF;
+ queue->grant_tx_ref[id] = INVALID_GRANT_REF;
queue->grant_tx_page[id] = NULL;
add_id_to_list(>tx_skb_freelist, queue->tx_link,
id);
dev_kfree_skb_irq(skb);
@@ -1021,7 +1019,7 @@ static int xennet_get_responses(struct netfront_queue
*queue,
* the backend driver. In future this should flag the bad
* situation to the system controller to reboot the backend.
*/
- if (ref == GRANT_INVALID_REF) {
+ if (ref == INVALID_GRANT_REF) {
if (net_ratelimit())
dev_warn(dev, "Bad rx response id %d.\n",
rx->id);
@@ -1390,7 +1388,7 @@ static void xennet_release_tx_bufs(struct netfront_queue
*queue)
gnttab_end_foreign_access(queue->grant_tx_ref[i],
(unsigned
long)page_address(queue->grant_tx_page[i]));
queue->grant_tx_page[i] = NULL;
- queue->grant_tx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_tx_ref[i] = INVALID_GRANT_REF;
add_id_to_list(>tx_skb_freelist, queue->tx_link, i);
dev_kfree_skb_irq(skb);
}
@@ -1411,7 +1409,7 @@ static void xennet_release_rx_bufs(struct netfront_queue
*queue)
continue;
ref = queue->grant_rx_ref[id];
- if (ref == GRANT_INVALID_REF)
+ if (ref == INVALID_GRANT_REF)
continue;
page = skb_frag_page(_shinfo(skb)->frags[0]);
@@ -1422,7 +1420,7 @@ static void xennet_release_rx_bufs(struct netfront_queue
*queue)
get_page(page);
gnttab_end_foreign_access(ref,
(unsigned long)page_address(page));
- queue->grant_rx_ref[id] = GRANT_INVALID_REF;
+ queue->grant_rx_ref[id] = INVALID_GRANT_REF;
kfree_skb(skb);
}
@@ -1761,7 +1759,7 @@ static int netfront_probe(struct xenbus_device *dev,
static void xennet_end_access(int ref, void *page)
{
/* This frees the page as a side-effect */
- if (ref != GRANT_INVALID_REF)
+ if (ref != INVALID_GRANT_REF)
gnttab_end_foreign_access(ref, (unsigned long)page);
}
@@ -1798,8 +1796,8 @@ static void xennet_disconnect_backend(struct
netfront_info *info)
xennet_end_access(queue->tx_ring_ref, queue->tx.sring);
xennet_end_access(queue->rx_ring_ref, queue->rx.sring);
- queue->tx_ring_ref = GRANT_INVALID_REF;
- queue->rx_ring_ref = GRANT_INVALID_REF;
+ queue->tx_ring_ref = INVALID_GRANT_REF;
+ queue->rx_ring_ref = INVALID_GRANT_REF;
queue->tx.sring = NULL;
queue->rx.sring = NULL;
@@ -1927,8 +1925,8 @@ static int setup_netfront(struct xenbus_device *dev,
grant_ref_t gref;
int err;
- queue->tx_ring_ref = GRANT_INVALID_REF;
- queue->rx_ring_ref = GRANT_INVALID_REF;
+ queue->tx_ring_ref = INVALID_GRANT_REF;
+ queue->rx_ring_ref = INVALID_GRANT_REF;
queue->rx.sring = NULL;
queue->tx.sring = NULL;
@@ -1978,17 +1976,17 @@ static int setup_netfront(struct xenbus_device *dev,
* granted pages because backend is not accessing it at this point.
*/
fail:
- if (queue->rx_ring_ref != GRANT_INVALID_REF) {
+ if (queue->rx_ring_ref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(queue->rx_ring_ref,
Re: [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier
Hi Guilherme,
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic context,
with interrupts and preemption disabled in the running CPU and all other
CPUs disabled. That said, mutexes in such context are not a good idea.
This patch replaces a regular mutex with a mutex_trylock safer approach;
given the nature of the mutex used in the driver, it should be pretty
uncommon being unable to acquire such mutex in the panic path, hence
no functional change should be observed (and if it is, that would be
likely a deadlock with the regular mutex).
Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
Cc: Leo Yan
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Guilherme G. Piccoli
How would you like to proceed with queuing this ? I am happy
either way. In case you plan to push this as part of this
series (I don't see any potential conflicts) :
Reviewed-by: Suzuki K Poulose
Re: [PATCH 20/30] panic: Add the panic informational notifier list
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The goal of this new panic notifier is to allow its users to
register callbacks to run earlier in the panic path than they
currently do. This aims at informational mechanisms, like dumping
kernel offsets and showing device error data (in case it's simple
registers reading, for example) as well as mechanisms to disable
log flooding (like hung_task detector / RCU warnings) and the
tracing dump_on_oops (when enabled).
Any (non-invasive) information that should be provided before
kmsg_dump() as well as log flooding preventing code should fit
here, as long it offers relatively low risk for kdump.
For now, the patch is almost a no-op, although it changes a bit
the ordering in which some panic notifiers are executed - specially
affected by this are the notifiers responsible for disabling the
hung_task detector / RCU warnings, which now run first. In a
subsequent patch, the panic path will be refactored, then the
panic informational notifiers will effectively run earlier,
before ksmg_dump() (and usually before kdump as well).
We also defer documenting it all properly in the subsequent
refactor patch. Finally, while at it, we removed some useless
header inclusions too.
Cc: Benjamin Herrenschmidt
Cc: Catalin Marinas
Cc: Florian Fainelli
Cc: Frederic Weisbecker
Cc: "H. Peter Anvin"
Cc: Hari Bathini
Cc: Joel Fernandes
Cc: Jonathan Hunter
Cc: Josh Triplett
Cc: Lai Jiangshan
Cc: Leo Yan
Cc: Mathieu Desnoyers
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Mike Leach
Cc: Mikko Perttunen
Cc: Neeraj Upadhyay
Cc: Nicholas Piggin
Cc: Paul Mackerras
Cc: Suzuki K Poulose
Cc: Thierry Reding
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/arm64/kernel/setup.c | 2 +-
arch/mips/kernel/relocate.c | 2 +-
arch/powerpc/kernel/setup-common.c| 2 +-
arch/x86/kernel/setup.c | 2 +-
drivers/bus/brcmstb_gisb.c| 2 +-
drivers/hwtracing/coresight/coresight-cpu-debug.c | 4 ++--
drivers/soc/tegra/ari-tegra186.c | 3 ++-
include/linux/panic_notifier.h| 1 +
kernel/hung_task.c| 3 ++-
kernel/panic.c| 4
kernel/rcu/tree.c | 1 -
kernel/rcu/tree_stall.h | 3 ++-
kernel/trace/trace.c | 2 +-
13 files changed, 19 insertions(+), 12 deletions(-)
...
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 1874df7c6a73..7b1012454525 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -535,7 +535,7 @@ static int debug_func_init(void)
_func_knob_fops);
/* Register function to be called for panic */
- ret = atomic_notifier_chain_register(_notifier_list,
+ ret = atomic_notifier_chain_register(_info_list,
_notifier);
if (ret) {
pr_err("%s: unable to register notifier: %d\n",
@@ -552,7 +552,7 @@ static int debug_func_init(void)
static void debug_func_exit(void)
{
- atomic_notifier_chain_unregister(_notifier_list,
+ atomic_notifier_chain_unregister(_info_list,
_notifier);
debugfs_remove_recursive(debug_debugfs_dir);
}
Acked-by: Suzuki K Poulose
Re: [PATCH 3/4] mwait-idle: add 'preferred_cstates' module argument
On 28.04.2022 10:06, Roger Pau Monné wrote:
> On Thu, Apr 28, 2022 at 08:37:58AM +0200, Jan Beulich wrote:
>> On 27.04.2022 18:12, Roger Pau Monné wrote:
>>> On Wed, Apr 27, 2022 at 05:25:35PM +0200, Jan Beulich wrote:
On 27.04.2022 17:06, Roger Pau Monné wrote:
> On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
>> On 27.04.2022 14:45, Roger Pau Monné wrote:
>>> On Tue, Apr 26, 2022 at 12:05:28PM +0200, Jan Beulich wrote:
--- unstable.orig/xen/arch/x86/cpu/mwait-idle.c
+++ unstable/xen/arch/x86/cpu/mwait-idle.c
@@ -82,6 +82,18 @@ boolean_param("mwait-idle", opt_mwait_id
static unsigned int mwait_substates;
+/*
+ * Some platforms come with mutually exclusive C-states, so that if
one is
+ * enabled, the other C-states must not be used. Example: C1 and C1E
on
+ * Sapphire Rapids platform. This parameter allows for selecting the
+ * preferred C-states among the groups of mutually exclusive C-states
- the
+ * selected C-states will be registered, the other C-states from the
mutually
+ * exclusive group won't be registered. If the platform has no
mutually
+ * exclusive C-states, this parameter has no effect.
+ */
+static unsigned int __ro_after_init preferred_states_mask;
+integer_param("preferred-cstates", preferred_states_mask);
+
#define LAPIC_TIMER_ALWAYS_RELIABLE 0x
/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1.
*/
static unsigned int lapic_timer_reliable_states = (1 << 1);
@@ -96,6 +108,7 @@ struct idle_cpu {
unsigned long auto_demotion_disable_flags;
bool byt_auto_demotion_disable_flag;
bool disable_promotion_to_c1e;
+ bool enable_promotion_to_c1e;
>>>
>>> I'm confused by those fields, shouldn't we just have:
>>> promotion_to_c1e = true | false?
>>>
>>> As one field is the negation of the other:
>>> enable_promotion_to_c1e = !disable_promotion_to_c1e
>>>
>>> I know this is code from Linux, but would like to understand why two
>>> fields are needed.
>>
>> This really is a tristate; Linux is now changing their global variable
>> to an enum, but we don't have an equivalent of that global variable.
>
> So it would be: leave default, disable C1E promotion, enable C1E
> promotion.
>
> And Linux is leaving the {disable,enable}_promotion_to_c1e in
> idle_cpu?
Iirc they only have disable_promotion_to_c1e there (as a struct field)
and keep it, but they convert the similarly named file-scope variable
to a tristate.
> I guess there's not much we can do unless we want to diverge from
> upstream.
We've diverged some from Linux here already - as said, for example we
don't have their file-scope variable. I could convert our struct field
to an enum, but that would be larger code churn for (I think) little
gain.
>>>
>>> Hm, OK, could gaining the file scope variable would make sense in order
>>> to reduce divergences? Or are the other roadblocks there?
>>
>> I don't recall. It might have originated from a change I decided to not
>> port over, or I might have dropped it while porting. To be honest I'm
>> not keen on putting time into researching this, the more that I would
>> generally try to avoid static variables.
>>
>> What I would be willing to put time in is making a more user friendly
>> command line option, but as said - I can't think of any good alternative
>> (except perhaps "preferred-cstates=c1e" or "cstates=preferred:c1e", with
>> internal translation of the strings into a bit mask, as long as (a) you
>> would think that's an improvement and (b) the further divergence from
>> Linux is not deemed a problem).
>
> I think (b) won't be a problem as long as internally the user option
> is translated into a bitmask.
>
> Regarding (a) I do think it would be helpful to express this in a more
> user friendly way, I'm not sure whether it would make sense to keep
> Linux format also for compatibility reasons if users already have a
> bitmask and want to use the same parameter for Xen and Linux, ie:
>
> preferred-cstates = |
Yes, I would have been planning to accept both (but probably reject
mixing of both).
> What I think we should fix is the naming of the two booleans:
>
> bool disable_promotion_to_c1e;
> bool enable_promotion_to_c1e;
>
> I would rather translated this into an enum, as right now it's
> confusing IMO.
Okay, I can certainly do that. The more that I did consider doing
so already, breaking ties simply based on the "less code churn"
argument.
Jan
Re: [PATCH 3/4] mwait-idle: add 'preferred_cstates' module argument
On Thu, Apr 28, 2022 at 08:37:58AM +0200, Jan Beulich wrote:
> On 27.04.2022 18:12, Roger Pau Monné wrote:
> > On Wed, Apr 27, 2022 at 05:25:35PM +0200, Jan Beulich wrote:
> >> On 27.04.2022 17:06, Roger Pau Monné wrote:
> >>> On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
> On 27.04.2022 14:45, Roger Pau Monné wrote:
> > On Tue, Apr 26, 2022 at 12:05:28PM +0200, Jan Beulich wrote:
> >> --- unstable.orig/xen/arch/x86/cpu/mwait-idle.c
> >> +++ unstable/xen/arch/x86/cpu/mwait-idle.c
> >> @@ -82,6 +82,18 @@ boolean_param("mwait-idle", opt_mwait_id
> >>
> >> static unsigned int mwait_substates;
> >>
> >> +/*
> >> + * Some platforms come with mutually exclusive C-states, so that if
> >> one is
> >> + * enabled, the other C-states must not be used. Example: C1 and C1E
> >> on
> >> + * Sapphire Rapids platform. This parameter allows for selecting the
> >> + * preferred C-states among the groups of mutually exclusive C-states
> >> - the
> >> + * selected C-states will be registered, the other C-states from the
> >> mutually
> >> + * exclusive group won't be registered. If the platform has no
> >> mutually
> >> + * exclusive C-states, this parameter has no effect.
> >> + */
> >> +static unsigned int __ro_after_init preferred_states_mask;
> >> +integer_param("preferred-cstates", preferred_states_mask);
> >> +
> >> #define LAPIC_TIMER_ALWAYS_RELIABLE 0x
> >> /* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1.
> >> */
> >> static unsigned int lapic_timer_reliable_states = (1 << 1);
> >> @@ -96,6 +108,7 @@ struct idle_cpu {
> >>unsigned long auto_demotion_disable_flags;
> >>bool byt_auto_demotion_disable_flag;
> >>bool disable_promotion_to_c1e;
> >> + bool enable_promotion_to_c1e;
> >
> > I'm confused by those fields, shouldn't we just have:
> > promotion_to_c1e = true | false?
> >
> > As one field is the negation of the other:
> > enable_promotion_to_c1e = !disable_promotion_to_c1e
> >
> > I know this is code from Linux, but would like to understand why two
> > fields are needed.
>
> This really is a tristate; Linux is now changing their global variable
> to an enum, but we don't have an equivalent of that global variable.
> >>>
> >>> So it would be: leave default, disable C1E promotion, enable C1E
> >>> promotion.
> >>>
> >>> And Linux is leaving the {disable,enable}_promotion_to_c1e in
> >>> idle_cpu?
> >>
> >> Iirc they only have disable_promotion_to_c1e there (as a struct field)
> >> and keep it, but they convert the similarly named file-scope variable
> >> to a tristate.
> >>
> >>> I guess there's not much we can do unless we want to diverge from
> >>> upstream.
> >>
> >> We've diverged some from Linux here already - as said, for example we
> >> don't have their file-scope variable. I could convert our struct field
> >> to an enum, but that would be larger code churn for (I think) little
> >> gain.
> >
> > Hm, OK, could gaining the file scope variable would make sense in order
> > to reduce divergences? Or are the other roadblocks there?
>
> I don't recall. It might have originated from a change I decided to not
> port over, or I might have dropped it while porting. To be honest I'm
> not keen on putting time into researching this, the more that I would
> generally try to avoid static variables.
>
> What I would be willing to put time in is making a more user friendly
> command line option, but as said - I can't think of any good alternative
> (except perhaps "preferred-cstates=c1e" or "cstates=preferred:c1e", with
> internal translation of the strings into a bit mask, as long as (a) you
> would think that's an improvement and (b) the further divergence from
> Linux is not deemed a problem).
I think (b) won't be a problem as long as internally the user option
is translated into a bitmask.
Regarding (a) I do think it would be helpful to express this in a more
user friendly way, I'm not sure whether it would make sense to keep
Linux format also for compatibility reasons if users already have a
bitmask and want to use the same parameter for Xen and Linux, ie:
preferred-cstates = |
What I think we should fix is the naming of the two booleans:
bool disable_promotion_to_c1e;
bool enable_promotion_to_c1e;
I would rather translated this into an enum, as right now it's
confusing IMO.
Thanks, Roger.
Re: [PATCH v2 1/2] PCI: replace stray uses of PCI_{DEVFN,BDF}2()
On 21.04.2022 16:26, Jan Beulich wrote: > There's no good reason to use these when we already have a pci_sbdf_t > type object available. This extends to the use of PCI_BUS() in > pci_ecam_map_bus() as well. > > No change to generated code (with gcc11 at least, and I have to admit > that I didn't expect compilers to necessarily be able to spot the > optimization potential on the original code). > > Signed-off-by: Jan Beulich > Reviewed-by: Roger Pau Monné > Reviewed-by: Kevin Tian > --- > Note that the Arm changes are "blind": I haven't been able to spot a way > to at least compile test the changes there; the code looks to be > entirely dead. > --- > v2: Arm build fix (for those who actually have ways to build the Arm > code being changed here). May I please get an Arm side ack (or otherwise) here? Especially the 2nd, dependent patch better wouldn't remain pending for too long, or else there's a fair risk for it to go stale. Thanks, Jan > --- a/xen/arch/arm/pci/ecam.c > +++ b/xen/arch/arm/pci/ecam.c > @@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc > container_of(bridge->ops, const struct pci_ecam_ops, pci_ops); > unsigned int devfn_shift = ops->bus_shift - 8; > void __iomem *base; > - > -unsigned int busn = PCI_BUS(sbdf.bdf); > +unsigned int busn = sbdf.bus; > > if ( busn < cfg->busn_start || busn > cfg->busn_end ) > return NULL; > @@ -37,7 +36,7 @@ void __iomem *pci_ecam_map_bus(struct pc > busn -= cfg->busn_start; > base = cfg->win + (busn << ops->bus_shift); > > -return base + (PCI_DEVFN2(sbdf.bdf) << devfn_shift) + where; > +return base + (sbdf.devfn << devfn_shift) + where; > } > > bool __init pci_ecam_need_p2m_hwdom_mapping(struct domain *d, > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -839,7 +839,7 @@ static int msix_capability_init(struct p > pbus = dev->info.physfn.bus; > pslot = PCI_SLOT(dev->info.physfn.devfn); > pfunc = PCI_FUNC(dev->info.physfn.devfn); > -vf = PCI_BDF2(dev->bus, dev->devfn); > +vf = dev->sbdf.bdf; > } > > table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf); > --- a/xen/drivers/passthrough/vtd/qinval.c > +++ b/xen/drivers/passthrough/vtd/qinval.c > @@ -267,7 +267,7 @@ int qinval_device_iotlb_sync(struct vtd_ > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_1 = 0; > qinval_entry->q.dev_iotlb_inv_dsc.lo.max_invs_pend = > pdev->ats.queue_depth; > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_2 = 0; > -qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = PCI_BDF2(pdev->bus, > pdev->devfn); > +qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = pdev->sbdf.bdf; > qinval_entry->q.dev_iotlb_inv_dsc.lo.res_3 = 0; > > qinval_entry->q.dev_iotlb_inv_dsc.hi.size = size; > >
Re: [PATCH] x86/msr: handle reads to MSR_P5_MC_ADDR
On 27.04.2022 17:47, Roger Pau Monne wrote:
> I've added it for CENTAUR and SHANGHAI because the MSR is there since
> Pentium, so likely to be implemented by those vendors also, but have
> no way to check.
I think that's fine.
> I wonder how long it will take for Windows to also start poking at
> MSR_IA32_MC0_ADDR or other MCE related registers. For now this seems
> to be enough.
Those are handled by vmce_{rd,wr}msr(), aren't they? As a result I
wonder whether the MSR in question as well as its companion
P5_MC_TYPE wouldn't better also be handled (faked) there. (Even if
not, I don't think we should handle ADDR by not TYPE.)
Jan
[PATCH v2 3/4] xen/scsifront: use new command result macros
Add a translation layer for the command result values.
Signed-off-by: Juergen Gross
---
drivers/scsi/xen-scsifront.c | 64 +++-
1 file changed, 56 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 12109e4c73d4..8511bfc62963 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -243,6 +243,56 @@ static void scsifront_gnttab_done(struct vscsifrnt_info
*info,
kfree(shadow->sg);
}
+static unsigned int scsifront_host_byte(int32_t rslt)
+{
+ switch (XEN_VSCSIIF_RSLT_HOST(rslt)) {
+ case XEN_VSCSIIF_RSLT_HOST_OK:
+ return DID_OK;
+ case XEN_VSCSIIF_RSLT_HOST_NO_CONNECT:
+ return DID_NO_CONNECT;
+ case XEN_VSCSIIF_RSLT_HOST_BUS_BUSY:
+ return DID_BUS_BUSY;
+ case XEN_VSCSIIF_RSLT_HOST_TIME_OUT:
+ return DID_TIME_OUT;
+ case XEN_VSCSIIF_RSLT_HOST_BAD_TARGET:
+ return DID_BAD_TARGET;
+ case XEN_VSCSIIF_RSLT_HOST_ABORT:
+ return DID_ABORT;
+ case XEN_VSCSIIF_RSLT_HOST_PARITY:
+ return DID_PARITY;
+ case XEN_VSCSIIF_RSLT_HOST_ERROR:
+ return DID_ERROR;
+ case XEN_VSCSIIF_RSLT_HOST_RESET:
+ return DID_RESET;
+ case XEN_VSCSIIF_RSLT_HOST_BAD_INTR:
+ return DID_BAD_INTR;
+ case XEN_VSCSIIF_RSLT_HOST_PASSTHROUGH:
+ return DID_PASSTHROUGH;
+ case XEN_VSCSIIF_RSLT_HOST_SOFT_ERROR:
+ return DID_SOFT_ERROR;
+ case XEN_VSCSIIF_RSLT_HOST_IMM_RETRY:
+ return DID_IMM_RETRY;
+ case XEN_VSCSIIF_RSLT_HOST_REQUEUE:
+ return DID_REQUEUE;
+ case XEN_VSCSIIF_RSLT_HOST_TRANSPORT_DISRUPTED:
+ return DID_TRANSPORT_DISRUPTED;
+ case XEN_VSCSIIF_RSLT_HOST_TRANSPORT_FAILFAST:
+ return DID_TRANSPORT_FAILFAST;
+ case XEN_VSCSIIF_RSLT_HOST_TARGET_FAILURE:
+ return DID_TARGET_FAILURE;
+ case XEN_VSCSIIF_RSLT_HOST_NEXUS_FAILURE:
+ return DID_NEXUS_FAILURE;
+ case XEN_VSCSIIF_RSLT_HOST_ALLOC_FAILURE:
+ return DID_ALLOC_FAILURE;
+ case XEN_VSCSIIF_RSLT_HOST_MEDIUM_ERROR:
+ return DID_MEDIUM_ERROR;
+ case XEN_VSCSIIF_RSLT_HOST_TRANSPORT_MARGINAL:
+ return DID_TRANSPORT_MARGINAL;
+ default:
+ return DID_ERROR;
+ }
+}
+
static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
struct vscsiif_response *ring_rsp)
{
@@ -250,7 +300,6 @@ static void scsifront_cdb_cmd_done(struct vscsifrnt_info
*info,
struct scsi_cmnd *sc;
uint32_t id;
uint8_t sense_len;
- int result;
id = ring_rsp->rqid;
shadow = info->shadow[id];
@@ -261,12 +310,8 @@ static void scsifront_cdb_cmd_done(struct vscsifrnt_info
*info,
scsifront_gnttab_done(info, shadow);
scsifront_put_rqid(info, id);
- result = ring_rsp->rslt;
- if (result >> 24)
- set_host_byte(sc, DID_ERROR);
- else
- set_host_byte(sc, host_byte(result));
- set_status_byte(sc, result & 0xff);
+ set_host_byte(sc, scsifront_host_byte(ring_rsp->rslt));
+ set_status_byte(sc, XEN_VSCSIIF_RSLT_STATUS(ring_rsp->rslt));
scsi_set_resid(sc, ring_rsp->residual_len);
sense_len = min_t(uint8_t, VSCSIIF_SENSE_BUFFERSIZE,
@@ -290,7 +335,10 @@ static void scsifront_sync_cmd_done(struct vscsifrnt_info
*info,
shadow->wait_reset = 1;
switch (shadow->rslt_reset) {
case RSLT_RESET_WAITING:
- shadow->rslt_reset = ring_rsp->rslt;
+ if (ring_rsp->rslt == XEN_VSCSIIF_RSLT_RESET_SUCCESS)
+ shadow->rslt_reset = SUCCESS;
+ else
+ shadow->rslt_reset = FAILED;
break;
case RSLT_RESET_ERR:
kick = _scsifront_put_rqid(info, id);
--
2.34.1
[PATCH v2 4/4] xen/scsifront: harden driver against malicious backend
Instead of relying on a well behaved PV scsi backend verify all meta
data received from the backend and avoid multiple reads of the same
data from the shared ring page.
In case any illegal data from the backend is detected switch the
PV device to a new "error" state and deactivate it for further use.
Use the "lateeoi" variant for the event channel in order to avoid
event storms blocking the guest.
Signed-off-by: Juergen Gross
---
V2:
- only remove spurious flag from eoiflag (Boris Ostrovsky)
---
drivers/scsi/xen-scsifront.c | 104 +--
1 file changed, 76 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 8511bfc62963..56173beecbc6 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -83,6 +83,8 @@ struct vscsifrnt_shadow {
uint16_t rqid;
uint16_t ref_rqid;
+ bool inflight;
+
unsigned int nr_grants; /* number of grants in gref[] */
struct scsiif_request_segment *sg; /* scatter/gather elements */
struct scsiif_request_segment seg[VSCSIIF_SG_TABLESIZE];
@@ -104,7 +106,11 @@ struct vscsifrnt_info {
struct xenbus_device *dev;
struct Scsi_Host *host;
- int host_active;
+ enum {
+ STATE_INACTIVE,
+ STATE_ACTIVE,
+ STATE_ERROR
+ } host_active;
unsigned int evtchn;
unsigned int irq;
@@ -217,6 +223,8 @@ static int scsifront_do_request(struct vscsifrnt_info *info,
for (i = 0; i < (shadow->nr_segments & ~VSCSIIF_SG_GRANT); i++)
ring_req->seg[i] = shadow->seg[i];
+ shadow->inflight = true;
+
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
if (notify)
notify_remote_via_irq(info->irq);
@@ -224,6 +232,13 @@ static int scsifront_do_request(struct vscsifrnt_info
*info,
return 0;
}
+static void scsifront_set_error(struct vscsifrnt_info *info, const char *msg)
+{
+ shost_printk(KERN_ERR, info->host, KBUILD_MODNAME "%s\n"
+"Disabling device for further use\n", msg);
+ info->host_active = STATE_ERROR;
+}
+
static void scsifront_gnttab_done(struct vscsifrnt_info *info,
struct vscsifrnt_shadow *shadow)
{
@@ -234,9 +249,8 @@ static void scsifront_gnttab_done(struct vscsifrnt_info
*info,
for (i = 0; i < shadow->nr_grants; i++) {
if (unlikely(!gnttab_try_end_foreign_access(shadow->gref[i]))) {
- shost_printk(KERN_ALERT, info->host, KBUILD_MODNAME
-"grant still in use by backend\n");
- BUG();
+ scsifront_set_error(info, "grant still in use by
backend");
+ return;
}
}
@@ -308,6 +322,8 @@ static void scsifront_cdb_cmd_done(struct vscsifrnt_info
*info,
BUG_ON(sc == NULL);
scsifront_gnttab_done(info, shadow);
+ if (info->host_active == STATE_ERROR)
+ return;
scsifront_put_rqid(info, id);
set_host_byte(sc, scsifront_host_byte(ring_rsp->rslt));
@@ -348,9 +364,7 @@ static void scsifront_sync_cmd_done(struct vscsifrnt_info
*info,
scsifront_wake_up(info);
return;
default:
- shost_printk(KERN_ERR, info->host, KBUILD_MODNAME
-"bad reset state %d, possibly leaking %u\n",
-shadow->rslt_reset, id);
+ scsifront_set_error(info, "bad reset state");
break;
}
spin_unlock_irqrestore(>shadow_lock, flags);
@@ -361,28 +375,41 @@ static void scsifront_sync_cmd_done(struct vscsifrnt_info
*info,
static void scsifront_do_response(struct vscsifrnt_info *info,
struct vscsiif_response *ring_rsp)
{
- if (WARN(ring_rsp->rqid >= VSCSIIF_MAX_REQS ||
-test_bit(ring_rsp->rqid, info->shadow_free_bitmap),
-"illegal rqid %u returned by backend!\n", ring_rsp->rqid))
+ struct vscsifrnt_shadow *shadow;
+
+ if (ring_rsp->rqid >= VSCSIIF_MAX_REQS ||
+ !info->shadow[ring_rsp->rqid]->inflight) {
+ scsifront_set_error(info, "illegal rqid returned by backend!");
return;
+ }
+ shadow = info->shadow[ring_rsp->rqid];
+ shadow->inflight = false;
- if (info->shadow[ring_rsp->rqid]->act == VSCSIIF_ACT_SCSI_CDB)
+ if (shadow->act == VSCSIIF_ACT_SCSI_CDB)
scsifront_cdb_cmd_done(info, ring_rsp);
else
scsifront_sync_cmd_done(info, ring_rsp);
}
-static int scsifront_ring_drain(struct vscsifrnt_info *info)
+static int scsifront_ring_drain(struct vscsifrnt_info *info,
+ unsigned int *eoiflag)
{
- struct vscsiif_response *ring_rsp;
+ struct
[PATCH v2 2/4] xen/scsiback: use new command result macros
Instead of using the kernel's values for the result of PV scsi
operations use the values of the interface definition.
Signed-off-by: Juergen Gross
---
V2:
- fix scsiback_result() to pass through lowest 16 bits of result
- use XEN_VSCSIIF_RSLT_HOST() instead of open coding it (Boris Ostrovsky)
---
drivers/xen/xen-scsiback.c | 82 --
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 0c5e565aa8cf..7a0c93acc2c5 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -280,6 +280,82 @@ static void scsiback_free_translation_entry(struct kref
*kref)
kfree(entry);
}
+static int32_t scsiback_result(int32_t result)
+{
+ int32_t host_status;
+
+ switch (XEN_VSCSIIF_RSLT_HOST(result)) {
+ case DID_OK:
+ host_status = XEN_VSCSIIF_RSLT_HOST_OK;
+ break;
+ case DID_NO_CONNECT:
+ host_status = XEN_VSCSIIF_RSLT_HOST_NO_CONNECT;
+ break;
+ case DID_BUS_BUSY:
+ host_status = XEN_VSCSIIF_RSLT_HOST_BUS_BUSY;
+ break;
+ case DID_TIME_OUT:
+ host_status = XEN_VSCSIIF_RSLT_HOST_TIME_OUT;
+ break;
+ case DID_BAD_TARGET:
+ host_status = XEN_VSCSIIF_RSLT_HOST_BAD_TARGET;
+ break;
+ case DID_ABORT:
+ host_status = XEN_VSCSIIF_RSLT_HOST_ABORT;
+ break;
+ case DID_PARITY:
+ host_status = XEN_VSCSIIF_RSLT_HOST_PARITY;
+ break;
+ case DID_ERROR:
+ host_status = XEN_VSCSIIF_RSLT_HOST_ERROR;
+ break;
+ case DID_RESET:
+ host_status = XEN_VSCSIIF_RSLT_HOST_RESET;
+ break;
+ case DID_BAD_INTR:
+ host_status = XEN_VSCSIIF_RSLT_HOST_BAD_INTR;
+ break;
+ case DID_PASSTHROUGH:
+ host_status = XEN_VSCSIIF_RSLT_HOST_PASSTHROUGH;
+ break;
+ case DID_SOFT_ERROR:
+ host_status = XEN_VSCSIIF_RSLT_HOST_SOFT_ERROR;
+ break;
+ case DID_IMM_RETRY:
+ host_status = XEN_VSCSIIF_RSLT_HOST_IMM_RETRY;
+ break;
+ case DID_REQUEUE:
+ host_status = XEN_VSCSIIF_RSLT_HOST_REQUEUE;
+ break;
+ case DID_TRANSPORT_DISRUPTED:
+ host_status = XEN_VSCSIIF_RSLT_HOST_TRANSPORT_DISRUPTED;
+ break;
+ case DID_TRANSPORT_FAILFAST:
+ host_status = XEN_VSCSIIF_RSLT_HOST_TRANSPORT_FAILFAST;
+ break;
+ case DID_TARGET_FAILURE:
+ host_status = XEN_VSCSIIF_RSLT_HOST_TARGET_FAILURE;
+ break;
+ case DID_NEXUS_FAILURE:
+ host_status = XEN_VSCSIIF_RSLT_HOST_NEXUS_FAILURE;
+ break;
+ case DID_ALLOC_FAILURE:
+ host_status = XEN_VSCSIIF_RSLT_HOST_ALLOC_FAILURE;
+ break;
+ case DID_MEDIUM_ERROR:
+ host_status = XEN_VSCSIIF_RSLT_HOST_MEDIUM_ERROR;
+ break;
+ case DID_TRANSPORT_MARGINAL:
+ host_status = XEN_VSCSIIF_RSLT_HOST_TRANSPORT_MARGINAL;
+ break;
+ default:
+ host_status = XEN_VSCSIIF_RSLT_HOST_ERROR;
+ break;
+ }
+
+ return (host_status << 16) | (result & 0x00);
+}
+
static void scsiback_send_response(struct vscsibk_info *info,
char *sense_buffer, int32_t result, uint32_t resid,
uint16_t rqid)
@@ -295,7 +371,7 @@ static void scsiback_send_response(struct vscsibk_info
*info,
ring_res = RING_GET_RESPONSE(>ring, info->ring.rsp_prod_pvt);
info->ring.rsp_prod_pvt++;
- ring_res->rslt = result;
+ ring_res->rslt = scsiback_result(result);
ring_res->rqid = rqid;
if (sense_buffer != NULL &&
@@ -555,7 +631,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
struct scsiback_nexus *nexus = tpg->tpg_nexus;
struct se_cmd *se_cmd = _req->se_cmd;
u64 unpacked_lun = pending_req->v2p->lun;
- int rc, err = FAILED;
+ int rc, err = XEN_VSCSIIF_RSLT_RESET_FAILED;
init_completion(_req->tmr_done);
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(_req->tmr_done);
err = (se_cmd->se_tmr_req->response == TMR_FUNCTION_COMPLETE) ?
- SUCCESS : FAILED;
+ XEN_VSCSIIF_RSLT_RESET_SUCCESS : XEN_VSCSIIF_RSLT_RESET_FAILED;
scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
transport_generic_free_cmd(_req->se_cmd, 0);
--
2.34.1
