[ovmf test] 170019: regressions - FAIL

[osstest service owner]

flight 170019 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170019/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  772 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[ovmf test] 170017: regressions - FAIL

[osstest service owner]

flight 170017 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170017/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  771 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[ovmf test] 170013: regressions - FAIL

[osstest service owner]

flight 170013 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170013/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  770 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

Re: [LINUX PATCH v3] xen: add support for initializing xenstore later as HVM domain

[Boris Ostrovsky]

On 5/2/22 8:36 PM, Stefano Stabellini wrote:


I gave it a try and there is a problem with unbinding the IRQ here. If I
do that, later when xb_init_comms calls bind_evtchn_to_irqhandler, the
event channel doesn't fire anymore. I did some testing and debugging and
as far as I can tell the issue is that if we call unbind_from_irqhandler
here, we end up calling xen_evtchn_close. Then, when xb_init_comms calls
bind_evtchn_to_irqhandler on the same evtchn, it is not enough to
receive event notifications anymore because from Xen POV the evtchn is
"closed".



Ah, yes. That's unfortunate.




If I comment out xen_evtchn_close() in __unbind_from_irq, then yes, I
can call unbind_from_irqhandler here instead of free_irq and everything
works.

My suggestion is to keep the call to free_irq here (not
unbind_from_irqhandler) and improve the in-code comment.



OK.


You could add an argument to unbind_from_irq() to keep the event channel open 
(I in fact am not sure it should be closing the channel since bind routines 
don't open it) but that looks pretty ugly too.


-boris

[ovmf test] 170010: regressions - FAIL

[osstest service owner]

flight 170010 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170010/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  769 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[linux-linus test] 170001: tolerable FAIL - PUSHED

[osstest service owner]

flight 170001 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170001/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169977
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169977
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169977
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169977
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169977
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169977
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169977
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169977
 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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-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-rtds 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-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

version targeted for testing:
 linux9050ba3a61a4b5bd84c2cde092a100404f814f31
baseline version:
 linux672c0c5173427e6b3e2a9bbb7be51ceeec78093a

Last test of basis   169977  2022-05-02 01:56:06 Z0 days
Testing same since   170001  2022-05-02 19:09:59 Z0 days1 attempts


People who touched revisions under test:
  Chung-Chiang Cheng 
  David Sterba 
  Filipe Manana 
  Linus Torvalds 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64 

Re: [LINUX PATCH v3] xen: add support for initializing xenstore later as HVM domain

[Stefano Stabellini]

On Fri, 29 Apr 2022, Boris Ostrovsky wrote:
> On 4/29/22 5:10 PM, Stefano Stabellini wrote:
> > From: Luca Miccio 
> > 
> > When running as dom0less guest (HVM domain on ARM) the xenstore event
> > channel is available at domain creation but the shared xenstore
> > interface page only becomes available later on.
> > 
> > In that case, wait for a notification on the xenstore event channel,
> > then complete the xenstore initialization later, when the shared page
> > is actually available.
> > 
> > The xenstore page has few extra field. Add them to the shared struct.
> > One of the field is "connection", when the connection is ready, it is
> > zero. If the connection is not-zero, wait for a notification.
> > 
> > Signed-off-by: Luca Miccio 
> > Signed-off-by: Stefano Stabellini 
> > CC: jgr...@suse.com
> > CC: boris.ostrov...@oracle.com
> > ---
> > Changes in v3:
> > - check for the connection field, if it is not zero, wait for event
> > 
> > Changes in v2:
> > - remove XENFEAT_xenstore_late_init
> > ---
> >   drivers/xen/xenbus/xenbus_probe.c  | 86 +++---
> >   include/xen/interface/io/xs_wire.h |  3 ++
> >   2 files changed, 70 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c
> > b/drivers/xen/xenbus/xenbus_probe.c
> > index fe360c33ce71..dc046d25789e 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -65,6 +65,7 @@
> >   #include "xenbus.h"
> > +static int xs_init_irq;
> >   int xen_store_evtchn;
> >   EXPORT_SYMBOL_GPL(xen_store_evtchn);
> >   @@ -750,6 +751,17 @@ static void xenbus_probe(void)
> >   {
> > xenstored_ready = 1;
> >   + if (!xen_store_interface) {
> > +   xen_store_interface = xen_remap(xen_store_gfn <<
> > XEN_PAGE_SHIFT,
> > +   XEN_PAGE_SIZE);
> > +   /*
> > +* Now it is safe to free the IRQ used for xenstore late
> > +* initialization. No need to unbind: it is about to be
> > +* bound again.
> 
> 
> This assumes knowledge of bind/unbind internals. I think we should unbind.

I gave it a try and there is a problem with unbinding the IRQ here. If I
do that, later when xb_init_comms calls bind_evtchn_to_irqhandler, the
event channel doesn't fire anymore. I did some testing and debugging and
as far as I can tell the issue is that if we call unbind_from_irqhandler
here, we end up calling xen_evtchn_close. Then, when xb_init_comms calls
bind_evtchn_to_irqhandler on the same evtchn, it is not enough to
receive event notifications anymore because from Xen POV the evtchn is
"closed".

If I comment out xen_evtchn_close() in __unbind_from_irq, then yes, I
can call unbind_from_irqhandler here instead of free_irq and everything
works.

My suggestion is to keep the call to free_irq here (not
unbind_from_irqhandler) and improve the in-code comment.

 
> > +*/
> > +   free_irq(xs_init_irq, &xb_waitq);
> > +   }
> > +
> 
> 
> 
> > @@ -959,23 +988,42 @@ static int __init xenbus_init(void)
> >  *
> >  * Also recognize all bits set as an invalid value.
> 
> 
> Is this comment still correct?

I can improve the comment

 
> >  */
> > -   if (!v || !~v) {
> > +   if (!v) {
> > err = -ENOENT;
> > goto out_error;
> > }
> > -   /* Avoid truncation on 32-bit. */
> > +   if (v == ~0ULL) {
> > +   wait = true;
> > +   } else {
> > +   /* Avoid truncation on 32-bit. */

[ovmf test] 170006: regressions - FAIL

[osstest service owner]

flight 170006 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170006/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  768 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[ovmf test] 170005: regressions - FAIL

[osstest service owner]

flight 170005 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170005/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  767 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops

[Rob Herring]

On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko 
> 
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
> 
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the grant mapping APIs.
> 
> This is needed for the option to restrict memory access using Xen grant
> mappings to work which primary goal is to enable using virtio devices
> in Xen guests.
> 
> Signed-off-by: Oleksandr Tyshchenko 
> ---
> Changes RFC -> V1:
>- update commit subject/description and text in description
>- move to devicetree/bindings/arm/
> ---
>  .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml 
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index ..ef0f747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for the virtualized device (e.g. virtio)
> +
> +maintainers:
> +  - Oleksandr Tyshchenko 
> +
> +select: true

Do we really need to support this property everywhere?

> +
> +description:
> +  This binding indicates that Xen grant mappings scheme needs to be enabled
> +  for that device and specifies the ID of Xen domain where the corresponding
> +  device (backend) resides. This is needed for the option to restrict memory
> +  access using Xen grant mappings to work.
> +
> +properties:
> +  xen,dev-domid:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description:
> +  The domid (domain ID) of the domain where the device (backend) is 
> running.
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +virtio_block@3000 {

virtio@3000

> +compatible = "virtio,mmio";
> +reg = <0x3000 0x100>;
> +interrupts = <41>;
> +
> +/* The device is located in Xen domain with ID 1 */
> +xen,dev-domid = <1>;

This fails validation:

Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: 
virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
From schema: 
/home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml

The property has to be added to the virtio/mmio.yaml schema. If it is 
not needed elsewhere, then *just* add the property there.

Rob

[ovmf test] 170004: regressions - FAIL

[osstest service owner]

flight 170004 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170004/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  766 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[ovmf test] 170003: regressions - FAIL

[osstest service owner]

flight 170003 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170003/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  765 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[xen-unstable test] 169990: tolerable FAIL - PUSHED

[osstest service owner]

flight 169990 xen-unstable real [real]
flight 170002 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169990/
http://logs.test-lab.xenproject.org/osstest/logs/170002/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail pass 
in 170002-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169976
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169976
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169976
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169976
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169976
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169976
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169976
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169976
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169976
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169976
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169976
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169976
 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-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-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-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-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-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-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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-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  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-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-check 

[ANNOUNCE] Call for agenda items for May Community Call @ 1500 UTC

[George Dunlap]

Hi all,

The proposed agenda is in 
https://cryptpad.fr/pad/#/2/pad/edit/UNa6xVJgZtDsmscu8r3PmsUI/ and you can edit 
to add items.  Alternatively, you can reply to this mail directly.

Agenda items appreciated a few days before the call: please put your name 
besides items if you edit the document.

Note the following administrative conventions for the call:
* Unless, agreed in the pervious meeting otherwise, the call is on the 1st 
Thursday of each month at 1600 British Time (either GMT or BST)
* I usually send out a meeting reminder a few days before with a provisional 
agenda

* To allow time to switch between meetings, we'll plan on starting the agenda 
at 16:05 sharp.  Aim to join by 16:03 if possible to allocate time to sort out 
technical difficulties &c

* If you want to be CC'ed please add or remove yourself from the sign-up-sheet 
at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

Best Regards
George



== Dial-in Information ==
## Meeting time
15:00 - 16:00 UTC
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=05&day=5&hour=15&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179


## Dial in details
Web: https://meet.jit.si/XenProjectCommunityCall

Dial-in info and pin can be found here:

https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall

[ovmf test] 170000: regressions - FAIL

[osstest service owner]

flight 17 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/17/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  764 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

[ovmf test] 169999: regressions - FAIL

[osstest service owner]

flight 16 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/16/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 4092f1d3977d290bf7fbcaa1ff55784c080f136f
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  763 attempts
Testing same since   16  2022-05-02 17:12:56 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 
  Corvin Köhne 
  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 
  Jiewen Yao 
  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 
  Peter Grehan 
  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 5871 lines long.)

Re: fix and cleanup discard_alignment handling

[Christoph Hellwig]

ping?

[ovmf test] 169998: regressions - FAIL

[osstest service owner]

flight 169998 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169998/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  762 attempts
Testing same since   169904  2022-04-30 08:10:33 Z2 days   54 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 5855 lines long.)

Re: [PATCH 15/30] bus: brcmstb_gisb: Clean-up panic/die notifiers

[Guilherme G. Piccoli]

On 02/05/2022 12:38, Florian Fainelli wrote:
> [...] 
> 
> Acked-by: Florian Fainelli 
> 
> Not sure if the Fixes tag is warranted however as this is a clean up, 
> and not really fixing a bug.

Perfect, thanks Florian. I'll add your ACK and remove the fixes tag in V2.
Cheers,


Guilherme

Re: [PATCH 06/30] soc: bcm: brcmstb: Document panic notifier action and remove useless header

[Guilherme G. Piccoli]

On 02/05/2022 12:38, Florian Fainelli wrote:
> [...] 
> Acked-by: Florian Fainelli 
> 
> Likewise, I am not sure if the Fixes tag is necessary here.

Perfect Florian, thanks!  I'll add your Acked-by tag and remove the
fixes for V2 =)
Cheers,


Guilherme

[ovmf test] 169995: regressions - FAIL

[osstest service owner]

flight 169995 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169995/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  761 attempts
Testing same since   169904  2022-04-30 08:10:33 Z2 days   53 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 5855 lines long.)

Re: [PATCH 06/30] soc: bcm: brcmstb: Document panic notifier action and remove useless header

[Florian Fainelli]

On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:

The panic notifier of this driver is very simple code-wise, just a memory
write to a special position with some numeric code. But this is not clear
from the semantic point-of-view, and there is no public documentation
about that either.

After discussing this in the mailing-lists [0] and having Florian explained
it very well, this patch just document that in the code for the future
generations asking the same questions. Also, it removes a useless header.

[0] https://lore.kernel.org/lkml/781cafb0-8d06-8b56-907a-5175c2da1...@gmail.com

Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states 
(ARM)")
Cc: Brian Norris 
Cc: Doug Berger 
Cc: Florian Fainelli 
Cc: Justin Chen 
Cc: Lee Jones 
Cc: Markus Mayer 
Signed-off-by: Guilherme G. Piccoli 


Acked-by: Florian Fainelli 

Likewise, I am not sure if the Fixes tag is necessary here.
--
Florian

Re: [PATCH 15/30] bus: brcmstb_gisb: Clean-up panic/die notifiers

[Florian Fainelli]

On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:

This patch improves the panic/die notifiers in this driver by
making use of a passed "id" instead of comparing pointer
address; also, it removes an useless prototype declaration
and unnecessary header inclusion.

This is part of a panic notifiers refactor - this notifier in
the future will be moved to a new list, that encompass the
information notifiers only.

Fixes: 9eb60880d9a9 ("bus: brcmstb_gisb: add notifier handling")
Cc: Brian Norris 
Cc: Florian Fainelli 
Signed-off-by: Guilherme G. Piccoli 


Acked-by: Florian Fainelli 

Not sure if the Fixes tag is warranted however as this is a clean up, 
and not really fixing a bug.

--
Florian

[PATCH RFC] x86/lld: fix symbol map generation

[Roger Pau Monne]

The symbol map generation (and thus the debug info attached to Xen) is
partially broken when using LLVM LD.  That's due to LLD converting
almost all symbols from global to local in the last linking step, and
thus confusing tools/symbols into adding a file prefix to all text
symbols, the results looks like:

Xen call trace:
   [] R xxhash64.c#__start_xen+0x3938/0x39c0
   [] F __high_start+0x94/0xa0

In order to workaround this create a list of global symbols prior to
the linking step, and use objcopy to convert the symbols in the final
binary back to global before processing with tools/symbols.

Signed-off-by: Roger Pau Monné 
---
I haven't found a way to prevent LLD from converting the symbols, so
I've come up with this rather crappy workaround.

Not applied to EFI, partially because I don't have an environment with
LLD capable of generating the EFI binary.

Obtaining the global symbol list could likely be a target on itself,
if it is to be shared between the ELF and the EFI binary generation.
---
 xen/arch/x86/Makefile | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 177a2ff742..f3817827bc 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -134,24 +134,34 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
+   # Dump global text symbols before the linking step
+   $(NM) -pa --format=bsd $< | awk '{ if($$2 == "T") print $$3}' \
+   > $(@D)/.$(@F).global-syms
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
-   $(objtree)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+   $(objtree)/common/symbols-dummy.o -o $(@D)/.$(@F).0.tmp
+   # LLVM LD has converted global symbols into local ones as part of the
+   # linking step, convert those back to global before using tools/symbols.
+   $(OBJCOPY) --globalize-symbols=$(@D)/.$(@F).global-syms \
+   $(@D)/.$(@F).0.tmp $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>$(@D)/.$(@F).0.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).0.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
-   $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+   $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1.tmp
+   $(OBJCOPY) --globalize-symbols=$(@D)/.$(@F).global-syms \
+   $(@D)/.$(@F).1.tmp $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(objtree)/tools/symbols $(all_symbols) --sysv --sort 
$(syms-warn-dup-y) \
>$(@D)/.$(@F).1.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
-   $(orphan-handling-y) $(@D)/.$(@F).1.o -o $@
+   $(orphan-handling-y) $(@D)/.$(@F).1.o -o $@.tmp
+   $(OBJCOPY) --globalize-symbols=$(@D)/.$(@F).global-syms $@.tmp $@
$(NM) -pa --format=sysv $(@D)/$(@F) \
| $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
>$(@D)/$(@F).map
-   rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]*
+   rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]* $(@D)/.$(@F).global-syms
 ifeq ($(CONFIG_XEN_IBT),y)
$(SHELL) $(srctree)/tools/check-endbr.sh $@
 endif
@@ -266,6 +276,7 @@ $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE
 clean-files := \
 include/asm/asm-macros.* \
 $(objtree)/.xen-syms.[0-9]* \
+$(objtree)/.xen-syms.global-syms \
 $(objtree)/.xen.elf32 \
 $(objtree)/.xen.efi.[0-9]* \
 efi/*.efi
-- 
2.35.1

[PATCH] osstest: update Debian Buster install CD media to 10.12

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
 production-config | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/production-config b/production-config
index 9d2e7e0e..95d663dd 100644
--- a/production-config
+++ b/production-config
@@ -101,8 +101,8 @@ DebianSnapshotBackports_jessie 
http://snapshot.debian.org/archive/debian/2019020
 DebianImageVersion_wheezy 7.2.0
 DebianImageVersion_jessie 8.2.0
 DebianImageVersion_stretch 9.4.0
-DebianImageFile_buster_amd64 debian-10.2.0-amd64-xfce-CD-1.iso
-DebianImageFile_buster_i386 debian-10.2.0-i386-xfce-CD-1.iso
+DebianImageFile_buster_amd64 debian-10.12.0-amd64-xfce-CD-1.iso
+DebianImageFile_buster_i386 debian-10.12.0-i386-xfce-CD-1.iso
 
 
 # Update with ./mg-netgrub-loader-update
-- 
2.35.1

Re: x86/PV: (lack of) MTRR exposure

[Juergen Gross]

On 02.05.22 16:50, Jan Beulich wrote:

On 02.05.2022 16:25, Juergen Gross wrote:

PAT MSR writes can be handled by special casing in xen_write_msr_safe().


You can squash the write attempt there, but that'll still confuse the caller
assuming the write actually took effect.


With the list of cpus supported by Xen I don't see a big challenge here.
PAT virtualization handles everything we need.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: x86/PV: (lack of) MTRR exposure

[Jan Beulich]

On 02.05.2022 16:25, Juergen Gross wrote:
> PAT MSR writes can be handled by special casing in xen_write_msr_safe().

You can squash the write attempt there, but that'll still confuse the caller
assuming the write actually took effect.

Jan

Re: [PATCH RFC] EFI: strip xen.efi when putting it on the EFI partition

[Jan Beulich]

On 25.04.2022 12:46, Jan Beulich wrote:
> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
> there's no intermediate step (mkelf32 there) involved which would strip
> debug info kind of as a side effect. While the installing of xen.efi on
> the EFI partition is an optional step (intended to be a courtesy to the
> developer), adjust it also for the purpose of documenting what distros
> would be expected to do during boot loader configuration (which is what
> would normally put xen.efi into the EFI partition).
> 
> Model the control over stripping after Linux'es module installation,
> except that the stripped executable is constructed in the build area
> instead of in the destination location. This is to conserve on space
> used there - EFI partitions tend to be only a few hundred Mb in size.
> 
> Signed-off-by: Jan Beulich 
> ---
> RFC: GNU strip 2.38 appears to have issues when acting on a PE binary:
>  - the new file positions of the sections do not respect the file
>alignment specified by the header (a resulting looks to work on
>one EFI implementation where I did actually try it, but I don't
>think we can rely on that),
>  - file name symbols are also stripped; while there is a separate
>--keep-file-symbols option (which I would have thought to be on
>by default anyway), its use makes no difference.

Update to these items: The first one turned out to be an issue with a
not-yet-upstream patch that I've been carrying for a long time. I've
fixed that up, and will submit that patch (perhaps together with
further ones) in due course. Apart from that the list of remarks now
is

- file name symbols are also stripped; while there is a separate
  --keep-file-symbols option (which I would have thought to be on by
  default anyway), its use so far makes no difference,
- the string table grows in size, when one would expect it to shrink,
- linker version is changed in and timestamp zapped from the header.

Locally I have draft patches for all of these issues, but this means
stripping won't work overly well until at least 2.39.

Jan

Re: x86/PV: (lack of) MTRR exposure

[Juergen Gross]

On 29.04.22 12:53, Roger Pau Monné wrote:

On Fri, Apr 29, 2022 at 12:00:21PM +0200, Jan Beulich wrote:

On 29.04.2022 10:00, Roger Pau Monné wrote:

On Thu, Apr 28, 2022 at 05:53:17PM +0200, 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.

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.


I wonder whether the patch needs to be limited to the CPUID Hypervisor
bit being present.  If the PAT MSR is readable and returns a value !=
0 then PAT should be available?


I simply didn't want to be too "aggressive". There may be reasons why
they want things to be the way they are on native. All I really care
about is that things are broken on PV Xen; as such I wouldn't even
mind tightening the check to xen_pv_domain(). But first I need
feedback from the maintainers there anyway.


Right, I did also consider suggesting to limit this to PV at first,
but I was unsure why native wouldn't also want such behavior.  Maybe
there's no hardware that has PAT but not MTRR, and hence this was
never considered.


I guess we should instead check that the current PAT value matches
what Linux expects, before declaring PAT enabled?


I don't think such a check is needed, the code ...


Note there's already a comment in init_cache_modes that refers to Xen
in the check for PAT CPUID bit.


... in __init_cache_modes() already does it the other way around:
Adapt behavior to what is found in PAT.


  We might want to expand that comment
(or add one to the new check you are adding).


I don't see what further information you would want to put there.


It would depend on how the check ends up looking I think.  If the
enabling is limited to also having the Hypervisor CPUID bit set then
the comment should likely mention why setting it on native is not
safe.

Anyway, let's see what maintainers think.

The other option would be to set some kind of hooks for Xen PV to be
able to report PAT as enabled (maybe a Xen PV implementation of
mtrr_ops?), but that seems like over-engineering it.  My main concern
with setting pat_bp_enabled to true is whether in the future such
setting could be used to gate PAT MSR writes.  It's already like this
for APs (in pat_init() -> pat_ap_init()), but we avoid that path
because we don't report MTRR support AFAICT.


The clean way to handle this mess would be to support PAT in the kernel
without requiring MTRR.

The only reason for PAT to requite MTRR seems to be the common usage of
mtrr_rendezvous_handler(). I need to look into that a little bit further,
but I think this should be rather easy to solve by using a generic
rendezvous handler and proper callbacks, which will use common backend
functions.

PAT MSR writes can be handled by special casing in xen_write_msr_safe().


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v5 2/2] flask: implement xsm_set_system_active

[Jan Beulich]

On 02.05.2022 15:30, Daniel P. Smith wrote:
> @@ -188,14 +188,20 @@ static int cf_check flask_domain_alloc_security(struct 
> domain *d)
>  
>  static int cf_check flask_set_system_active(void)
>  {
> +struct domain_security_struct *dsec;
>  struct domain *d = current->domain;
>  
> +dsec = d->ssid;
> +ASSERT(dsec->sid == SECINITSID_XENBOOT);

What about ->self_sid, which ...

> +
>  if ( d->domain_id != DOMID_IDLE )
>  {
>  printk("xsm_set_system_active should only be called by idle 
> domain\n");
>  return -EPERM;
>  }
>  
> +dsec->self_sid = dsec->sid = SECINITSID_XEN;

... you also overwrite here?

Jan

Re: [PATCH v2 19/19] xen/xenbus: eliminate xenbus_grant_ring()

[Oleksandr]

On 02.05.22 16:30, Juergen Gross wrote:

Hello Juergen



On 29.04.22 17:10, Oleksandr wrote:


On 28.04.22 11:27, Juergen Gross wrote:


Hello Juergen



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, &gref_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(&gref_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, &gref_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(&gref_head);


gnttab_claim_grant_reference() can return error if no free grant 
reference remains.


This can happen only in case gnttab_alloc_grant_references() didn't
allocate enough grants but told us it succeeded doing so.

I understand this patch only moves the code, but probably it would be 
better to add a missing check here (and likely rollback already 
processed grants if any?).


I don't think this is needed, as this would be a clear bug in the code.


I would put WARN_ON_ONCE if ref is an error value then like xen-netfront 
does. Either way, with or without it you can add my:


Reviewed-by: Oleksandr Tyshchenko 







Juergen


--
Regards,

Oleksandr Tyshchenko

Re: [PATCH v5 2/2] flask: implement xsm_set_system_active

[Jason Andryuk]

On Mon, May 2, 2022 at 9:31 AM Daniel P. Smith
 wrote:

> @@ -188,14 +188,20 @@ static int cf_check flask_domain_alloc_security(struct 
> domain *d)
>
>  static int cf_check flask_set_system_active(void)
>  {
> +struct domain_security_struct *dsec;
>  struct domain *d = current->domain;
>
> +dsec = d->ssid;
> +ASSERT(dsec->sid == SECINITSID_XENBOOT);
> +
>  if ( d->domain_id != DOMID_IDLE )
>  {
>  printk("xsm_set_system_active should only be called by idle 
> domain\n");
>  return -EPERM;
>  }
>
> +dsec->self_sid = dsec->sid = SECINITSID_XEN;

I think you want to re-add setting is_privileged to false.  I think
from the other thread Roger just thought it should also have the
matching assert.  It doesn't matter for flask decisions, but it
changes the return of is_control_domain.  It seems to me it would be
better to have idle domains consistent between flask and non-flask
instead of having a potentially subtle difference.

Regards,
Jason

Re: [PATCH v5 1/2] xsm: create idle domain privileged and demote after setup

[Daniel P. Smith]

On 5/2/22 09:49, Daniel P. Smith wrote:
> On 5/2/22 09:42, Jason Andryuk wrote:
>> On Mon, May 2, 2022 at 9:31 AM Daniel P. Smith
>>  wrote:
>>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>>> index d5d0792ed4..b9057222d6 100644
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -1048,6 +1048,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>>>  /* Hide UART from DOM0 if we're using it */
>>>  serial_endboot();
>>>
>>> +if ( (rc = xsm_set_system_active()) != 0 )
>>> +panic("xsm(err=%d): "
>>> +  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", 
>>> err);
>>
>> You want to print rc in this message.
> 
> Thanks, but now I want to figure out how that compile

Ah, arm which I do not have a build env to do build tests.

v/r,
dps

Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF

[Oleksandr]

On 02.05.22 16:31, Juergen Gross wrote:


Hello Juergen



On 29.04.22 17:28, Oleksandr wrote:


Hello Juergen


On 28.04.22 21:03, Oleksandr Tyshchenko wrote:



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 mailto:jgr...@suse.com>>
    ---
     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.



In addition to what I said yesterday:

PV Display also uses this xen-front-pgdir-shbuf framework. It's 
protocol (displif.h) also mentions the same as sndif.h if the context 
of gref_dir_next_page:


  * gref_dir_next_page - grant_ref_t, reference to the next page 
describing

  *   page directory. Must be 0 if there are no more pages in the list.


With that local change both PV devices work in my environment.

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c 
b/drivers/xen/xen-front-pgdir-shbuf.c

index fa2921d..ad4a88e 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -346,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 = INVALID_GRANT_REF;
+   page_dir->gref_dir_next_page = 0;
  }

  /**
@@ -375,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 = 
INVALID_GRANT_REF;

+   page_dir->gref_dir_next_pag

Re: [PATCH v5 1/2] xsm: create idle domain privileged and demote after setup

[Daniel P. Smith]

On 5/2/22 09:42, Jason Andryuk wrote:
> On Mon, May 2, 2022 at 9:31 AM Daniel P. Smith
>  wrote:
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index d5d0792ed4..b9057222d6 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -1048,6 +1048,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>>  /* Hide UART from DOM0 if we're using it */
>>  serial_endboot();
>>
>> +if ( (rc = xsm_set_system_active()) != 0 )
>> +panic("xsm(err=%d): "
>> +  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", err);
> 
> You want to print rc in this message.

Thanks, but now I want to figure out how that compiled.

v/r,
dps

Re: [PATCH v5 1/2] xsm: create idle domain privileged and demote after setup

[Jason Andryuk]

On Mon, May 2, 2022 at 9:31 AM Daniel P. Smith
 wrote:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index d5d0792ed4..b9057222d6 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -1048,6 +1048,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>  /* Hide UART from DOM0 if we're using it */
>  serial_endboot();
>
> +if ( (rc = xsm_set_system_active()) != 0 )
> +panic("xsm(err=%d): "
> +  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", err);

You want to print rc in this message.

Regards,
Jason

Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF

[Juergen Gross]

On 29.04.22 17:28, Oleksandr wrote:


Hello Juergen


On 28.04.22 21:03, Oleksandr Tyshchenko wrote:



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 mailto:jgr...@suse.com>>
    ---
     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.



In addition to what I said yesterday:

PV Display also uses this xen-front-pgdir-shbuf framework. It's protocol 
(displif.h) also mentions the same as sndif.h if the context of gref_dir_next_page:


  * gref_dir_next_page - grant_ref_t, reference to the next page describing
  *   page directory. Must be 0 if there are no more pages in the list.


With that local change both PV devices work in my environment.

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c 
b/drivers/xen/xen-front-pgdir-shbuf.c

index fa2921d..ad4a88e 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -346,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 = INVALID_GRANT_REF;
+   page_dir->gref_dir_next_page = 0;
  }

  /**
@@ -375,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 = INVALID_GRANT_REF;
+   page_dir->gref_dir_next_page = 0;
     } else {
     to_copy 

[PATCH v5 2/2] flask: implement xsm_set_system_active

[Daniel P. Smith]

This commit implements full support for starting the idle domain privileged by
introducing a new flask label xenboot_t which the idle domain is labeled with
at creation.  It then provides the implementation for the XSM hook
xsm_set_system_active to relabel the idle domain to the existing xen_t flask
label.

In the reference flask policy a new macro, xen_build_domain(target), is
introduced for creating policies for dom0less/hyperlaunch allowing the
hypervisor to create and assign the necessary resources for domain
construction.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
 tools/flask/policy/modules/xen.if  | 6 ++
 tools/flask/policy/modules/xen.te  | 1 +
 tools/flask/policy/policy/initial_sids | 1 +
 xen/xsm/flask/hooks.c  | 8 +++-
 xen/xsm/flask/policy/initial_sids  | 1 +
 5 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 5e2aa472b6..4ec676fff1 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -62,6 +62,12 @@ define(`create_domain_common', `
setparam altp2mhvm altp2mhvm_op dm };
 ')
 
+# xen_build_domain(target)
+#   Allow a domain to be created at boot by the hypervisor
+define(`xen_build_domain', `
+   allow xenboot_t $1_channel:event create;
+')
+
 # create_domain(priv, target)
 #   Allow a domain to be created directly
 define(`create_domain', `
diff --git a/tools/flask/policy/modules/xen.te 
b/tools/flask/policy/modules/xen.te
index 3dbf93d2b8..de98206fdd 100644
--- a/tools/flask/policy/modules/xen.te
+++ b/tools/flask/policy/modules/xen.te
@@ -24,6 +24,7 @@ attribute mls_priv;
 

 
 # The hypervisor itself
+type xenboot_t, xen_type, mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
diff --git a/tools/flask/policy/policy/initial_sids 
b/tools/flask/policy/policy/initial_sids
index 6b7b7eff21..ec729d3ba3 100644
--- a/tools/flask/policy/policy/initial_sids
+++ b/tools/flask/policy/policy/initial_sids
@@ -2,6 +2,7 @@
 # objects created before the policy is loaded or for objects that do not have a
 # label defined in some other manner.
 
+sid xenboot gen_context(system_u:system_r:xenboot_t,s0)
 sid xen gen_context(system_u:system_r:xen_t,s0)
 sid dom0 gen_context(system_u:system_r:dom0_t,s0)
 sid domxen gen_context(system_u:system_r:domxen_t,s0)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0bd4e8a4bd..3e5d084276 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -168,7 +168,7 @@ static int cf_check flask_domain_alloc_security(struct 
domain *d)
 switch ( d->domain_id )
 {
 case DOMID_IDLE:
-dsec->sid = SECINITSID_XEN;
+dsec->sid = SECINITSID_XENBOOT;
 break;
 case DOMID_XEN:
 dsec->sid = SECINITSID_DOMXEN;
@@ -188,14 +188,20 @@ static int cf_check flask_domain_alloc_security(struct 
domain *d)
 
 static int cf_check flask_set_system_active(void)
 {
+struct domain_security_struct *dsec;
 struct domain *d = current->domain;
 
+dsec = d->ssid;
+ASSERT(dsec->sid == SECINITSID_XENBOOT);
+
 if ( d->domain_id != DOMID_IDLE )
 {
 printk("xsm_set_system_active should only be called by idle domain\n");
 return -EPERM;
 }
 
+dsec->self_sid = dsec->sid = SECINITSID_XEN;
+
 return 0;
 }
 
diff --git a/xen/xsm/flask/policy/initial_sids 
b/xen/xsm/flask/policy/initial_sids
index 7eca70d339..e8b55b8368 100644
--- a/xen/xsm/flask/policy/initial_sids
+++ b/xen/xsm/flask/policy/initial_sids
@@ -3,6 +3,7 @@
 #
 # Define initial security identifiers 
 #
+sid xenboot
 sid xen
 sid dom0
 sid domio
-- 
2.20.1

[PATCH v5 0/2] Adds starting the idle domain privileged

[Daniel P. Smith]

This series makes it so that the idle domain is started privileged under the
default policy, which the SILO policy inherits, and under the flask policy. It
then introduces a new one-way XSM hook, xsm_transition_running, that is hooked
by an XSM policy to transition the idle domain to its running privilege level.

Changes in v5:
- dropped setting is_privileged in flask_set_system_active()
- added err code returned by xsm_set_system_active() to panic message

Changes in v4:
- reworded patch 1 commit messaged
- fixed whitespace to coding style
- fixed comment to coding style

Changes in v3:
- renamed *_transition_running() to *_set_system_active()
- changed the XSM hook set_system_active() from void to int return
- added ASSERT check for the expected privilege level each XSM policy expected
- replaced a check against is_privileged in each arch with checking the return
  value from the call to xsm_set_system_active()

Changes in v2:
- renamed flask_domain_runtime_security() to flask_transition_running()
- added the missed assignment of self_sid

Daniel P. Smith (2):
  xsm: create idle domain privileged and demote after setup
  flask: implement xsm_set_system_active

 tools/flask/policy/modules/xen.if  |  6 ++
 tools/flask/policy/modules/xen.te  |  1 +
 tools/flask/policy/policy/initial_sids |  1 +
 xen/arch/arm/setup.c   |  4 
 xen/arch/x86/setup.c   |  5 +
 xen/common/sched/core.c|  7 ++-
 xen/include/xsm/dummy.h| 17 +
 xen/include/xsm/xsm.h  |  6 ++
 xen/xsm/dummy.c|  1 +
 xen/xsm/flask/hooks.c  | 22 +-
 xen/xsm/flask/policy/initial_sids  |  1 +
 11 files changed, 69 insertions(+), 2 deletions(-)

-- 
2.20.1

[PATCH v5 1/2] xsm: create idle domain privileged and demote after setup

[Daniel P. Smith]

There are new capabilities, dom0less and hyperlaunch, that introduce internal
hypervisor logic which needs to make resource allocation calls that are
protected by XSM access checks. This creates an issue as a subset of the
hypervisor code is executed under a system domain, the idle domain, that is
represented by a per-CPU non-privileged struct domain. To enable these new
capabilities to function correctly but in a controlled manner, this commit
changes the idle system domain to be created as a privileged domain under the
default policy and demoted before transitioning to running. A new XSM hook,
xsm_set_system_active(), is introduced to allow each XSM policy type to demote
the idle domain appropriately for that policy type. In the case of SILO, it
inherits the default policy's hook for xsm_set_system_active().

For flask a stub is added to ensure that flask policy system will function
correctly with this patch until flask is extended with support for starting the
idle domain privileged and properly demoting it on the call to
xsm_set_system_active().

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
 xen/arch/arm/setup.c|  4 
 xen/arch/x86/setup.c|  5 +
 xen/common/sched/core.c |  7 ++-
 xen/include/xsm/dummy.h | 17 +
 xen/include/xsm/xsm.h   |  6 ++
 xen/xsm/dummy.c |  1 +
 xen/xsm/flask/hooks.c   | 14 ++
 7 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..b9057222d6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1048,6 +1048,10 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* Hide UART from DOM0 if we're using it */
 serial_endboot();
 
+if ( (rc = xsm_set_system_active()) != 0 )
+panic("xsm(err=%d): "
+  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", err);
+
 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..36a60ce884 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -620,6 +620,11 @@ static void noreturn init_done(void)
 {
 void *va;
 unsigned long start, end;
+int err;
+
+if ( (err = xsm_set_system_active()) != 0 )
+panic("xsm(err=%d): "
+  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", err);
 
 system_state = SYS_STATE_active;
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 19ab678181..7b1c03a0e1 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3021,7 +3021,12 @@ void __init scheduler_init(void)
 sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
 }
 
-idle_domain = domain_create(DOMID_IDLE, NULL, 0);
+/*
+ * The idle dom is created privileged to ensure unrestricted access during
+ * setup and will be demoted by xsm_set_system_active() when setup is
+ * complete.
+ */
+idle_domain = domain_create(DOMID_IDLE, NULL, CDF_privileged);
 BUG_ON(IS_ERR(idle_domain));
 BUG_ON(nr_cpu_ids > ARRAY_SIZE(idle_vcpu));
 idle_domain->vcpu = idle_vcpu;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 58afc1d589..3291fb5396 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -101,6 +101,23 @@ static always_inline int xsm_default_action(
 }
 }
 
+static XSM_INLINE int cf_check xsm_set_system_active(void)
+{
+struct domain *d = current->domain;
+
+ASSERT(d->is_privileged);
+
+if ( d->domain_id != DOMID_IDLE )
+{
+printk("xsm_set_system_active: should only be called by idle 
domain\n");
+return -EPERM;
+}
+
+d->is_privileged = false;
+
+return 0;
+}
+
 static XSM_INLINE void cf_check xsm_security_domaininfo(
 struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3e2b7fe3db..8dad03fd3d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -52,6 +52,7 @@ typedef enum xsm_default xsm_default_t;
  * !!! WARNING !!!
  */
 struct xsm_ops {
+int (*set_system_active)(void);
 void (*security_domaininfo)(struct domain *d,
 struct xen_domctl_getdomaininfo *info);
 int (*domain_create)(struct domain *d, uint32_t ssidref);
@@ -208,6 +209,11 @@ extern struct xsm_ops xsm_ops;
 
 #ifndef XSM_NO_WRAPPERS
 
+static inline int xsm_set_system_active(void)
+{
+return alternative_call(xsm_ops.set_system_active);
+}
+
 static inline void xsm_security_domaininfo(
 struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
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

Re: [PATCH v2 19/19] xen/xenbus: eliminate xenbus_grant_ring()

[Juergen Gross]

On 29.04.22 17:10, Oleksandr wrote:


On 28.04.22 11:27, Juergen Gross wrote:


Hello Juergen



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, &gref_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(&gref_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, &gref_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(&gref_head);


gnttab_claim_grant_reference() can return error if no free grant reference 
remains.


This can happen only in case gnttab_alloc_grant_references() didn't
allocate enough grants but told us it succeeded doing so.

I understand this patch only moves the code, but probably it would be better to 
add a missing check here (and likely rollback already processed grants if any?).


I don't think this is needed, as this would be a clear bug in the code.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF

[Juergen Gross]

On 28.04.22 20:03, Oleksandr Tyshchenko wrote:



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 mailto:jgr...@suse.com>>
---
  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...


Hmm, that's unfortunate.

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.


Thanks for finding this.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[ovmf test] 169994: regressions - FAIL

[osstest service owner]

flight 169994 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169994/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  760 attempts
Testing same since   169904  2022-04-30 08:10:33 Z2 days   52 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 5855 lines long.)

[linux-linus test] 169977: tolerable FAIL - PUSHED

[osstest service owner]

flight 169977 linux-linus real [real]
flight 169992 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169977/
http://logs.test-lab.xenproject.org/osstest/logs/169992/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-freebsd12-amd64 19 guest-localmigrate/x10 fail pass in 
169992-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169968
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169968
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169968
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169968
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169968
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169968
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169968
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169968
 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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-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-rtds 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:
 linux672c0c5173427e6b3e2a9bbb7be51ceeec78093a
baseline version:
 linuxb2da7df52e16110c8d8dda0602db81c15711e7ff

Last test of basis   169968  2022-05-01 17:11:06 Z0 days
Testing same since   169977  2022-05-02 01:56:06 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Elisei 
  Linus Torvalds 
  Marc Zyngier 
  Mingwei Zhang 
  Paolo Bonzini 
  Sean Christopherson 
  Will Deacon 

jobs:
 build-amd

[libvirt test] 169980: regressions - FAIL

[osstest service owner]

flight 169980 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169980/

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  d0289cfa0e77f5db524393802eb5c58216b38db6
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  661 days
Failing since151818  2020-07-11 04:18:52 Z  660 days  642 attempts
Testing same since   169897  2022-04-30 04:20:04 Z2 days3 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 Paladug

[ovmf test] 169991: regressions - FAIL

[osstest service owner]

flight 169991 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169991/

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-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   63 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  759 attempts
Testing same since   169904  2022-04-30 08:10:33 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 
  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 5855 lines long.)

Re: [xen-unstable test] 169819: regressions - FAIL

[Roger Pau Monné]

On Mon, May 02, 2022 at 01:16:05PM +0200, Juergen Gross wrote:
> On 02.05.22 12:49, Roger Pau Monné wrote:
> > On Mon, May 02, 2022 at 08:51:40AM +0200, Juergen Gross wrote:
> > > On 29.04.22 13:00, Roger Pau Monné wrote:
> > > > On Fri, Apr 29, 2022 at 12:37:13PM +0200, Jan Beulich wrote:
> > > > > On 29.04.2022 12:30, Roger Pau Monné wrote:
> > > > > > On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner 
> > > > > > wrote:
> > > > > > > flight 169819 xen-unstable real [real]
> > > > > > > flight 169843 xen-unstable real-retest [real]
> > > > > > > http://logs.test-lab.xenproject.org/osstest/logs/169819/
> > > > > > > http://logs.test-lab.xenproject.org/osstest/logs/169843/
> > > > > > > 
> > > > > > > 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-credit1   8 xen-boot fail 
> > > > > > > REGR. vs. 169775
> > > > > > >test-arm64-arm64-xl-thunderx  8 xen-boot fail 
> > > > > > > REGR. vs. 169775
> > > > > > >test-arm64-arm64-xl   8 xen-boot fail 
> > > > > > > REGR. vs. 169775
> > > > > > > 
> > > > > > > Tests which are failing intermittently (not blocking):
> > > > > > >test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 
> > > > > > > debian-hvm-install fail pass in 169843-retest
> > > > > > 
> > > > > > Looked into this one, and it's slightly concerning, guest seems to 
> > > > > > be
> > > > > > stuck at installation:
> > > > > > 
> > > > > > Select and install software  [  481.093857] watchdog: BUG: soft 
> > > > > > lockup - CPU#1 stuck for 23s! [ksoftirqd/1:17]
> > > > > > [  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > > > [ksoftirqd/1:17]
> > > > > > [ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 

Re: Virtio on Xen with Rust

[Viresh Kumar]

On 14-04-22, 14:45, Viresh Kumar wrote:
> Hello,
> 
> 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.

An update to this, I have successfully tested GPIO backend as well with this
setup now and pushed out everything.

- GPIO required two virtqueues instead of one as in case of I2C.

- GPIO requires to do configuration exchange as well, while I2C didn't.

- The latest code supports MMIO V2, modern.

- The Xen vhost master is fully device independent now and a device type can be
  chosen based on just the command line itself. It would be simple to test RNG
  or other backends with this now (we just need to update "enum
  VirtioDeviceType" in vhost-user-master crate for this, with device specific
  information). Of course we need to emulate device in Xen too.

Hope this helps.

-- 
viresh

Re: [PATCH v3] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld

[Roger Pau Monné]

On Mon, May 02, 2022 at 09:09:46AM +0200, Jan Beulich wrote:
> Support for this construct was added in 2.22 only. Avoid the need to
> introduce logic to probe for linker script capabilities by (ab)using the
> probe for a command line option having appeared at about the same time.
> 
> Note that this remains x86-specific because Arm is unaffected, by
> requiring GNU ld 2.24 or newer.
> 
> Fixes: 4b7fd8153ddf ("x86: fold sections in final binaries")
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

Re: [xen-unstable test] 169819: regressions - FAIL

[Juergen Gross]

On 02.05.22 12:49, Roger Pau Monné wrote:

On Mon, May 02, 2022 at 08:51:40AM +0200, Juergen Gross wrote:

On 29.04.22 13:00, Roger Pau Monné wrote:

On Fri, Apr 29, 2022 at 12:37:13PM +0200, Jan Beulich wrote:

On 29.04.2022 12:30, Roger Pau Monné wrote:

On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner wrote:

flight 169819 xen-unstable real [real]
flight 169843 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169819/
http://logs.test-lab.xenproject.org/osstest/logs/169843/

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-credit1   8 xen-boot fail REGR. vs. 
169775
   test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 
169775
   test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 
169775

Tests which are failing intermittently (not blocking):
   test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 169843-retest


Looked into this one, and it's slightly concerning, guest seems to be
stuck at installation:

Select and install software  [  481.093857] watchdog: BUG: soft lockup - CPU#1 
stuck for 23s! [ksoftirqd/1:17]
[  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1393.094167] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1429.093857] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1457.093900] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1489.094026] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1517.093997] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1553.093996] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1581.094064] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1617.094076] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1645.093882] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1681.093896] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1709.094022] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1741.093870] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1769.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1805.094017] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1833.093837] watch

Re: [xen-unstable test] 169819: regressions - FAIL

[Roger Pau Monné]

On Mon, May 02, 2022 at 08:51:40AM +0200, Juergen Gross wrote:
> On 29.04.22 13:00, Roger Pau Monné wrote:
> > On Fri, Apr 29, 2022 at 12:37:13PM +0200, Jan Beulich wrote:
> > > On 29.04.2022 12:30, Roger Pau Monné wrote:
> > > > On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner wrote:
> > > > > flight 169819 xen-unstable real [real]
> > > > > flight 169843 xen-unstable real-retest [real]
> > > > > http://logs.test-lab.xenproject.org/osstest/logs/169819/
> > > > > http://logs.test-lab.xenproject.org/osstest/logs/169843/
> > > > > 
> > > > > 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-credit1   8 xen-boot fail REGR. 
> > > > > vs. 169775
> > > > >   test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. 
> > > > > vs. 169775
> > > > >   test-arm64-arm64-xl   8 xen-boot fail REGR. 
> > > > > vs. 169775
> > > > > 
> > > > > Tests which are failing intermittently (not blocking):
> > > > >   test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install 
> > > > > fail pass in 169843-retest
> > > > 
> > > > Looked into this one, and it's slightly concerning, guest seems to be
> > > > stuck at installation:
> > > > 
> > > > Select and install software  [  481.093857] watchdog: BUG: soft lockup 
> > > > - CPU#1 stuck for 23s! [ksoftirqd/1:17]
> > > > [  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1393.094167] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1429.093857] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1457.093900] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1489.094026] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > > > [ksoftirqd/1:17]
> > > > [ 1517.093997] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> >

[ovmf test] 169989: regressions - FAIL

[osstest service owner]

flight 169989 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169989/

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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   62 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  758 attempts
Testing same since   169904  2022-04-30 08:10:33 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 
  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 5855 lines long.)

[PATCH v2] tools/xenstore: don't let special watches be children of /

[Juergen Gross]

When firing special watches (e.g. "@releaseDomain"), they will be
regarded to be valid children of the "/" node. So a domain having
registered a watch for "/" and having the privilege to receive
the special watches will receive those special watch events for the
registered "/" watch.

Fix that by calling the related fire_watches() with the "exact"
parameter set to true, causing a mismatch for the "/" node.

Reported-by: Raphael Ning 
Signed-off-by: Juergen Gross 
Reviewed-by: Raphael Ning 
---
V2:
- use Rapahael's amazon mail address
---
 tools/xenstore/xenstored_domain.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c 
b/tools/xenstore/xenstored_domain.c
index ae065fcbee..80ba1d627b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -231,7 +231,7 @@ static int destroy_domain(void *_domain)
unmap_interface(domain->interface);
}
 
-   fire_watches(NULL, domain, "@releaseDomain", NULL, false, NULL);
+   fire_watches(NULL, domain, "@releaseDomain", NULL, true, NULL);
 
wrl_domain_destroy(domain);
 
@@ -282,7 +282,7 @@ void check_domains(void)
}
 
if (notify)
-   fire_watches(NULL, NULL, "@releaseDomain", NULL, false, NULL);
+   fire_watches(NULL, NULL, "@releaseDomain", NULL, true, NULL);
 }
 
 /* We scan all domains rather than use the information given here. */
@@ -495,7 +495,7 @@ static struct domain *introduce_domain(const void *ctx,
 
if (!is_master_domain && !restore)
fire_watches(NULL, ctx, "@introduceDomain", NULL,
-false, NULL);
+true, NULL);
} else {
/* Use XS_INTRODUCE for recreating the xenbus event-channel. */
if (domain->port)
-- 
2.34.1

[xen-unstable-smoke test] 169982: tolerable all pass - PUSHED

[osstest service owner]

flight 169982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169982/

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  702c9a800eb3ecd4b8595998d37a769d470c5bb0
baseline version:
 xen  fe234237b6fc8afc5d8265850169ceeb3d2f81fd

Last test of basis   169864  2022-04-29 10:00:27 Z2 days
Testing same since   169982  2022-05-02 07:01:45 Z0 days1 attempts


People who touched revisions under test:
  Elliott Mitchell 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   fe234237b6..702c9a800e  702c9a800eb3ecd4b8595998d37a769d470c5bb0 -> smoke

[ovmf test] 169988: regressions - FAIL

[osstest service owner]

flight 169988 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169988/

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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   62 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  757 attempts
Testing same since   169904  2022-04-30 08:10:33 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 
  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 5855 lines long.)

[ovmf test] 169987: regressions - FAIL

[osstest service owner]

flight 169987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169987/

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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   62 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  756 attempts
Testing same since   169904  2022-04-30 08:10:33 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 
  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 5855 lines long.)

[xen-unstable test] 169976: tolerable FAIL

[osstest service owner]

flight 169976 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169976/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-install fail pass in 169929

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169929
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169929
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169929
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169929
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169929
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169929
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169929
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169929
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169929
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169929
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169929
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169929
 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-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-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-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-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-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-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-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-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-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 targe

[PATCH v3] tools/libs/light: update xenstore entry when setting max domain memory

[Juergen Gross]

libxl_domain_setmaxmem() called during "xl mem-max" should update the
domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
won't be able to set the memory size to the new maximum.

Adjust the related comments and documentation accordingly.

Signed-off-by: Juergen Gross 
---
V2:
- adjust comments and docs (Anthony Perard)
V3:
- really adjust the docs (Anthony Perard)
---
 docs/man/xl.1.pod.in | 11 +--
 tools/libs/light/libxl_mem.c | 12 ++--
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index e2176bd696..101e14241d 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -442,15 +442,14 @@ allocate.
 The default unit is kiB.  Add 't' for TiB, 'g' for GiB, 'm' for
 MiB, 'k' for kiB, and 'b' for bytes (e.g., `2048m` for 2048 MiB).
 
-NB that users normally shouldn't need this command; B will
-set this as appropriate automatically.
-
 I can't be set lower than the current memory target for
 I.  It is allowed to be higher than the configured maximum
 memory size of the domain (B parameter in the domain's
-configuration). Note however that the initial B value is still
-used as an upper limit for B.  Also note that calling B will reset this value.
+configuration).
+
+Setting the maximum memory size above the configured maximum memory size
+will require special guest support (memory hotplug) in order to be usable
+by the guest.
 
 The domain will not receive any signal regarding the changed memory
 limit.
diff --git a/tools/libs/light/libxl_mem.c b/tools/libs/light/libxl_mem.c
index c739d00f39..92ec09f4cf 100644
--- a/tools/libs/light/libxl_mem.c
+++ b/tools/libs/light/libxl_mem.c
@@ -20,8 +20,7 @@
 /*
  * Set the maximum memory size of the domain in the hypervisor. There is no
  * change of the current memory size involved. The specified memory size can
- * even be above the configured maxmem size of the domain, but the related
- * Xenstore entry memory/static-max isn't modified!
+ * even be above the configured maxmem size of the domain.
  */
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
 {
@@ -82,6 +81,15 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, 
uint64_t max_memkb)
 goto out;
 }
 
+rc = libxl__xs_printf(gc, XBT_NULL,
+  GCSPRINTF("%s/memory/static-max", dompath),
+  "%"PRIu64, max_memkb);
+if (rc != 0) {
+LOGED(ERROR, domid, "Couldn't set %s/memory/static-max, rc=%d\n",
+  dompath, rc);
+goto out;
+}
+
 rc = 0;
 out:
 libxl_domain_config_dispose(&d_config);
-- 
2.34.1

[ovmf test] 169983: regressions - FAIL

[osstest service owner]

flight 169983 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169983/

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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   62 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  755 attempts
Testing same since   169904  2022-04-30 08:10:33 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 
  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 5855 lines long.)

Re: [PATCH v2] tools/libs/light: update xenstore entry when setting max domain memory

[Juergen Gross]

On 29.04.22 16:52, Anthony PERARD wrote:

On Wed, Apr 20, 2022 at 10:04:26AM +0200, Juergen Gross wrote:

libxl_domain_setmaxmem() called during "xl mem-max" should update the
domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
won't be able to set the memory size to the new maximum.


Setting domain's memory higher than the original mem-max only works on
PV and maybe PVH guest, right? Because on HVM, QEMU is told about
maxmem when starting a guest, and allocates some stuff from this address
(vga buffer, pci rom I think) so trying to give HVM guest more memory
after the fact is probably not going to go smoothly.


Works without a problem.

This area is marked in the e820 memory map, so the guest won't use it to
add memory.




Adjust the related comments and documentation accordingly.

Signed-off-by: Juergen Gross 
---
V2:
- adjust comments and docs (Anthony Perard)


Maybe `man xl` should be updated as well. In the section about `xl
mem-max`, there is:
 "Note however that the initial maxmem value is still used as an
 upper limit for xl mem-set.  Also note that calling xl mem-set will
 reset this value."

That wouldn't be true anymore with this patch.


Weird. I did modify that man page, but obviously didn't check it was
really added to the patch. Sorry for that, will resend the patch with
that change included.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT

[Demi Marie Obenour]

On Mon, May 02, 2022 at 09:37:39AM +0200, Jan Beulich wrote:
> On 02.05.2022 09:11, Demi Marie Obenour wrote:
> > On Mon, May 02, 2022 at 08:24:30AM +0200, Jan Beulich wrote:
> >> On 29.04.2022 19:06, Demi Marie Obenour wrote:
> >>> On Fri, Apr 29, 2022 at 10:40:42AM +0200, Jan Beulich wrote:
>  On 29.04.2022 00:54, Demi Marie Obenour wrote:
> > On Thu, Apr 28, 2022 at 08:47:49AM +0200, Jan Beulich wrote:
> >> On 27.04.2022 21:08, Demi Marie Obenour wrote:
> >>> 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?
> 
>  While in boot mode, aiui page tables aren't supposed to be enforcing
>  access restrictions. Recall that on other architectures EFI even runs
>  with paging disabled; this simply is not possible for x86-64.
> >>>
> >>> Yikes!  No wonder firmware has nonexistent exploit mitigations.  They
> >>> really ought to start porting UEFI to Rust, with ASLR, NX, stack
> >>> canaries, a hardened allocator, and support for de-priviliged services
> >>> that run in user mode.
> >>>
> >>> That reminds me: Can Xen itself run from ROM?
> >>
> >> I guess that could be possible in principle, but would certainly require
> >> some work.
> >>
> >>>  Xen is being ported to
> >>> POWER for use in Qubes OS, and one approach under consideration is to
> >>> have Xen and a mini-dom0 be part of the firmware.  Personally, I really
> >>> like this approach, as it makes untrusted storage domains much simpler.
> >>> If this should be a separate email thread, let me know.
> >>
> >> It probably should be.
> > 
> > I will make one at some point.
> > 
>  So
>  portable firmware shouldn't map anything r/o. In principle the pointer
>  could still be in ROM; I consider this unlikely, but we could check
>  for that (just like we could do a page table walk to figure out
>  whether a r/o mapping would prevent us from updating the field).
> >>>
> >>> Is there a utility function that could be used for this?
> >>
> >> I don't think there is.
> > 
> > Then it is good that none is necessary :)
> > 
> > Also, should the various bug checks I added be replaced by ASSERT()?
> 
> You mean those in the earlier patch(es)? Not sure - depends on what you
> would be doing for release builds. In the cases where you simply re-
> check what was checked earlier on, ASSERT() would probably indeed be
> preferable over BUG_ON() (and there I wouldn't even see a strong need
> to consider alternatives for release builds).

Yup, that’s what the BUG_ON()s were for.  I will use ASSERT() in the
next round.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT

[Jan Beulich]

On 02.05.2022 09:11, Demi Marie Obenour wrote:
> On Mon, May 02, 2022 at 08:24:30AM +0200, Jan Beulich wrote:
>> On 29.04.2022 19:06, Demi Marie Obenour wrote:
>>> On Fri, Apr 29, 2022 at 10:40:42AM +0200, Jan Beulich wrote:
 On 29.04.2022 00:54, Demi Marie Obenour wrote:
> On Thu, Apr 28, 2022 at 08:47:49AM +0200, Jan Beulich wrote:
>> On 27.04.2022 21:08, Demi Marie Obenour wrote:
>>> 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?

 While in boot mode, aiui page tables aren't supposed to be enforcing
 access restrictions. Recall that on other architectures EFI even runs
 with paging disabled; this simply is not possible for x86-64.
>>>
>>> Yikes!  No wonder firmware has nonexistent exploit mitigations.  They
>>> really ought to start porting UEFI to Rust, with ASLR, NX, stack
>>> canaries, a hardened allocator, and support for de-priviliged services
>>> that run in user mode.
>>>
>>> That reminds me: Can Xen itself run from ROM?
>>
>> I guess that could be possible in principle, but would certainly require
>> some work.
>>
>>>  Xen is being ported to
>>> POWER for use in Qubes OS, and one approach under consideration is to
>>> have Xen and a mini-dom0 be part of the firmware.  Personally, I really
>>> like this approach, as it makes untrusted storage domains much simpler.
>>> If this should be a separate email thread, let me know.
>>
>> It probably should be.
> 
> I will make one at some point.
> 
 So
 portable firmware shouldn't map anything r/o. In principle the pointer
 could still be in ROM; I consider this unlikely, but we could check
 for that (just like we could do a page table walk to figure out
 whether a r/o mapping would prevent us from updating the field).
>>>
>>> Is there a utility function that could be used for this?
>>
>> I don't think there is.
> 
> Then it is good that none is necessary :)
> 
> Also, should the various bug checks I added be replaced by ASSERT()?

You mean those in the earlier patch(es)? Not sure - depends on what you
would be doing for release builds. In the cases where you simply re-
check what was checked earlier on, ASSERT() would probably indeed be
preferable over BUG_ON() (and there I wouldn't even see a strong need
to consider alternatives for release builds).

Jan

[ovmf test] 169981: regressions - FAIL

[osstest service owner]

flight 169981 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169981/

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 cabd96ad03603a63a97e701fb30a03341ca0e2ec
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   62 days
Failing since168258  2022-03-01 01:55:31 Z   62 days  754 attempts
Testing same since   169904  2022-04-30 08:10:33 Z1 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 
  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 5855 lines long.)

Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT

[Demi Marie Obenour]

On Mon, May 02, 2022 at 08:24:30AM +0200, Jan Beulich wrote:
> On 29.04.2022 19:06, Demi Marie Obenour wrote:
> > On Fri, Apr 29, 2022 at 10:40:42AM +0200, Jan Beulich wrote:
> >> On 29.04.2022 00:54, Demi Marie Obenour wrote:
> >>> On Thu, Apr 28, 2022 at 08:47:49AM +0200, Jan Beulich wrote:
>  On 27.04.2022 21:08, Demi Marie Obenour wrote:
> > 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?
> >>
> >> While in boot mode, aiui page tables aren't supposed to be enforcing
> >> access restrictions. Recall that on other architectures EFI even runs
> >> with paging disabled; this simply is not possible for x86-64.
> > 
> > Yikes!  No wonder firmware has nonexistent exploit mitigations.  They
> > really ought to start porting UEFI to Rust, with ASLR, NX, stack
> > canaries, a hardened allocator, and support for de-priviliged services
> > that run in user mode.
> > 
> > That reminds me: Can Xen itself run from ROM?
> 
> I guess that could be possible in principle, but would certainly require
> some work.
> 
> >  Xen is being ported to
> > POWER for use in Qubes OS, and one approach under consideration is to
> > have Xen and a mini-dom0 be part of the firmware.  Personally, I really
> > like this approach, as it makes untrusted storage domains much simpler.
> > If this should be a separate email thread, let me know.
> 
> It probably should be.

I will make one at some point.

> >> So
> >> portable firmware shouldn't map anything r/o. In principle the pointer
> >> could still be in ROM; I consider this unlikely, but we could check
> >> for that (just like we could do a page table walk to figure out
> >> whether a r/o mapping would prevent us from updating the field).
> > 
> > Is there a utility function that could be used for this?
> 
> I don't think there is.

Then it is good that none is necessary :)

Also, should the various bug checks I added be replaced by ASSERT()?

> >>>  It could also be undefined behavior to modify it.
> >>
> >> That's the bigger worry I have.
> > 
> > Turns out that it is *not* undefined behavior, so long as
> > ExitBootServices() has not been called.  This is becaues EFI drivers
> > will modify the config table, so firmware cannot assume it to be
> > read-only.
> 
> Ah, right - we could even use InstallConfigurationTable() ourselves
> to make the adjustment.

That is even simpler than I thought!  I was worried that
InstallConfigurationTable() would assume that memory for the table was
allocated a certain way and cause invalid free errors, but at least
TianoCore does not do that.

> > 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.
> >>
> >> It definitely is. We do recycle EfiLoaderData ourselves.
> > 
> > I wonder why the ESRT was not in EfiRuntimeServicesData to begin with.
> 
> So do I.

I suspect the assumption was that the ESRT would be parsed by the OS
before

[PATCH v3] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld

[Jan Beulich]

Support for this construct was added in 2.22 only. Avoid the need to
introduce logic to probe for linker script capabilities by (ab)using the
probe for a command line option having appeared at about the same time.

Note that this remains x86-specific because Arm is unaffected, by
requiring GNU ld 2.24 or newer.

Fixes: 4b7fd8153ddf ("x86: fold sections in final binaries")
Signed-off-by: Jan Beulich 
---
v3: Rebase over "kconfig: detect LD implementation".
v2: Always define HAVE_LD_SORT_BY_INIT_PRIORITY when using LLVM ld.

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -73,6 +73,16 @@ ifeq ($(CONFIG_UBSAN),y)
 $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
 endif
 
+ifeq ($(CONFIG_LD_IS_GNU),y)
+# While not much better than going by raw GNU ld version, utilize that the
+# feature we're after has appeared in the same release as the
+# --print-output-format command line option.
+AFLAGS-$(call ld-option,--print-output-format) += 
-DHAVE_LD_SORT_BY_INIT_PRIORITY
+else
+# Assume all versions of LLD support this.
+AFLAGS += -DHAVE_LD_SORT_BY_INIT_PRIORITY
+endif
+
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 
 efi-check := arch/x86/efi/check
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -36,6 +36,10 @@ ENTRY(start_pa)
 # define SECTION_ALIGN PAGE_SIZE
 #endif
 
+#ifndef HAVE_LD_SORT_BY_INIT_PRIORITY
+# define SORT_BY_INIT_PRIORITY SORT
+#endif
+
 OUTPUT_FORMAT(FORMAT, FORMAT, FORMAT)
 
 OUTPUT_ARCH(i386:x86-64)