[ovmf test] 170022: regressions - FAIL

[osstest service owner]

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

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  773 attempts
Testing same since   16  2022-05-02 17:12:56 Z0 days   11 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  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.)

[libvirt test] 170020: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   151777  2020-07-10 04:19:19 Z  662 days
Failing since151818  2020-07-11 04:18:52 Z  661 days  643 attempts
Testing same since   170020  2022-05-03 04:20:13 Z0 days1 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Amneesh Singh 
  Andika Triwidada 
  Andrea Bolognani 
  Andrew Melnychenko 
  Ani Sinha 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brad Laue 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Borntraeger 
  Christian Ehrhardt 
  Christian Kirbach 
  Christian Schoenebeck 
  Christophe Fergeau 
  Claudio Fontana 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Cédric Bosdonnat 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Didik Supriadi 
  dinglimin 
  Divya Garg 
  Dmitrii Shcherbakov 
  Dmytro Linkin 
  Eiichi Tsukata 
  Emilio Herrera 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Franck Ridel 
  Gavi Teitz 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Haonan Wang 
  Hela Basa 
  Helmut Grohne 
  Hiroki Narukawa 
  Hyman Huang(黄勇) 
  Ian Wienand 
  Ioanna Alifieraki 
  Ivan Teterevkov 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  jason lee 
  Jean-Baptiste Holcroft 
  Jia Zhou 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jing Qi 
  Jinsheng Zhang 
  Jiri Denemark 
  Joachim Falk 
  John Ferlan 
  John Levon 
  John Levon 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Justin Gatzen 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kim InSoo 
  Koichi Murase 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Lei Yang 
  Lena Voytek 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Lubomir Rintel 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Martin Pitt 
  Masayoshi Mizuma 
  Matej Cepl 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Maxim Nestratov 
  Meina Li 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Moshe Levi 
  Moteen Shah 
  Moteen Shah 
  Muha Aliss 
  Nathan 
  Neal Gompa 
  Nick Chevsky 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nicolas Lécureuil 
  Nicolas Lécureuil 
  Nikolay Shirokovskiy 
  Nikolay Shirokovskiy 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Or Ozeri 
  Orion Poplawski 
  Pany 
  Paolo Bonzini 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Praveen K Paladug

osstest: blessed sabro boxes

[Roger Pau Monné]

Hello,

I've blessed the pair of sabro boxes for production after a successful
commission flight:

http://logs.test-lab.xenproject.org/osstest/logs/169857/

Note that the boxes don't seem to be able to boot in 32bit mode, see
the following flight where all 32bit jobs failed to install the host:

http://logs.test-lab.xenproject.org/osstest/logs/169986/

I have no idea what's causing this, and hence sabros will only be used
in 64bit mode.  FWIW, those boxes where already not marked as suitable
for 32bit installs, I had to add the arch-i386 flag myself in order to
test (which I've now removed again before blessing).

Roger.

[ovmf test] 170027: regressions - FAIL

[osstest service owner]

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

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  774 attempts
Testing same since   16  2022-05-02 17:12:56 Z0 days   12 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 RFC] x86/lld: fix symbol map generation

[Jan Beulich]

On 02.05.2022 17:20, Roger Pau Monne wrote:
> 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

I'm puzzled by "almost" - is there a pattern of which ones aren't
converted?

Also "last linking step" is ambiguous, as we link three binaries and
aiui the issue is present on every of these passes. May I suggest
"... when linking actual executables" or (still somewhat ambiguous)
"... when linking final binaries"?

> 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.

Perhaps a map file (like we use for shared libraries in tools/) would
allow doing so? But of course this would want to be machine-generated,
not manually maintained.

Have you gained any insight into _why_ they are doing what they do?

> 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.

If, as the last paragraph of the description is worded, you did this
just once (as a prereq), I could see this working. Otherwise (as you
have it now, with it done 3 times) it would first require splitting
the linking rules into many separate ones (which has been the plan
anyway, but so far I didn't get to it).

> --- 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 $@

Is this very useful? It only affects ...

>   $(NM) -pa --format=sysv $(@D)/$(@F) \
>   | $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
> --sort \
>   >$(@D)/$(@F).map

... the actual map file; what's in the binary and in this map file doesn't
depend on local vs global anymore (and you limit this to text symbols
anyway; I wonder in how far livepatching might also be affected by the
same issue with data symbols).

In any event I would like to ask that the objcopy invocations be tied to
lld being in use. No matter that it shouldn't, objcopy can alter binaries
even if no actual change is being made (I've just recently observed this
with xen.efi, see the thread rooted at "EFI: strip xen.efi when putting it
on the EFI partition", and recall that at least for GNU binutils objcopy
and strip are effectively [almost] the same binary).

Jan

Re: osstest: blessed sabro boxes

[Jan Beulich]

On 03.05.2022 09:50, Roger Pau Monné wrote:
> Hello,
> 
> I've blessed the pair of sabro boxes for production after a successful
> commission flight:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/169857/
> 
> Note that the boxes don't seem to be able to boot in 32bit mode, see
> the following flight where all 32bit jobs failed to install the host:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/169986/
> 
> I have no idea what's causing this, and hence sabros will only be used
> in 64bit mode.

You may have better luck with a PAE kernel (which would then also be
able to use all of the memory rather than just about 1.7 Gb):

Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!

Jan

[ovmf test] 170029: regressions - FAIL

[osstest service owner]

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

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  775 attempts
Testing same since   16  2022-05-02 17:12:56 Z0 days   13 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.)

[PATCH v5 1/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL

[Roger Pau Monne]

Use the logic to set shadow SPEC_CTRL values in order to implement
support for VIRT_SPEC_CTRL (signaled by VIRT_SSBD CPUID flag) for HVM
guests. This includes using the spec_ctrl vCPU MSR variable to store
the guest set value of VIRT_SPEC_CTRL.SSBD, which will be OR'ed with
any SPEC_CTRL values being set by the guest.

On hardware having SPEC_CTRL VIRT_SPEC_CTRL will not be offered by
default to guests. VIRT_SPEC_CTRL will only be part of the max CPUID
policy so it can be enabled for compatibility purposes.

Use '!' to annotate the feature in order to express that the presence
of the bit is not directly tied to its value in the host policy.

Suggested-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Changes since v3:
 - Use '!' to annotate the feature.

Changes since v2:
 - Reword reasoning for using '!s'.
 - Trim comment about only setting SSBD bit in spec_ctrl.raw.

Changes since v1:
 - Only expose VIRT_SSBD if AMD_SSBD is available on the host.
 - Revert change to msr-sc= command line option documentation.
 - Only set or clear the SSBD bit of spec_ctrl.
---
 xen/arch/x86/cpuid.c|  7 +++
 xen/arch/x86/hvm/hvm.c  |  1 +
 xen/arch/x86/include/asm/msr.h  |  4 
 xen/arch/x86/msr.c  | 18 ++
 xen/arch/x86/spec_ctrl.c|  3 ++-
 xen/include/public/arch-x86/cpufeatureset.h |  2 +-
 6 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 7e0b395698..979dcf8164 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -550,6 +550,13 @@ static void __init calculate_hvm_max_policy(void)
 __clear_bit(X86_FEATURE_IBRSB, hvm_featureset);
 __clear_bit(X86_FEATURE_IBRS, hvm_featureset);
 }
+else if ( boot_cpu_has(X86_FEATURE_AMD_SSBD) )
+/*
+ * If SPEC_CTRL.SSBD is available VIRT_SPEC_CTRL.SSBD can be exposed
+ * and implemented using the former. Expose in the max policy only as
+ * the preference is for guests to use SPEC_CTRL.SSBD if available.
+ */
+__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
 
 /*
  * With VT-x, some features are only supported by Xen if dedicated
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5b16fb4cd8..db8f95ef7c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1334,6 +1334,7 @@ static const uint32_t msrs_to_send[] = {
 MSR_INTEL_MISC_FEATURES_ENABLES,
 MSR_IA32_BNDCFGS,
 MSR_IA32_XSS,
+MSR_VIRT_SPEC_CTRL,
 MSR_AMD64_DR0_ADDRESS_MASK,
 MSR_AMD64_DR1_ADDRESS_MASK,
 MSR_AMD64_DR2_ADDRESS_MASK,
diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index ce4fe51afe..ab6fbb5051 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -291,6 +291,7 @@ struct vcpu_msrs
 {
 /*
  * 0x0048 - MSR_SPEC_CTRL
+ * 0xc001011f - MSR_VIRT_SPEC_CTRL (if X86_FEATURE_AMD_SSBD)
  *
  * For PV guests, this holds the guest kernel value.  It is accessed on
  * every entry/exit path.
@@ -306,6 +307,9 @@ struct vcpu_msrs
  * We must clear/restore Xen's value before/after VMRUN to avoid unduly
  * influencing the guest.  In order to support "behind the guest's back"
  * protections, we load this value (commonly 0) before VMRUN.
+ *
+ * Once of such "behind the guest's back" usages is setting SPEC_CTRL.SSBD
+ * if the guest sets VIRT_SPEC_CTRL.SSBD.
  */
 struct {
 uint32_t raw;
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 6206529162..c9aabbafd7 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -383,6 +383,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t 
*val)
? K8_HWCR_TSC_FREQ_SEL : 0;
 break;
 
+case MSR_VIRT_SPEC_CTRL:
+if ( !cp->extd.virt_ssbd )
+goto gp_fault;
+
+*val = msrs->spec_ctrl.raw & SPEC_CTRL_SSBD;
+break;
+
 case MSR_AMD64_DE_CFG:
 if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
 goto gp_fault;
@@ -668,6 +675,17 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 wrmsr_tsc_aux(val);
 break;
 
+case MSR_VIRT_SPEC_CTRL:
+if ( !cp->extd.virt_ssbd )
+goto gp_fault;
+
+/* Only supports SSBD bit, the rest are ignored. */
+if ( val & SPEC_CTRL_SSBD )
+msrs->spec_ctrl.raw |= SPEC_CTRL_SSBD;
+else
+msrs->spec_ctrl.raw &= ~SPEC_CTRL_SSBD;
+break;
+
 case MSR_AMD64_DE_CFG:
 /*
  * OpenBSD 6.7 will panic if writing to DE_CFG triggers a #GP:
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 1408e4c7ab..f338bfe292 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -402,12 +402,13 @@ static void __init print_details(enum ind_thunk thunk

[PATCH v5 2/3] amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests

[Roger Pau Monne]

Allow HVM guests access to MSR_VIRT_SPEC_CTRL if the platform Xen is
running on has support for it.  This requires adding logic in the
vm{entry,exit} paths for SVM in order to context switch between the
hypervisor value and the guest one.  The added handlers for context
switch will also be used for the legacy SSBD support.

Introduce a new synthetic feature leaf (X86_FEATURE_VIRT_SC_MSR_HVM)
to signal whether VIRT_SPEC_CTRL needs to be handled on guest
vm{entry,exit}.

Suggested-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Fix exposing in the max policy.

Changes since v3:
 - Always trap write accesses to VIRT_SPEC_CTRL in order to cache the
   guest setting.
 - Do not use the 'S' annotation for the VIRT_SSBD feature.

Changes since v2:
 - Reword part of the commit message regarding annotation change.
 - Fix MSR intercept.
 - Add handling of VIRT_SPEC_CTRL to guest_{rd,wr}msr when using
   VIRT_SSBD also.

Changes since v1:
 - Introduce virt_spec_ctrl vCPU field.
 - Context switch VIRT_SPEC_CTRL on vmentry/vmexit separately from
   SPEC_CTRL.
---
 xen/arch/x86/cpuid.c   | 10 
 xen/arch/x86/hvm/svm/entry.S   |  8 ++
 xen/arch/x86/hvm/svm/svm.c | 35 ++
 xen/arch/x86/include/asm/cpufeatures.h |  1 +
 xen/arch/x86/include/asm/msr.h | 10 
 xen/arch/x86/msr.c | 16 +---
 xen/arch/x86/spec_ctrl.c   |  9 ++-
 7 files changed, 84 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 979dcf8164..0b6ba117b7 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -541,6 +541,9 @@ static void __init calculate_hvm_max_policy(void)
  raw_cpuid_policy.basic.sep )
 __set_bit(X86_FEATURE_SEP, hvm_featureset);
 
+if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
+__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
+
 /*
  * If Xen isn't virtualising MSR_SPEC_CTRL for HVM guests (functional
  * availability, or admin choice), hide the feature.
@@ -597,6 +600,13 @@ static void __init calculate_hvm_def_policy(void)
 guest_common_feature_adjustments(hvm_featureset);
 guest_common_default_feature_adjustments(hvm_featureset);
 
+/*
+ * Only expose VIRT_SSBD if AMD_SSBD is not available, and thus
+ * VIRT_SC_MSR_HVM is set.
+ */
+if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
+__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
+
 sanitise_featureset(hvm_featureset);
 cpuid_featureset_to_policy(hvm_featureset, p);
 recalculate_xstate(p);
diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index 4ae55a2ef6..2f63a2e3c6 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -19,6 +19,8 @@
 
 .file "svm/entry.S"
 
+#include 
+
 #include 
 #include 
 
@@ -57,6 +59,9 @@ __UNLIKELY_END(nsvm_hap)
 
 clgi
 
+ALTERNATIVE "", STR(call vmentry_virt_spec_ctrl), \
+X86_FEATURE_VIRT_SC_MSR_HVM
+
 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
 /* SPEC_CTRL_EXIT_TO_SVM   Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
 .macro svm_vmentry_spec_ctrl
@@ -114,6 +119,9 @@ __UNLIKELY_END(nsvm_hap)
 ALTERNATIVE "", svm_vmexit_spec_ctrl, X86_FEATURE_SC_MSR_HVM
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
+ALTERNATIVE "", STR(call vmexit_virt_spec_ctrl), \
+X86_FEATURE_VIRT_SC_MSR_HVM
+
 stgi
 GLOBAL(svm_stgi_label)
 mov  %rsp,%rdi
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0849a9dc5f..2d0ad05111 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -610,6 +611,16 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu 
*v)
 svm_intercept_msr(v, MSR_SPEC_CTRL,
   cp->extd.ibrs ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
 
+/*
+ * Always trap write accesses to VIRT_SPEC_CTRL in order to cache the guest
+ * setting and avoid having to perform a rdmsr on vmexit to get the guest
+ * setting even if VIRT_SSBD is offered to Xen itself.
+ */
+svm_intercept_msr(v, MSR_VIRT_SPEC_CTRL,
+  cp->extd.virt_ssbd && cpu_has_virt_ssbd &&
+  !cpu_has_amd_ssbd ?
+  MSR_INTERCEPT_WRITE : MSR_INTERCEPT_RW);
+
 /* Give access to MSR_PRED_CMD if the guest has been told about it. */
 svm_intercept_msr(v, MSR_PRED_CMD,
   cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
@@ -3105,6 +3116,30 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 vmcb_set_vintr(vmcb, intr);
 }
 
+/* Called with GIF=0. */
+void vmexit_virt_spec_ctrl(void)
+{
+unsigned int val = opt_ssbd ?

[PATCH v5 0/3] amd/msr: implement MSR_VIRT_SPEC_CTRL for HVM guests

[Roger Pau Monne]

Hello,

The following series implements support for MSR_VIRT_SPEC_CTRL
(VIRT_SSBD) on different AMD CPU families.

Note that the support is added backwards, starting with the newer CPUs
that support MSR_SPEC_CTRL and moving to the older ones either using
MSR_VIRT_SPEC_CTRL or the SSBD bit in LS_CFG.

Xen is still free to use it's own SSBD setting, as the selection is
context switched on vm{entry,exit}.

On Zen2 and later, SPEC_CTRL.SSBD should exist and should be used in
preference to VIRT_SPEC_CTRL.SSBD.  However, for migration
compatibility, Xen offers VIRT_SSBD to guests (in the max cpuid policy,
not default) implemented in terms of SPEC_CTRL.SSBD.

On Fam15h thru Zen1, Xen exposes VIRT_SSBD to guests by default to
abstract away the model and/or hypervisor specific differences in
MSR_LS_CFG/MSR_VIRT_SPEC_CTRL.

So the implementation of VIRT_SSBD exposed to HVM guests will use one of
the following underlying mechanisms, in the preference order listed
below:

 * SPEC_CTRL.SSBD: patch 1
 * VIRT_SPEC_CTRL.SSBD: patch 2.
 * Non-architectural way using LS_CFG: patch 3.

NB: patch 3 introduces some logic in GIF=0 context, such logic has been
kept to a minimum due to the special context it's running on.

Roger Pau Monne (3):
  amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
  amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests
  amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

 CHANGELOG.md|   3 +
 xen/arch/x86/cpu/amd.c  | 121 +---
 xen/arch/x86/cpuid.c|  17 +++
 xen/arch/x86/hvm/hvm.c  |   1 +
 xen/arch/x86/hvm/svm/entry.S|   8 ++
 xen/arch/x86/hvm/svm/svm.c  |  39 +++
 xen/arch/x86/include/asm/amd.h  |   4 +
 xen/arch/x86/include/asm/cpufeatures.h  |   1 +
 xen/arch/x86/include/asm/msr.h  |  14 +++
 xen/arch/x86/msr.c  |  26 +
 xen/arch/x86/spec_ctrl.c|  12 +-
 xen/include/public/arch-x86/cpufeatureset.h |   2 +-
 12 files changed, 229 insertions(+), 19 deletions(-)

-- 
2.35.1

[PATCH v5 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

[Roger Pau Monne]

Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
families use different bits in LS_CFG, so exposing VIRT_SPEC_CTRL.SSBD
allows for an unified way of exposing SSBD support to guests on AMD
hardware that's compatible migration wise, regardless of what
underlying mechanism is used to set SSBD.

Note that on AMD Family 17h and Hygon Family 18h processors the value
of SSBD in LS_CFG is shared between threads on the same core, so
there's extra logic in order to synchronize the value and have SSBD
set as long as one of the threads in the core requires it to be set.
Such logic also requires extra storage for each thread state, which is
allocated at initialization time.

Do the context switching of the SSBD selection in LS_CFG between
hypervisor and guest in the same handler that's already used to switch
the value of VIRT_SPEC_CTRL.

Suggested-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Slightly change usage of val/opt_ssbd in
   vm{exit,entry}_virt_spec_ctrl.
 - Pull opt_ssbd outside of the for loop in amd_setup_legacy_ssbd().
 - Fix indentation.
 - Remove ASSERTs/BUG_ONs from GIF=0 context.

Changes since v3:
 - Align ssbd per-core struct to a cache line.
 - Open code a simple spinlock to avoid playing tricks with the lock
   detector.
 - s/ssbd_core/ssbd_ls_cfg/.
 - Fix log message wording.
 - Fix define name and remove comment.
 - Also handle Hygon processors (Fam18h).
 - Add changelog entry.

Changes since v2:
 - Fix codding style issues.
 - Use AMD_ZEN1_MAX_SOCKETS to define the max number of possible
   sockets in Zen1 systems.

Changes since v1:
 - Report legacy SSBD support using a global variable.
 - Use ro_after_init for ssbd_max_cores.
 - Handle boot_cpu_data.x86_num_siblings < 1.
 - Add comment regarding _irqsave usage in amd_set_legacy_ssbd.
---
 CHANGELOG.md   |   3 +
 xen/arch/x86/cpu/amd.c | 121 -
 xen/arch/x86/hvm/svm/svm.c |   4 ++
 xen/arch/x86/include/asm/amd.h |   4 ++
 xen/arch/x86/spec_ctrl.c   |   4 +-
 5 files changed, 118 insertions(+), 18 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6a7755d7b0..9a007e2513 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,6 +13,9 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Removed / support downgraded
  - dropped support for the (x86-only) "vesa-mtrr" and "vesa-remap" command 
line options
 
+### Added
+ - Support VIRT_SSBD feature for HVM guests on AMD.
+
 ## [4.16.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=staging) - 
2021-12-02
 
 ### Removed
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 4999f8be2b..27f4d51e86 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -48,6 +48,7 @@ boolean_param("allow_unsafe", opt_allow_unsafe);
 
 /* Signal whether the ACPI C1E quirk is required. */
 bool __read_mostly amd_acpi_c1e_quirk;
+bool __ro_after_init amd_legacy_ssbd;
 
 static inline int rdmsr_amd_safe(unsigned int msr, unsigned int *lo,
 unsigned int *hi)
@@ -685,23 +686,10 @@ void amd_init_lfence(struct cpuinfo_x86 *c)
  * Refer to the AMD Speculative Store Bypass whitepaper:
  * 
https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
  */
-void amd_init_ssbd(const struct cpuinfo_x86 *c)
+static bool set_legacy_ssbd(const struct cpuinfo_x86 *c, bool enable)
 {
int bit = -1;
 
-   if (cpu_has_ssb_no)
-   return;
-
-   if (cpu_has_amd_ssbd) {
-   /* Handled by common MSR_SPEC_CTRL logic */
-   return;
-   }
-
-   if (cpu_has_virt_ssbd) {
-   wrmsrl(MSR_VIRT_SPEC_CTRL, opt_ssbd ? SPEC_CTRL_SSBD : 0);
-   return;
-   }
-
switch (c->x86) {
case 0x15: bit = 54; break;
case 0x16: bit = 33; break;
@@ -715,20 +703,119 @@ void amd_init_ssbd(const struct cpuinfo_x86 *c)
if (rdmsr_safe(MSR_AMD64_LS_CFG, val) ||
({
val &= ~mask;
-   if (opt_ssbd)
+   if (enable)
val |= mask;
false;
}) ||
wrmsr_safe(MSR_AMD64_LS_CFG, val) ||
({
rdmsrl(MSR_AMD64_LS_CFG, val);
-   (val & mask) != (opt_ssbd * mask);
+   (val & mask) != (enable * mask);
}))
bit = -1;
}
 
-   if (bit < 0)
+   return bit >= 0;
+}
+
+void amd_init_ssbd(const struct cpuinfo_x86 *c)
+{
+   if (cpu_has_ssb_no)
+   return;
+
+   if (cpu_has_amd_ssbd) {
+   /* Handled by common MSR_SPEC_CTRL logic */
+   return;
+   }
+
+ 

Re: [PATCH v5 4/7] xen/arm: configure dom0less domain for enabling xenstore after boot

[Bertrand Marquis]

Hi,

> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
> 
> From: Luca Miccio 
> 
> Export evtchn_alloc_unbound and make it __must_check.
> 
> If "xen,enhanced" is enabled, then add to dom0less domains:
> 
> - the hypervisor node in device tree
> - the xenstore event channel
> 
> The xenstore event channel is also used for the first notification to
> let the guest know that xenstore has become available.
> 
> Signed-off-by: Luca Miccio 
> Signed-off-by: Stefano Stabellini 
> CC: Julien Grall 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> CC: Jan Beulich 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

[xen-unstable test] 170014: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail in 
169990 pass in 170014
 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat  fail pass in 169990
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 20 
guest-start/debianhvm.repeat fail pass in 169990

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

Re: osstest: blessed sabro boxes

[Roger Pau Monné]

On Tue, May 03, 2022 at 10:25:02AM +0200, Jan Beulich wrote:
> On 03.05.2022 09:50, Roger Pau Monné wrote:
> > Hello,
> > 
> > I've blessed the pair of sabro boxes for production after a successful
> > commission flight:
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/169857/
> > 
> > Note that the boxes don't seem to be able to boot in 32bit mode, see
> > the following flight where all 32bit jobs failed to install the host:
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/169986/
> > 
> > I have no idea what's causing this, and hence sabros will only be used
> > in 64bit mode.
> 
> You may have better luck with a PAE kernel (which would then also be
> able to use all of the memory rather than just about 1.7 Gb):
> 
> Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!

I'm not sure it's worth it, we have plenty of boxes that can do i386
just fine, so I think it's fine to have those as amd64 only.

Thanks, Roger.

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

[Juergen Gross]

On 29.04.22 23:10, 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.
+*/
+   free_irq(xs_init_irq, &xb_waitq);
+   }
+
/*
 * In the HVM case, xenbus_init() deferred its call to
 * xs_init() in case callbacks were not operational yet.
@@ -798,20 +810,22 @@ static int __init xenbus_probe_initcall(void)
  {
/*
 * Probe XenBus here in the XS_PV case, and also XS_HVM unless we
-* need to wait for the platform PCI device to come up.
+* need to wait for the platform PCI device to come up or
+* xen_store_interface is not ready.
 */
if (xen_store_domain_type == XS_PV ||
(xen_store_domain_type == XS_HVM &&
-!xs_hvm_defer_init_for_callback()))
+!xs_hvm_defer_init_for_callback() &&
+xen_store_interface != NULL))
xenbus_probe();
  
  	/*

-* For XS_LOCAL, spawn a thread which will wait for xenstored
-* or a xenstore-stubdom to be started, then probe. It will be
-* triggered when communication starts happening, by waiting
-* on xb_waitq.
+* For XS_LOCAL or when xen_store_interface is not ready, spawn a
+* thread which will wait for xenstored or a xenstore-stubdom to be
+* started, then probe.  It will be triggered when communication
+* starts happening, by waiting on xb_waitq.
 */
-   if (xen_store_domain_type == XS_LOCAL) {
+   if (xen_store_domain_type == XS_LOCAL || xen_store_interface == NULL) {
struct task_struct *probe_task;
  
  		probe_task = kthread_run(xenbus_probe_thread, NULL,

@@ -907,10 +921,25 @@ static struct notifier_block xenbus_resume_nb = {
.notifier_call = xenbus_resume_cb,
  };
  
+static irqreturn_t xenbus_late_init(int irq, void *unused)

+{
+   int err = 0;
+   uint64_t v = 0;
+
+   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+   if (err || !v || !~v)
+   return IRQ_HANDLED;
+   xen_store_gfn = (unsigned long)v;
+
+   wake_up(&xb_waitq);
+   return IRQ_HANDLED;
+}
+
  static int __init xenbus_init(void)
  {
int err;
uint64_t v = 0;
+   bool wait = false;
xen_store_domain_type = XS_UNKNOWN;
  
  	if (!xen_domain())

@@ -959,23 +988,42 @@ static int __init xenbus_init(void)
 *
 * Also recognize all bits set as an invalid value.
 */
-   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. */
  #if BITS_PER_LONG == 32
-   if (v > ULONG_MAX) {
-   pr_err("%s: cannot handle HVM_PARAM_STORE_PFN=%llx > 
ULONG_MAX\n",
-  __func__, v);
-   err = -EINVAL;
-   goto out_error;
-   }
+   if (v > ULONG_MAX) {
+   pr_err(

Re: [PATCH v5 5/7] xenstored: send an evtchn notification on introduce_domain

[Juergen Gross]

On 29.04.22 22:57, Stefano Stabellini wrote:

From: Luca Miccio 

When xs_introduce_domain is called, send out a notification on the
xenstore event channel so that any (dom0less) domain waiting for the
xenstore interface to be ready can continue with the initialization.
Before sending the notification, clear XS_CONNECTION_STATE_RECONNECTING.

The extra notification is harmless for domains that don't require it.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: Juergen Gross 
CC: Julien Grall 
---
I dropped the Reviewed-by tags due to the connect = 0 change. Julien
also suggested it would be a good idea to add a clarification statement
about the usage of XS_CONNECTION_STATE_RECONNECTING in the header files
but I wasn't sure what to write. Please advise and I am happy to include
a statement in the next version.

Changes in v5:
- reset XS_CONNECTION_STATE_RECONNECTING before notifying the domU

Changes in v2:
- drop the new late_init parameter
---
  tools/xenstore/xenstored_domain.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/tools/xenstore/xenstored_domain.c 
b/tools/xenstore/xenstored_domain.c
index ae065fcbee..7bb8c64d33 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -493,6 +493,10 @@ static struct domain *introduce_domain(const void *ctx,
/* Now domain belongs to its connection. */
talloc_steal(domain->conn, domain);
  
+		/* Notify the domain that xenstore is available */

+   interface->connection = 0x0;


Please use XENSTORE_CONNECTED instead of 0x0.


+   xenevtchn_notify(xce_handle, domain->port);
+
if (!is_master_domain && !restore)
fire_watches(NULL, ctx, "@introduceDomain", NULL,
 false, NULL);



Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v5 6/7] tools: add example application to initialize dom0less PV drivers

[Juergen Gross]

On 29.04.22 22:57, Stefano Stabellini wrote:

From: Luca Miccio 

Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.

The application sets XS_CONNECTION_STATE_RECONNECTING on the xenstore
page before calling xs_introduce_domain to signal that the connection is
not ready yet to be used. XS_CONNECTION_STATE_RECONNECTING is reset soon
after by xenstored.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: Wei Liu 
CC: Anthony PERARD 
CC: Juergen Gross 
---
Changes in v5:
- set XS_CONNECTION_STATE_RECONNECTING before xs_introduce_domain

Changes in v4:
- only alloc xs page (no other magic pages)
- add xenstore permissions
- check all return values
- rename restore_xenstore to create_xenstore
- set target_memkb
- set start_time properly
- close xs transaction on error
- call xc_dom_gnttab_seed instead of xc_dom_gnttab_init
- xs_open instead of xs_daemon_open

Changes in v3:
- handle xenstore errors
- add an in-code comment about xenstore entries
- less verbose output
- clean-up error path in main

Changes in v2:
- do not set HVM_PARAM_STORE_EVTCHN twice
- rename restore_xenstore to create_xenstore
- increase maxmem

connection reconnecting
---
  tools/helpers/Makefile|  13 ++
  tools/helpers/init-dom0less.c | 341 ++
  2 files changed, 354 insertions(+)
  create mode 100644 tools/helpers/init-dom0less.c

diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 7f6c422440..8d78ab1e90 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -10,6 +10,9 @@ ifeq ($(CONFIG_Linux),y)
  ifeq ($(CONFIG_X86),y)
  PROGS += init-xenstore-domain
  endif
+ifeq ($(CONFIG_ARM),y)
+PROGS += init-dom0less
+endif
  endif
  
  XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o

@@ -26,6 +29,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenstore)
  $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
  $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h
  
+INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o

+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
+
  .PHONY: all
  all: $(PROGS)
  
@@ -35,6 +45,9 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)

  init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenguest) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
  
+init-dom0less: $(INIT_DOM0LESS_OBJS)

+   $(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenevtchn) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) 
$(LDLIBS_libxenlight) $(LDLIBS_libxenguest) $(LDLIBS_libxenforeignmemory) 
$(APPEND_LDFLAGS)
+
  .PHONY: install
  install: all
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
new file mode 100644
index 00..a99398e928
--- /dev/null
+++ b/tools/helpers/init-dom0less.c
@@ -0,0 +1,341 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "init-dom-json.h"
+
+#define XS_CONNECTION_STATE_OFFSET   (2068/4)
+#define XS_CONNECTION_STATE_RECONNECTING 0x1


Why don't you use the xs_wire.h header instead?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[Roger Pau Monné]

On Tue, May 03, 2022 at 10:17:44AM +0200, Jan Beulich wrote:
> On 02.05.2022 17:20, Roger Pau Monne wrote:
> > 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
> 
> I'm puzzled by "almost" - is there a pattern of which ones aren't
> converted?

This is the list of the ones that aren't converted:

__x86_indirect_thunk_r11
s3_resume
start
__image_base__
__high_start
wakeup_stack
wakeup_stack_start
handle_exception
dom_crash_sync_extable
common_interrupt
__x86_indirect_thunk_rbx
__x86_indirect_thunk_rcx
__x86_indirect_thunk_rax
__x86_indirect_thunk_rdx
__x86_indirect_thunk_rbp
__x86_indirect_thunk_rsi
__x86_indirect_thunk_rdi
__x86_indirect_thunk_r8
__x86_indirect_thunk_r9
__x86_indirect_thunk_r10
__x86_indirect_thunk_r12
__x86_indirect_thunk_r13
__x86_indirect_thunk_r14
__x86_indirect_thunk_r15

I assume there's some kind of pattern, but I haven't yet been able to
spot where triggers the conversion from global to local in lld.

> Also "last linking step" is ambiguous, as we link three binaries and
> aiui the issue is present on every of these passes. May I suggest
> "... when linking actual executables" or (still somewhat ambiguous)
> "... when linking final binaries"?
> 
> > 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.
> 
> Perhaps a map file (like we use for shared libraries in tools/) would
> allow doing so? But of course this would want to be machine-generated,
> not manually maintained.
> 
> Have you gained any insight into _why_ they are doing what they do?

I've informally asked on IRC but got no reply.  I've now created this:

https://discourse.llvm.org/t/conversion-of-text-symbols-from-global-to-local

> > 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.
> 
> If, as the last paragraph of the description is worded, you did this
> just once (as a prereq), I could see this working.

Yes, my comment was about splitting the:

$(NM) -pa --format=bsd $< | awk '{ if($$2 == "T") print $$3}' \
  > $(@D)/.$(@F).global-syms

rune into a separate $(TARGET)-syms.global-syms target or some such.
Not sure it's really worth it.

> Otherwise (as you
> have it now, with it done 3 times) it would first require splitting
> the linking rules into many separate ones (which has been the plan
> anyway, but so far I didn't get to it).
> 
> > --- 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)/.

[PATCH 0/3] Spectre BHB follow up

[Bertrand Marquis]

Following up the handling of Spectre BHB on Arm (XSA-398), this serie
contain several changes which were not needed in the XSA patches but
should be done in Xen:
- Sync sysregs and cpuinfo with latest version of Linux (5.18-rc3)
- Advertise both workaround 1 and 3 if we apply workaround 3 as it
  handle both cases. This will keep the same behaviour for guests which
  are not updated to support workaround 3.
- Add sb instruction support. Some newer generations of CPU
  (Neoverse-N2) do support the instruction so add support for it in Xen.

Bertrand Marquis (3):
  xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3
  xen/arm: Advertise workaround 1 if we apply 3
  xen/arm: Add sb instruction support

 xen/arch/arm/arm64/cpufeature.c  | 18 +-
 xen/arch/arm/cpuerrata.c | 14 +
 xen/arch/arm/include/asm/arm32/macros.h  |  8 +++
 xen/arch/arm/include/asm/arm64/macros.h  | 18 ++
 xen/arch/arm/include/asm/arm64/sysregs.h | 76 
 xen/arch/arm/include/asm/cpufeature.h| 17 --
 xen/arch/arm/include/asm/macros.h|  9 ---
 xen/arch/arm/vsmc.c  | 11 +++-
 8 files changed, 141 insertions(+), 30 deletions(-)

-- 
2.25.1

[PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3

[Bertrand Marquis]

Sync arm64 sysreg bit shift definitions with status of Linux kernel as
of 5.18-rc3 version (linux commit b2d229d4ddb1).
Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
sanitization of ISAR2 registers.
Complete AA64ISAR2 and AA64MMFR1 with more fields.
While there add a comment for MMFR bitfields as for other registers in
the cpuinfo structure definition.

Signed-off-by: Bertrand Marquis 
---
 xen/arch/arm/arm64/cpufeature.c  | 18 +-
 xen/arch/arm/include/asm/arm64/sysregs.h | 76 
 xen/arch/arm/include/asm/cpufeature.h| 14 -
 3 files changed, 91 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
index 6e5d30dc7b..d9039d37b2 100644
--- a/xen/arch/arm/arm64/cpufeature.c
+++ b/xen/arch/arm/arm64/cpufeature.c
@@ -143,6 +143,16 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
ARM64_FTR_END,
 };
 
+static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, 
ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
+   ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+  FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
+   ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+  FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 
0),
+   ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
+   ARM64_FTR_END,
+};
+
 static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_CSV3_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_CSV2_SHIFT, 4, 0),
@@ -158,8 +168,8 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL3_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL2_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_EL1_64BIT_ONLY),
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_EL0_64BIT_ONLY),
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
ARM64_FTR_END,
 };
 
@@ -197,7 +207,7 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_ECV_SHIFT, 4, 0),
+   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_ECV_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_FGT_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_EXS_SHIFT, 4, 0),
/*
@@ -243,6 +253,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
+   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR1_AFP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR1_ETS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR1_TWED_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR1_XNX_SHIFT, 4, 0),
@@ -588,6 +599,7 @@ void update_system_features(const struct cpuinfo_arm *new)
 
SANITIZE_ID_REG(isa64, 0, aa64isar0);
SANITIZE_ID_REG(isa64, 1, aa64isar1);
+   SANITIZE_ID_REG(isa64, 2, aa64isar2);
 
SANITIZE_ID_REG(zfr64, 0, aa64zfr0);
 
diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h 
b/xen/arch/arm/include/asm/arm64/sysregs.h
index eac08ed33f..54670084c3 100644
--- a/xen/arch/arm/include/asm/arm64/sysregs.h
+++ b/xen/arch/arm/include/asm/arm64/sysregs.h
@@ -144,6 +144,30 @@
 
 /* id_aa64isar2 */
 #define ID_AA64ISAR2_CLEARBHB_SHIFT 28
+#define ID_AA64ISAR2_APA3_SHIFT 12
+#define ID_AA64ISAR2_GPA3_SHIFT 8
+#define ID_AA64ISAR2_RPRES_SHIFT4
+#define ID_AA64ISAR2_WFXT_SHIFT 0
+
+#define ID_AA64ISAR2_RPRES_8BIT 0x0
+#define ID_AA64ISAR2_RPRES_12BIT0x1
+/*
+ * Value 0x1 has been removed from the architecture, and is
+ * reserved, but has not yet been removed from the ARM ARM
+ * as of ARM DDI 0487G.b.
+ */
+#define ID_AA64ISAR2_WFXT_NI0x0
+#define ID_AA64ISAR2_WFXT_SUPPORTED 0x2
+
+#define ID_AA64ISAR2_APA3_NI  0x0
+#define ID_AA64ISAR2_APA3_ARCHITECTED 0x1
+#define ID_AA64ISAR2_APA3_ARCH_EPAC   0x2
+#define ID_AA64ISAR2_A

[PATCH 2/3] xen/arm: Advertise workaround 1 if we apply 3

[Bertrand Marquis]

SMCC_WORKAROUND_3 is handling both Spectre v2 and spectre BHB.
So when a guest is asking if we support workaround 1, tell yes if we
apply workaround 3 on exception entry as it handles it.

This will allow guests not supporting Spectre BHB but impacted by
spectre v2 to still handle it correctly.
The modified behaviour is coherent with what the Linux kernel does in
KVM for guests.

While there use ARM_SMCCC_SUCCESS instead of 0 for the return code value
for workaround detection to be coherent with Workaround 2 handling.

Signed-off-by: Bertrand Marquis 
---
 xen/arch/arm/vsmc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index b633ff2fe8..676740ef15 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -104,8 +104,13 @@ static bool handle_arch(struct cpu_user_regs *regs)
 switch ( arch_func_id )
 {
 case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
-if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
-ret = 0;
+/*
+ * Workaround 3 is also mitigating spectre v2 so advertise that we
+ * support Workaround 1 if we do Workaround 3 on exception entry.
+ */
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) ||
+ cpus_have_cap(ARM_WORKAROUND_BHB_SMCC_3) )
+ret = ARM_SMCCC_SUCCESS;
 break;
 case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
 switch ( get_ssbd_state() )
@@ -126,7 +131,7 @@ static bool handle_arch(struct cpu_user_regs *regs)
 break;
 case ARM_SMCCC_ARCH_WORKAROUND_3_FID:
 if ( cpus_have_cap(ARM_WORKAROUND_BHB_SMCC_3) )
-ret = 0;
+ret = ARM_SMCCC_SUCCESS;
 break;
 }
 
-- 
2.25.1

[PATCH 3/3] xen/arm: Add sb instruction support

[Bertrand Marquis]

This patch is adding sb instruction support when it is supported by a
CPU on arm64.
To achieve this, the "sb" macro is moved to sub-arch macros.h so that we
can use sb instruction when available through alternative on arm64 and
keep the current behaviour on arm32.
A new cpuerrata capability is introduced to enable the alternative
code for sb when the support is detected using isa64 coprocessor
register.
The sb instruction is encoded using its hexadecimal value.

Signed-off-by: Bertrand Marquis 
---
 xen/arch/arm/cpuerrata.c| 14 ++
 xen/arch/arm/include/asm/arm32/macros.h |  8 
 xen/arch/arm/include/asm/arm64/macros.h | 18 ++
 xen/arch/arm/include/asm/cpufeature.h   |  3 ++-
 xen/arch/arm/include/asm/macros.h   |  9 -
 5 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index ae649d16ef..e744abe800 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -458,6 +458,13 @@ static bool has_ssbd_mitigation(const struct 
arm_cpu_capabilities *entry)
 }
 #endif
 
+#ifdef CONFIG_ARM_64
+static bool has_sb_instruction(const struct arm_cpu_capabilities *entry)
+{
+return system_cpuinfo.isa64.sb;
+}
+#endif
+
 #define MIDR_RANGE(model, min, max) \
 .matches = is_affected_midr_range,  \
 .midr_model = model,\
@@ -674,6 +681,13 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 .capability = ARM64_WORKAROUND_AT_SPECULATE,
 MIDR_ALL_VERSIONS(MIDR_CORTEX_A55),
 },
+#ifdef CONFIG_ARM_64
+{
+.desc = "Speculation barrier (SB)",
+.capability = ARM64_HAS_SB,
+.matches = has_sb_instruction,
+},
+#endif
 {},
 };
 
diff --git a/xen/arch/arm/include/asm/arm32/macros.h 
b/xen/arch/arm/include/asm/arm32/macros.h
index a4e20aa520..cf0ddad52b 100644
--- a/xen/arch/arm/include/asm/arm32/macros.h
+++ b/xen/arch/arm/include/asm/arm32/macros.h
@@ -5,4 +5,12 @@
 mov pc, lr
 .endm
 
+/*
+ * Speculative barrier
+ */
+.macro sb
+dsb nsh
+isb
+.endm
+
 #endif /* __ASM_ARM_ARM32_MACROS_H */
diff --git a/xen/arch/arm/include/asm/arm64/macros.h 
b/xen/arch/arm/include/asm/arm64/macros.h
index 140e223b4c..e639cec400 100644
--- a/xen/arch/arm/include/asm/arm64/macros.h
+++ b/xen/arch/arm/include/asm/arm64/macros.h
@@ -1,6 +1,24 @@
 #ifndef __ASM_ARM_ARM64_MACROS_H
 #define __ASM_ARM_ARM64_MACROS_H
 
+#include 
+
+/*
+ * Speculative barrier
+ */
+.macro sb
+alternative_if_not ARM64_HAS_SB
+dsb nsh
+isb
+alternative_else
+/*
+ * SB encoding as given in chapter C6.2.264 of ARM ARM (DDI 0487H.a).
+ */
+.inst 0xd50330ff
+nop
+alternative_endif
+.endm
+
 /*
  * @dst: Result of get_cpu_info()
  */
diff --git a/xen/arch/arm/include/asm/cpufeature.h 
b/xen/arch/arm/include/asm/cpufeature.h
index 4719de47f3..9370805900 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -67,8 +67,9 @@
 #define ARM_WORKAROUND_BHB_LOOP_24 13
 #define ARM_WORKAROUND_BHB_LOOP_32 14
 #define ARM_WORKAROUND_BHB_SMCC_3 15
+#define ARM64_HAS_SB 16
 
-#define ARM_NCAPS   16
+#define ARM_NCAPS   17
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/arch/arm/include/asm/macros.h 
b/xen/arch/arm/include/asm/macros.h
index 1aa373760f..91ea3505e4 100644
--- a/xen/arch/arm/include/asm/macros.h
+++ b/xen/arch/arm/include/asm/macros.h
@@ -5,15 +5,6 @@
 # error "This file should only be included in assembly file"
 #endif
 
-/*
- * Speculative barrier
- * XXX: Add support for the 'sb' instruction
- */
-.macro sb
-dsb nsh
-isb
-.endm
-
 #if defined (CONFIG_ARM_32)
 # include 
 #elif defined(CONFIG_ARM_64)
-- 
2.25.1

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

[Luca Fancellu]

> On 2 May 2022, at 14:53, Daniel P. Smith  wrote:
> 
> 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.

I’ve built this patch on arm (changing err to rc), everything looks fine, so 
with that
addressed:

Reviewed-by: Luca Fancellu 



> 
> v/r,
> dps
> 
> 

[ovmf test] 170030: regressions - FAIL

[osstest service owner]

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

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  776 attempts
Testing same since   16  2022-05-02 17:12:56 Z0 days   14 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 v4 01/21] AMD/IOMMU: correct potentially-UB shifts

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:30:33AM +0200, Jan Beulich wrote:
> Recent changes (likely 5fafa6cf529a ["AMD/IOMMU: have callers specify
> the target level for page table walks"]) have made Coverity notice a
> shift count in iommu_pde_from_dfn() which might in theory grow too
> large. While this isn't a problem in practice, address the concern
> nevertheless to not leave dangling breakage in case very large
> superpages would be enabled at some point.
> 
> Coverity ID: 1504264
> 
> While there also address a similar issue in set_iommu_ptes_present().
> It's not clear to me why Coverity hasn't spotted that one.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

> ---
> v4: New.
> 
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -89,11 +89,11 @@ static unsigned int set_iommu_ptes_prese
> bool iw, bool ir)
>  {
>  union amd_iommu_pte *table, *pde;
> -unsigned int page_sz, flush_flags = 0;
> +unsigned long page_sz = 1UL << (PTE_PER_TABLE_SHIFT * (pde_level - 1));

Seeing the discussion from Andrews reply, nr_pages might be more
appropriate while still quite short.

I'm not making my Rb conditional to that change though.

Thanks, Roger.

Re: [PATCH v5 1/7] xen/dt: of_property_read_string return -ENODATA when !length

[Luca Fancellu]

> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> When the length of the string is zero of_property_read_string should
> return -ENODATA according to the description of the function.
> 
> However, of_property_read_string doesn't check prop->length. If
> prop->length is zero, return -ENODATA.
> 
> Without this patch the following command in u-boot:
> 
> fdt set /chosen/node property-name
> 
> results in of_property_read_string returning -EILSEQ when attempting to
> read property-name. With this patch, it returns -ENODATA as expected.
> 
> This commit is a backport of:
> https://lore.kernel.org/xen-devel/20220416003028.1315268-1-sstabell...@kernel.org/
> 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Luca Fancellu 

> ---
> Changes in v5:
> - backport from Linux, I don't have the commit id yet so I used an LKML
>  link instead for now

Re: [PATCH v4 02/21] IOMMU: simplify unmap-on-error in iommu_map()

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:32:10AM +0200, Jan Beulich wrote:
> As of 68a8aa5d7264 ("iommu: make map and unmap take a page count,
> similar to flush") there's no need anymore to have a loop here.
> 
> Suggested-by: Roger Pau Monné 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

I wonder whether we should have a macro to ignore returns from
__must_check attributed functions.  Ie:

#define IGNORE_RETURN(exp) while ( exp ) break;

As to avoid confusion (and having to reason) whether the usage of
while is correct.  I always find it confusing to assert such loop
expressions are correct.

Thanks, Roger.

Re: [PATCH v5 2/7] xen/arm: implement domU extended regions

[Luca Fancellu]

> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> Implement extended regions for dom0less domUs. The implementation is
> based on the libxl implementation.
> 
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v5:
> - print the domain
> - coding style
> - simplify the code in find_domU_holes
> - return error if no regions allocated in find_domU_holes
> - use ROUNDUP
> - uint64_t/paddr_t
> ---
> xen/arch/arm/domain_build.c | 56 +++--
> 1 file changed, 48 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8be01678de..34d3e5ce30 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1324,6 +1324,37 @@ out:
> return res;
> }
> 
> +static int __init find_domU_holes(const struct kernel_info *kinfo,
> +  struct meminfo *ext_regions)
> +{
> +unsigned int i;
> +paddr_t bankend;
> +const paddr_t bankbase[] = GUEST_RAM_BANK_BASES;
> +const paddr_t banksize[] = GUEST_RAM_BANK_SIZES;
> +int res = -ENOENT;
> +
> +for ( i = 0; i < GUEST_RAM_BANKS; i++ )
> +{
> +struct membank *ext_bank = 
> &(ext_regions->bank[ext_regions->nr_banks]);
> +
> +ext_bank->start = ROUNDUP(bankbase[i] + kinfo->mem.bank[i].size,
> +  SZ_2M);

NIT: there is no need anymore to break the line as SZ_2M will fit in the line 
length

> +
> +bankend = ~0ULL >> (64 - p2m_ipa_bits);
> +bankend = min(bankend, bankbase[i] + banksize[i] - 1);
> +if ( bankend > ext_bank->start )
> +ext_bank->size = bankend - ext_bank->start + 1;
> +
> +/* 64MB is the minimum size of an extended region */
> +if ( ext_bank->size < MB(64) )
> +continue;
> +ext_regions->nr_banks++;
> +res = 0;
> +}
> +
> +return res;
> +}
> +
> static int __init make_hypervisor_node(struct domain *d,
>const struct kernel_info *kinfo,
>int addrcells, int sizecells)
> @@ -1360,12 +1391,13 @@ static int __init make_hypervisor_node(struct domain 
> *d,
> 
> if ( !opt_ext_regions )
> {
> -printk(XENLOG_INFO "The extended regions support is disabled\n");
> +printk(XENLOG_INFO "%pd: extended regions support is disabled\n", d);
> nr_ext_regions = 0;
> }
> else if ( is_32bit_domain(d) )
> {
> -printk(XENLOG_WARNING "The extended regions are only supported for 
> 64-bit guest currently\n");
> +printk(XENLOG_WARNING "%pd: extended regions are only supported for 
> 64-bit guest currently\n",
> +   d);

NIT: Something like that won’t exceed 80 chars:
printk(XENLOG_WARNING
  "%pd: extended regions not supported for 32-bit guests\n", d);


Reviewed-by: Luca Fancellu 

Re: [PATCH v5 1/7] xen/dt: of_property_read_string return -ENODATA when !length

[Bertrand Marquis]

Hi Stefano,

> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> When the length of the string is zero of_property_read_string should
> return -ENODATA according to the description of the function.
> 
> However, of_property_read_string doesn't check prop->length. If
> prop->length is zero, return -ENODATA.
> 
> Without this patch the following command in u-boot:
> 
> fdt set /chosen/node property-name
> 
> results in of_property_read_string returning -EILSEQ when attempting to
> read property-name. With this patch, it returns -ENODATA as expected.
> 
> This commit is a backport of:
> https://lore.kernel.org/xen-devel/20220416003028.1315268-1-sstabell...@kernel.org/
> 
> Signed-off-by: Stefano Stabellini 
Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

Re: [PATCH v5 7/7] docs: document dom0less + PV drivers

[Luca Fancellu]

> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> Document how to use the feature and how the implementation works.
> 
> Signed-off-by: Stefano Stabellini 

Reviewed-by Luca Fancellu 

[ovmf test] 170038: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  777 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

Re: [PATCH v5 7/7] docs: document dom0less + PV drivers

[Luca Fancellu]

> On 3 May 2022, at 11:35, Luca Fancellu  wrote:
> 
> 
> 
>> On 29 Apr 2022, at 21:57, Stefano Stabellini  wrote:
>> 
>> From: Stefano Stabellini 
>> 
>> Document how to use the feature and how the implementation works.
>> 
>> Signed-off-by: Stefano Stabellini 
> 
> Reviewed-by Luca Fancellu 
> 

Ops, sorry, typo:

Reviewed-by: Luca Fancellu 

[PATCH v6 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 v6:
- readded the setting of is_privileged in flask_set_system_active()
- clarified comment on is_privileged in flask_set_system_active()
- added ASSERT on is_privileged and self_sid in flask_set_system_active()
- fixed err code returned on Arm for xsm_set_system_active() panic message

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  | 32 +-
 xen/xsm/flask/policy/initial_sids  |  1 +
 11 files changed, 79 insertions(+), 2 deletions(-)

-- 
2.20.1

[PATCH v6 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   | 23 +++
 7 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..39a654926d 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", rc);
+
 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_do

[PATCH v6 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  | 9 -
 xen/xsm/flask/policy/initial_sids  | 1 +
 5 files changed, 17 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 b93101191e..734d9de16a 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,9 +188,14 @@ 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(d->is_privileged);
+ASSERT(dsec->sid == SECINITSID_XENBOOT);
+ASSERT(dsec->self_sid == SECINITSID_XENBOOT);
 
 if ( d->domain_id != DOMID_IDLE )
 {
@@ -205,6 +210,8 @@ static int cf_check flask_set_system_active(void)
  */
 d->is_privileged = false;
 
+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

Re: [PATCH v5 2/7] xen/arm: implement domU extended regions

[Oleksandr Tyshchenko]

On Fri, Apr 29, 2022 at 11:58 PM Stefano Stabellini 
wrote:

> From: Stefano Stabellini 
>

Hello Stefano

[Sorry for the possible format issues]



>
> Implement extended regions for dom0less domUs. The implementation is
> based on the libxl implementation.
>
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v5:
> - print the domain
> - coding style
> - simplify the code in find_domU_holes
> - return error if no regions allocated in find_domU_holes
> - use ROUNDUP
> - uint64_t/paddr_t
> ---
>  xen/arch/arm/domain_build.c | 56 +++--
>  1 file changed, 48 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8be01678de..34d3e5ce30 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1324,6 +1324,37 @@ out:
>  return res;
>  }
>
> +static int __init find_domU_holes(const struct kernel_info *kinfo,
> +  struct meminfo *ext_regions)
> +{
> +unsigned int i;
> +paddr_t bankend;
> +const paddr_t bankbase[] = GUEST_RAM_BANK_BASES;
> +const paddr_t banksize[] = GUEST_RAM_BANK_SIZES;
> +int res = -ENOENT;
> +
> +for ( i = 0; i < GUEST_RAM_BANKS; i++ )
> +{
> +struct membank *ext_bank =
> &(ext_regions->bank[ext_regions->nr_banks]);
> +
> +ext_bank->start = ROUNDUP(bankbase[i] + kinfo->mem.bank[i].size,
> +  SZ_2M);
> +
> +bankend = ~0ULL >> (64 - p2m_ipa_bits);
> +bankend = min(bankend, bankbase[i] + banksize[i] - 1);
> +if ( bankend > ext_bank->start )
> +ext_bank->size = bankend - ext_bank->start + 1;
> +
> +/* 64MB is the minimum size of an extended region */
> +if ( ext_bank->size < MB(64) )
> +continue;
> +ext_regions->nr_banks++;
> +res = 0;
> +}
> +
> +return res;
> +}
> +
>  static int __init make_hypervisor_node(struct domain *d,
> const struct kernel_info *kinfo,
> int addrcells, int sizecells)
> @@ -1360,12 +1391,13 @@ static int __init make_hypervisor_node(struct
> domain *d,
>
>  if ( !opt_ext_regions )
>


ok, I think, the comment for *opt_ext_regions* at the beginning of this
file and the description for *ext_regions* in xen-command-line.pandoc need
to be updated,
as they both mention Dom0 only.




>  {
> -printk(XENLOG_INFO "The extended regions support is disabled\n");
> +printk(XENLOG_INFO "%pd: extended regions support is disabled\n",
> d);
>  nr_ext_regions = 0;
>  }
>  else if ( is_32bit_domain(d) )
>  {
> -printk(XENLOG_WARNING "The extended regions are only supported
> for 64-bit guest currently\n");
> +printk(XENLOG_WARNING "%pd: extended regions are only supported
> for 64-bit guest currently\n",
> +   d);
>  nr_ext_regions = 0;
>  }
>  else
> @@ -1374,13 +1406,21 @@ static int __init make_hypervisor_node(struct
> domain *d,
>  if ( !ext_regions )
>  return -ENOMEM;
>
> -if ( !is_iommu_enabled(d) )
> -res = find_unallocated_memory(kinfo, ext_regions);
> +if ( is_domain_direct_mapped(d) )
> +{
> +if ( !is_iommu_enabled(d) )
> +res = find_unallocated_memory(kinfo, ext_regions);
> +else
> +res = find_memory_holes(kinfo, ext_regions);
> +}
>  else
> -res = find_memory_holes(kinfo, ext_regions);
> +{
> +res = find_domU_holes(kinfo, ext_regions);
> +}
>
>  if ( res )
> -printk(XENLOG_WARNING "Failed to allocate extended
> regions\n");
> +printk(XENLOG_WARNING "%pd: failed to allocate extended
> regions\n",
> +   d);
>  nr_ext_regions = ext_regions->nr_banks;
>  }
>
> @@ -1401,8 +1441,8 @@ static int __init make_hypervisor_node(struct domain
> *d,
>  u64 start = ext_regions->bank[i].start;
>  u64 size = ext_regions->bank[i].size;
>
> -printk("Extended region %d: %#"PRIx64"->%#"PRIx64"\n",
> -   i, start, start + size);
> +printk("%pd: extended region %d: %#"PRIx64"->%#"PRIx64"\n",
> +   d, i, start, start + size);
>
>  dt_child_set_range(&cells, addrcells, sizecells, start, size);
>  }
> --
> 2.25.1
>
>
>

-- 
Regards,

Oleksandr Tyshchenko

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

[Daniel P. Smith]

On 5/3/22 05:43, Luca Fancellu wrote:
> 
> 
>> On 2 May 2022, at 14:53, Daniel P. Smith  
>> wrote:
>>
>> 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.
> 
> I’ve built this patch on arm (changing err to rc), everything looks fine, so 
> with that
> addressed:
> 
> Reviewed-by: Luca Fancellu 

Thank you and my apologies for not adding your review-by this morning. I
had v6 queued to go out last night and missed this email before releasing.

[ovmf test] 170041: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  778 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

[seabios test] 170031: tolerable FAIL - PUSHED

[osstest service owner]

flight 170031 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170031/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169167
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169167
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169167
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169167
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169167
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  dc88f9b72df52b22c35b127b80c487e0b6fca4af
baseline version:
 seabios  01774004c7f7fdc9c1e8f1715f70d3b913f8d491

Last test of basis   169167  2022-04-04 21:41:47 Z   28 days
Testing same since   170031  2022-05-03 08:44:11 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-qemuu-freebsd11-amd64   pass
 test-amd64-amd64-qemuu-freebsd12-amd64   pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictpass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   0177400..dc88f9b  dc88f9b72df52b22c35b127b80c487e0b6fca4af -> 
xen-tested-master

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

[Luca Fancellu]

> On 3 May 2022, at 12:30, Daniel P. Smith  wrote:
> 
> On 5/3/22 05:43, Luca Fancellu wrote:
>> 
>> 
>>> On 2 May 2022, at 14:53, Daniel P. Smith  
>>> wrote:
>>> 
>>> 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.
>> 
>> I’ve built this patch on arm (changing err to rc), everything looks fine, so 
>> with that
>> addressed:
>> 
>> Reviewed-by: Luca Fancellu 
> 
> Thank you and my apologies for not adding your review-by this morning. I
> had v6 queued to go out last night and missed this email before releasing.
> 

Hi Daniel,

It’s ok I will put it again in the new serie.

Cheers,
Luca

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

[Luca Fancellu]

> On 3 May 2022, at 12:17, Daniel P. Smith  wrote:
> 
> 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 


Reviewed-by: Luca Fancellu 

Cheers,
Luca

Re: [PATCH v4 04/21] IOMMU: have iommu_{,un}map() split requests into largest possible chunks

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:33:32AM +0200, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -307,11 +338,10 @@ int iommu_map(struct domain *d, dfn_t df
>  if ( !d->is_shutting_down && printk_ratelimit() )
>  printk(XENLOG_ERR
> "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn" 
> failed: %d\n",
> -   d->domain_id, dfn_x(dfn_add(dfn, i)),
> -   mfn_x(mfn_add(mfn, i)), rc);
> +   d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);

Since you are already adjusting the line, I wouldn't mind if you also
switched to use %pd at once (and in the same adjustment done to
iommu_unmap).

>  
>  /* while statement to satisfy __must_check */
> -while ( iommu_unmap(d, dfn, i, flush_flags) )
> +while ( iommu_unmap(d, dfn0, i, flush_flags) )

To match previous behavior you likely need to use i + (1UL << order),
so pages covered by the map_page call above are also taken care in the
unmap request?

With that fixed:

Reviewed-by: Roger Pau Monné 

(Feel free to adjust the printks to use %pd or not, that's not a
requirement for the Rb)

Thanks, Roger.

[ovmf test] 170043: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  779 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

Re: [PATCH] x86/PAT: have pat_enabled() properly reflect state when running on e.g. Xen

[Juergen Gross]

On 28.04.22 16:50, Jan Beulich wrote:

The latest with commit bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT
with pat_enabled()") pat_enabled() returning false (because of PAT
initialization being suppressed in the absence of MTRRs being announced
to be available) has become a problem: The i915 driver now fails to
initialize when running PV on Xen (i915_gem_object_pin_map() is where I
located the induced failure), and its error handling is flaky enough to
(at least sometimes) result in a hung system.

Yet even beyond that problem the keying of the use of WC mappings to
pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
graphics frame buffer accesses would have been quite a bit less
performant than possible.

Arrange for the function to return true in such environments, without
undermining the rest of PAT MSR management logic considering PAT to be
disabled: Specifically, no writes to the PAT MSR should occur.

For the new boolean to live in .init.data, init_cache_modes() also needs
moving to .init.text (where it could/should have lived already before).

Signed-off-by: Jan Beulich 


I think this approach isn't the best way to tackle the issue.

It can be solved rather easily by not deriving the supported caching
modes via pat_enabled(), but by adding specific functions to query
the needed caching mode from the PAT translation tables, and to use
those functions instead of pat_enabled().

I'm preparing a patch for that purpose.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v4 05/21] IOMMU/x86: restrict IO-APIC mappings for PV Dom0

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:34:23AM +0200, Jan Beulich wrote:
> While already the case for PVH, there's no reason to treat PV
> differently here, though of course the addresses get taken from another
> source in this case. Except that, to match CPU side mappings, by default
> we permit r/o ones. This then also means we now deal consistently with
> IO-APICs whose MMIO is or is not covered by E820 reserved regions.
> 
> Signed-off-by: Jan Beulich 
> ---
> [integrated] v1: Integrate into series.
> [standalone] v2: Keep IOMMU mappings in sync with CPU ones.
> 
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -275,12 +275,12 @@ void iommu_identity_map_teardown(struct
>  }
>  }
>  
> -static bool __hwdom_init hwdom_iommu_map(const struct domain *d,
> - unsigned long pfn,
> - unsigned long max_pfn)
> +static unsigned int __hwdom_init hwdom_iommu_map(const struct domain *d,
> + unsigned long pfn,
> + unsigned long max_pfn)
>  {
>  mfn_t mfn = _mfn(pfn);
> -unsigned int i, type;
> +unsigned int i, type, perms = IOMMUF_readable | IOMMUF_writable;
>  
>  /*
>   * Set up 1:1 mapping for dom0. Default to include only conventional RAM
> @@ -289,44 +289,60 @@ static bool __hwdom_init hwdom_iommu_map
>   * that fall in unusable ranges for PV Dom0.
>   */
>  if ( (pfn > max_pfn && !mfn_valid(mfn)) || xen_in_range(pfn) )
> -return false;
> +return 0;
>  
>  switch ( type = page_get_ram_type(mfn) )
>  {
>  case RAM_TYPE_UNUSABLE:
> -return false;
> +return 0;
>  
>  case RAM_TYPE_CONVENTIONAL:
>  if ( iommu_hwdom_strict )
> -return false;
> +return 0;
>  break;
>  
>  default:
>  if ( type & RAM_TYPE_RESERVED )
>  {
>  if ( !iommu_hwdom_inclusive && !iommu_hwdom_reserved )
> -return false;
> +perms = 0;
>  }
> -else if ( is_hvm_domain(d) || !iommu_hwdom_inclusive || pfn > 
> max_pfn )
> -return false;
> +else if ( is_hvm_domain(d) )
> +return 0;
> +else if ( !iommu_hwdom_inclusive || pfn > max_pfn )
> +perms = 0;
>  }
>  
>  /* Check that it doesn't overlap with the Interrupt Address Range. */
>  if ( pfn >= 0xfee00 && pfn <= 0xfeeff )
> -return false;
> +return 0;
>  /* ... or the IO-APIC */
> -for ( i = 0; has_vioapic(d) && i < d->arch.hvm.nr_vioapics; i++ )
> -if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
> -return false;
> +if ( has_vioapic(d) )
> +{
> +for ( i = 0; i < d->arch.hvm.nr_vioapics; i++ )
> +if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
> +return 0;
> +}
> +else if ( is_pv_domain(d) )
> +{
> +/*
> + * Be consistent with CPU mappings: Dom0 is permitted to establish 
> r/o
> + * ones there, so it should also have such established for IOMMUs.
> + */
> +for ( i = 0; i < nr_ioapics; i++ )
> +if ( pfn == PFN_DOWN(mp_ioapics[i].mpc_apicaddr) )
> +return rangeset_contains_singleton(mmio_ro_ranges, pfn)
> +   ? IOMMUF_readable : 0;

If we really are after consistency with CPU side mappings, we should
likely take the whole contents of mmio_ro_ranges and d->iomem_caps
into account, not just the pages belonging to the IO-APIC?

There could also be HPET pages mapped as RO for PV.

Thanks, Roger.

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

[Luca Fancellu]

Hi Daniel,

> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 0bf63ffa84..b93101191e 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -186,6 +186,28 @@ static int cf_check flask_domain_alloc_security(struct 
> domain *d)
> return 0;
> }
> 
> +static int cf_check flask_set_system_active(void)
> +{
> +struct domain *d = current->domain;
> +
> +ASSERT(d->is_privileged);
> +
> +if ( d->domain_id != DOMID_IDLE )
> +{
> +printk("xsm_set_system_active should only be called by idle 
> domain\n");

Sorry I spotted that now, here in the printk probably you mean 
“flask_set_system_active”
instead of “xsm_set_system_active”, you can keep my R-by after this change.

Cheers,
Luca

[ovmf test] 170045: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  780 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

[PATCH 1/2] x86/pat: fix x86_has_pat_wp()

[Juergen Gross]

x86_has_pat_wp() is using a wrong test, as it relies on the normal
PAT configuration used by the kernel. In case the PAT MSR has been
setup by another entity (e.g. BIOS or Xen hypervisor) it might return
false even if the PAT configuration is allowing WP mappings.

Fixes: 1f6f655e01ad ("x86/mm: Add a x86_has_pat_wp() helper")
Signed-off-by: Juergen Gross 
---
 arch/x86/mm/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d8cfce221275..71e182ebced3 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -80,7 +80,8 @@ static uint8_t __pte2cachemode_tbl[8] = {
 /* Check that the write-protect PAT entry is set for write-protect */
 bool x86_has_pat_wp(void)
 {
-   return __pte2cachemode_tbl[_PAGE_CACHE_MODE_WP] == _PAGE_CACHE_MODE_WP;
+   return __pte2cachemode_tbl[__cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]] ==
+  _PAGE_CACHE_MODE_WP;
 }
 
 enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
-- 
2.35.3

[PATCH 2/2] x86/pat: add functions to query specific cache mode availability

[Juergen Gross]

Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false negatives
in case the system was booted e.g. with the "nopat" variant and the
BIOS did setup the PAT MSR supporting the queried mode, or if the
system is running as a Xen PV guest.

Add test functions for those caching modes instead and use them at the
appropriate places.

For symmetry reasons export the already existing x86_has_pat_wp() for
modules, too.

Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
Fixes: ae749c7ab475 ("PCI: Add arch_can_pci_mmap_wc() macro")
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/memtype.h   |  2 ++
 arch/x86/include/asm/pci.h   |  2 +-
 arch/x86/mm/init.c   | 25 +---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  8 
 4 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/memtype.h b/arch/x86/include/asm/memtype.h
index 9ca760e430b9..d00e0be854d4 100644
--- a/arch/x86/include/asm/memtype.h
+++ b/arch/x86/include/asm/memtype.h
@@ -25,6 +25,8 @@ extern void memtype_free_io(resource_size_t start, 
resource_size_t end);
 extern bool pat_pfn_immune_to_uc_mtrr(unsigned long pfn);
 
 bool x86_has_pat_wp(void);
+bool x86_has_pat_wc(void);
+bool x86_has_pat_uc_minus(void);
 enum page_cache_mode pgprot2cachemode(pgprot_t pgprot);
 
 #endif /* _ASM_X86_MEMTYPE_H */
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index f3fd5928bcbb..a5742268dec1 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -94,7 +94,7 @@ int pcibios_set_irq_routing(struct pci_dev *dev, int pin, int 
irq);
 
 
 #define HAVE_PCI_MMAP
-#define arch_can_pci_mmap_wc() pat_enabled()
+#define arch_can_pci_mmap_wc() x86_has_pat_wc()
 #define ARCH_GENERIC_PCI_MMAP_RESOURCE
 
 #ifdef CONFIG_PCI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 71e182ebced3..b6431f714dc2 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -77,12 +77,31 @@ static uint8_t __pte2cachemode_tbl[8] = {
[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
 };
 
-/* Check that the write-protect PAT entry is set for write-protect */
+static bool x86_has_pat_mode(unsigned int mode)
+{
+   return __pte2cachemode_tbl[__cachemode2pte_tbl[mode]] == mode;
+}
+
+/* Check that PAT supports write-protect */
 bool x86_has_pat_wp(void)
 {
-   return __pte2cachemode_tbl[__cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]] ==
-  _PAGE_CACHE_MODE_WP;
+   return x86_has_pat_mode(_PAGE_CACHE_MODE_WP);
+}
+EXPORT_SYMBOL_GPL(x86_has_pat_wp);
+
+/* Check that PAT supports WC */
+bool x86_has_pat_wc(void)
+{
+   return x86_has_pat_mode(_PAGE_CACHE_MODE_WC);
+}
+EXPORT_SYMBOL_GPL(x86_has_pat_wc);
+
+/* Check that PAT supports UC- */
+bool x86_has_pat_uc_minus(void)
+{
+   return x86_has_pat_mode(_PAGE_CACHE_MODE_UC_MINUS);
 }
+EXPORT_SYMBOL_GPL(x86_has_pat_uc_minus);
 
 enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
 {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 0c5c43852e24..f43ecf3f63eb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -76,7 +76,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
if (args->flags & ~(I915_MMAP_WC))
return -EINVAL;
 
-   if (args->flags & I915_MMAP_WC && !pat_enabled())
+   if (args->flags & I915_MMAP_WC && !x86_has_pat_wc())
return -ENODEV;
 
obj = i915_gem_object_lookup(file, args->handle);
@@ -757,7 +757,7 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
 
if (HAS_LMEM(to_i915(dev)))
mmap_type = I915_MMAP_TYPE_FIXED;
-   else if (pat_enabled())
+   else if (x86_has_pat_wc())
mmap_type = I915_MMAP_TYPE_WC;
else if (!i915_ggtt_has_aperture(to_gt(i915)->ggtt))
return -ENODEV;
@@ -813,7 +813,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
*data,
break;
 
case I915_MMAP_OFFSET_WC:
-   if (!pat_enabled())
+   if (!x86_has_pat_wc())
return -ENODEV;
type = I915_MMAP_TYPE_WC;
break;
@@ -823,7 +823,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
*data,
break;
 
case I915_MMAP_OFFSET_UC:
-   if (!pat_enabled())
+   if (!x86_has_pat_uc_minus())
return -ENODEV;
type = I915_MMAP_TYPE_UC;
break;
-- 
2.35.3

[PATCH 0/2] x86/pat: fix querying available caching modes

[Juergen Gross]

Fix some issues with querying caching modes being available for memory
mappings.

This is a replacement for the patch of Jan sent recently:

https://lists.xen.org/archives/html/xen-devel/2022-04/msg02392.html

Juergen Gross (2):
  x86/pat: fix x86_has_pat_wp()
  x86/pat: add functions to query specific cache mode availability

 arch/x86/include/asm/memtype.h   |  2 ++
 arch/x86/include/asm/pci.h   |  2 +-
 arch/x86/mm/init.c   | 24 ++--
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  8 
 4 files changed, 29 insertions(+), 7 deletions(-)

-- 
2.35.3

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

[Luca Fancellu]

> On 3 May 2022, at 12:17, Daniel P. Smith  wrote:
> 
> 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 

Hi Daniel,

I’ve built and tested the whole serie on arm, checked SILO and FLASK with 
builtin flask policy and I’ve
tested that Dom0 is booting fine.

So for me:

Reviewed-by: Luca Fancellu 
Tested-by: Luca Fancellu 

Cheers,
Luca

[ovmf bisection] complete build-i386

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  d3febfd9ade35dc552df6b3607c2b15d26b82867
  Bug not present: 84338c0d498555f860a480693ee8647a1795fba3
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/170047/


  commit d3febfd9ade35dc552df6b3607c2b15d26b82867
  Author: Jason 
  Date:   Mon Jan 10 21:46:27 2022 +0800
  
  MdePkg: Replace Opcode with the corresponding instructions.
  
  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3790
  
  Replace Opcode with the corresponding instructions.
  The code changes have been verified with CompareBuild.py tool, which
  can be used to compare the results of two different EDK II builds to
  determine if they generate the same binaries.
  (tool link: https://github.com/mdkinney/edk2/tree/sandbox/CompareBuild)
  
  Signed-off-by: Jason Lou 
  Cc: Michael D Kinney 
  Reviewed-by: Liming Gao 
  Cc: Zhiguang Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/build-i386.xen-build 
--summary-out=tmp/170047.bisection-summary --basis-template=168254 
--blessings=real,real-bisect,real-retry ovmf build-i386 xen-build
Searching for failure / basis pass:
 170045 fail [host=elbling1] / 168254 [host=albana0] 168249 [host=huxelrebe0] 
168232 [host=huxelrebe0] 168185 [host=huxelrebe0] 168131 [host=albana0] 168127 
[host=huxelrebe0] 168119 [host=albana0] 168115 [host=albana1] 168074 
[host=huxelrebe0] 168048 [host=albana0] 168046 [host=huxelrebe0] 168043 
[host=huxelrebe0] 168042 [host=chardonnay1] 168038 [host=huxelrebe0] 168017 
[host=albana0] 167989 [host=huxelrebe1] 167980 [host=albana1] 167976 
[host=huxelrebe0] 167956 [host=huxelrebe1] 167950 [host=a\
 lbana0] 167946 [host=fiano0] 167940 [host=albana0] 167933 [host=albana0] 
167929 [host=huxelrebe1] 167919 [host=fiano1] 167907 [host=albana0] 167803 
[host=huxelrebe0] 167775 [host=albana0] 167760 [host=fiano0] 167754 
[host=albana0] 167729 [host=albana1] 167727 [host=huxelrebe0] 167689 
[host=fiano0] 167685 [host=chardonnay1] 167651 [host=albana0] 167636 
[host=fiano0] 167627 [host=albana0] 167601 [host=albana1] 167598 
[host=huxelrebe0] 167559 [host=huxelrebe0] 167555 [host=huxelrebe0] 167552 
[host=\
 albana0] 167535 [host=chardonnay1] 167527 [host=chardonnay1] 167522 
[host=huxelrebe0] 167513 [host=albana1] 167487 [host=huxelrebe1] 167465 
[host=albana1] 167463 [host=huxelrebe0] 167450 [host=fiano1] 167445 
[host=chardonnay0] 167436 [host=fiano1] 167419 [host=pinot1] 167414 
[host=albana1] 167409 [host=albana0] 167394 [host=albana1] 167393 
[host=albana1] 167392 [host=albana1] 167391 [host=albana1] 167379 
[host=huxelrebe0] 167377 [host=huxelrebe1] 167239 [host=huxelrebe0] 167237 
[host=albana0] 16\
 7231 [host=albana0] 167225 [host=albana0] 167122 [host=huxelrebe0] 167104 
[host=huxelrebe0] 167081 [host=albana0] 166961 [host=albana0] 166951 
[host=pinot0] 166949 [host=pinot0] 166826 [host=albana0] 166360 [host=fiano0] 
166133 [host=albana1] 166130 [host=huxelrebe0] 166126 [host=huxelrebe1] 166123 
[host=albana0] 166120 [host=huxelrebe1] 166114 [host=huxelrebe1] 166108 
[host=huxelrebe0] 166105 [host=albana0] 166102 [host=huxelrebe0] 166097 
[host=huxelrebe1] 166093 [host=huxelrebe1] 166090 [host=\
 huxelrebe1] 166087 [host=fiano0] 166083 [host=albana0] 166081 
[host=huxelrebe0] 166063 [host=albana0] 166042 [host=huxelrebe0] 166035 
[host=albana0] 165969 [host=fiano0] 165962 [host=fiano0] 165950 [host=fiano0] 
165948 [host=fiano1] 165934 [host=fiano1] 165921 [host=albana0] 165899 
[host=huxelrebe0] 165873 [host=chardonnay0] 165862 [host=albana0] 165827 
[host=fiano0] 165808 [host=albana0] 165767 [host=fiano0] 165714 [host=fiano0] 
165701 [host=fiano0] 165690 [host=huxelrebe0] 165688 [host=huxelre\
 be0] 165685 [host=albana1] 165671 [host=albana0] 165657 [host=albana0] 165652 
[host=albana0] 165637 [host=fiano1] 165531 [host=albana1] 165523 [host=albana0] 
165508 [host=fiano1] 165505 [host=huxelrebe0] 165502 [host=fiano1] 165494 
[host=albana0] 165487 [host=albana1] 165474 [host=huxelrebe0] 165462 
[host=chardonnay0] 165433 [host=huxelrebe0] 165425 [host=albana0] 165398 
[host=albana1] 165382 [host=huxelrebe0] 165377 [host=albana0] 165347 
[host=chardonnay0] 165321 [host=elbling0] 165200 [host=ch\
 ardonnay0] 165175 [host=albana1] 165170 [host=albana1] 165155 
[host=huxelrebe0] 

Re: [PATCH v2] xen/arm: p2m don't fall over on FEAT_LPA enabled hw

[Luca Fancellu]

> On 28 Apr 2022, at 11:34, Alex Bennée  wrote:
> 
> When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
> kernels had a bug where the physical address was copied directly from
> ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
> the same error by blindly copying across the max supported range.
> 
> Unsurprisingly when the page tables aren't set up for these greater
> ranges hilarity ensues and the hypervisor crashes fairly early on in
> the boot-up sequence. This happens when we write to the control
> register in enable_mmu().
> 
> Attempt to fix this the same way as the Linux kernel does by gating
> PARange to the maximum the hypervisor can handle. I also had to fix up
> code in p2m which panics when it sees an "invalid" entry in PARange.
> 
> Signed-off-by: Alex Bennée 
> Cc: Richard Henderson 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Volodymyr Babchuk 
> Cc: Bertrand Marquis 
> 
> ---
> v2
>  - clamp p2m_ipa_bits = PADDR_BIT instead
> ---

Hi Alex,

I’ve tested the patch on fvp and Xen+Dom0 runs fine.

Tested-by: Luca Fancellu 

Cheers,
Luca

[ovmf test] 170048: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  781 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

Re: [PATCH v4 01/21] AMD/IOMMU: correct potentially-UB shifts

[Jan Beulich]

On 03.05.2022 12:10, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:30:33AM +0200, Jan Beulich wrote:
>> Recent changes (likely 5fafa6cf529a ["AMD/IOMMU: have callers specify
>> the target level for page table walks"]) have made Coverity notice a
>> shift count in iommu_pde_from_dfn() which might in theory grow too
>> large. While this isn't a problem in practice, address the concern
>> nevertheless to not leave dangling breakage in case very large
>> superpages would be enabled at some point.
>>
>> Coverity ID: 1504264
>>
>> While there also address a similar issue in set_iommu_ptes_present().
>> It's not clear to me why Coverity hasn't spotted that one.
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 

Thanks.

>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -89,11 +89,11 @@ static unsigned int set_iommu_ptes_prese
>> bool iw, bool ir)
>>  {
>>  union amd_iommu_pte *table, *pde;
>> -unsigned int page_sz, flush_flags = 0;
>> +unsigned long page_sz = 1UL << (PTE_PER_TABLE_SHIFT * (pde_level - 1));
> 
> Seeing the discussion from Andrews reply, nr_pages might be more
> appropriate while still quite short.

Yes and no - it then would be ambiguous as to what size pages are
meant.

> I'm not making my Rb conditional to that change though.

Good, thanks. But I guess I'm still somewhat stuck unless hearing
back from Andrew (although one might not count a conditional R-b
as a "pending objection"). I'll give him a few more days, but I
continue to think this ought to be a separate change (if renaming
is really needed in the 1st place) ...

Jan

Re: [PATCH v4 02/21] IOMMU: simplify unmap-on-error in iommu_map()

[Jan Beulich]

On 03.05.2022 12:25, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:32:10AM +0200, Jan Beulich wrote:
>> As of 68a8aa5d7264 ("iommu: make map and unmap take a page count,
>> similar to flush") there's no need anymore to have a loop here.
>>
>> Suggested-by: Roger Pau Monné 
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 

Thanks.

> I wonder whether we should have a macro to ignore returns from
> __must_check attributed functions.  Ie:
> 
> #define IGNORE_RETURN(exp) while ( exp ) break;
> 
> As to avoid confusion (and having to reason) whether the usage of
> while is correct.  I always find it confusing to assert such loop
> expressions are correct.

I've been considering some form of wrapper macro (not specifically
the one you suggest), but I'm of two minds: On one hand I agree it
would help readers, but otoh I fear it may make it more attractive
to actually override the __must_check (which really ought to be an
exception).

Jan

Re: [PATCH v4 04/21] IOMMU: have iommu_{,un}map() split requests into largest possible chunks

[Jan Beulich]

On 03.05.2022 14:37, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:33:32AM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -307,11 +338,10 @@ int iommu_map(struct domain *d, dfn_t df
>>  if ( !d->is_shutting_down && printk_ratelimit() )
>>  printk(XENLOG_ERR
>> "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn" 
>> failed: %d\n",
>> -   d->domain_id, dfn_x(dfn_add(dfn, i)),
>> -   mfn_x(mfn_add(mfn, i)), rc);
>> +   d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);
> 
> Since you are already adjusting the line, I wouldn't mind if you also
> switched to use %pd at once (and in the same adjustment done to
> iommu_unmap).

I did consider doing so, but decided against since this would lead
to also touching the format string (which right now is unaltered).

>>  
>>  /* while statement to satisfy __must_check */
>> -while ( iommu_unmap(d, dfn, i, flush_flags) )
>> +while ( iommu_unmap(d, dfn0, i, flush_flags) )
> 
> To match previous behavior you likely need to use i + (1UL << order),
> so pages covered by the map_page call above are also taken care in the
> unmap request?

I'm afraid I don't follow: Prior behavior was to unmap only what
was mapped on earlier iterations. This continues to be that way.

> With that fixed:
> 
> Reviewed-by: Roger Pau Monné 

Thanks, but I'll wait with applying this.

Jan

Re: [PATCH v4 06/21] IOMMU/x86: perform PV Dom0 mappings in batches

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:34:59AM +0200, Jan Beulich wrote:
> For large page mappings to be easily usable (i.e. in particular without
> un-shattering of smaller page mappings) and for mapping operations to
> then also be more efficient, pass batches of Dom0 memory to iommu_map().
> In dom0_construct_pv() and its helpers (covering strict mode) this
> additionally requires establishing the type of those pages (albeit with
> zero type references).

I think it's possible I've already asked this.  Would it make sense to
add the IOMMU mappings in alloc_domheap_pages(), maybe by passing a
specific flag?

It would seem to me that doing it that way would also allow the
mappings to get established in blocks for domUs.

And be less error prone in having to match memory allocation with
iommu_memory_setup() calls in order for the pages to be added to the
IOMMU page tables.

> The earlier establishing of PGT_writable_page | PGT_validated requires
> the existing places where this gets done (through get_page_and_type())
> to be updated: For pages which actually have a mapping, the type
> refcount needs to be 1.
> 
> There is actually a related bug that gets fixed here as a side effect:
> Typically the last L1 table would get marked as such only after
> get_page_and_type(..., PGT_writable_page). While this is fine as far as
> refcounting goes, the page did remain mapped in the IOMMU in this case
> (when "iommu=dom0-strict").
> 
> Signed-off-by: Jan Beulich 
> ---
> Subsequently p2m_add_identity_entry() may want to also gain an order
> parameter, for arch_iommu_hwdom_init() to use. While this only affects
> non-RAM regions, systems typically have 2-16Mb of reserved space
> immediately below 4Gb, which hence could be mapped more efficiently.

Indeed.

> The installing of zero-ref writable types has in fact shown (observed
> while putting together the change) that despite the intention by the
> XSA-288 changes (affecting DomU-s only) for Dom0 a number of
> sufficiently ordinary pages (at the very least initrd and P2M ones as
> well as pages that are part of the initial allocation but not part of
> the initial mapping) still have been starting out as PGT_none, meaning
> that they would have gained IOMMU mappings only the first time these
> pages would get mapped writably. Consequently an open question is
> whether iommu_memory_setup() should set the pages to PGT_writable_page
> independent of need_iommu_pt_sync().

I think I'm confused, doesn't the setting of PGT_writable_page happen
as a result of need_iommu_pt_sync() and having those pages added to
the IOMMU page tables? (so they can be properly tracked and IOMMU
mappings are removed if thte page is also removed)

If the pages are not added here (because dom0 is not running in strict
mode) then setting PGT_writable_page is not required?

> I didn't think I need to address the bug mentioned in the description in
> a separate (prereq) patch, but if others disagree I could certainly
> break out that part (needing to first use iommu_legacy_unmap() then).
> 
> Note that 4k P2M pages don't get (pre-)mapped in setup_pv_physmap():
> They'll end up mapped via the later get_page_and_type().
> 
> As to the way these refs get installed: I've chosen to avoid the more
> expensive {get,put}_page_and_type(), favoring to put in place the
> intended type directly. I guess I could be convinced to avoid this
> bypassing of the actual logic; I merely think it's unnecessarily
> expensive.

In a different piece of code I would have asked to avoid open-coding
the type changes.  But there are already open-coded type changes in
dom0_construct_pv(), so adding those doesn't make the current status
worse.

> Note also that strictly speaking the iommu_iotlb_flush_all() here (as
> well as the pre-existing one in arch_iommu_hwdom_init()) shouldn't be
> needed: Actual hooking up (AMD) or enabling of translation (VT-d)
> occurs only afterwards anyway, so nothing can have made it into TLBs
> just yet.

Hm, indeed. I think the one in arch_iommu_hwdom_init can surely go
away, as we must strictly do the hwdom init before enabling the iommu
itself.

The one in dom0 build I'm less convinced, just to be on the safe side
if we ever change the order of IOMMU init and memory setup.  I would
expect flushing an empty TLB to not be very expensive?

> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -347,8 +347,8 @@ static unsigned int __hwdom_init hwdom_i
>  
>  void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
>  {
> -unsigned long i, top, max_pfn;
> -unsigned int flush_flags = 0;
> +unsigned long i, top, max_pfn, start, count;
> +unsigned int flush_flags = 0, start_perms = 0;
>  
>  BUG_ON(!is_hardware_domain(d));
>  
> @@ -379,9 +379,9 @@ void __hwdom_init arch_iommu_hwdom_init(
>   * First Mb will get mapped in one go by pvh_populate_p2m(). Avoid
>   * setting up potentially conflicting mappings here.
>   */
> -i = paging_mode_tran

Re: [PATCH v4 05/21] IOMMU/x86: restrict IO-APIC mappings for PV Dom0

[Jan Beulich]

On 03.05.2022 15:00, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:34:23AM +0200, Jan Beulich wrote:
>> While already the case for PVH, there's no reason to treat PV
>> differently here, though of course the addresses get taken from another
>> source in this case. Except that, to match CPU side mappings, by default
>> we permit r/o ones. This then also means we now deal consistently with
>> IO-APICs whose MMIO is or is not covered by E820 reserved regions.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> [integrated] v1: Integrate into series.
>> [standalone] v2: Keep IOMMU mappings in sync with CPU ones.
>>
>> --- a/xen/drivers/passthrough/x86/iommu.c
>> +++ b/xen/drivers/passthrough/x86/iommu.c
>> @@ -275,12 +275,12 @@ void iommu_identity_map_teardown(struct
>>  }
>>  }
>>  
>> -static bool __hwdom_init hwdom_iommu_map(const struct domain *d,
>> - unsigned long pfn,
>> - unsigned long max_pfn)
>> +static unsigned int __hwdom_init hwdom_iommu_map(const struct domain *d,
>> + unsigned long pfn,
>> + unsigned long max_pfn)
>>  {
>>  mfn_t mfn = _mfn(pfn);
>> -unsigned int i, type;
>> +unsigned int i, type, perms = IOMMUF_readable | IOMMUF_writable;
>>  
>>  /*
>>   * Set up 1:1 mapping for dom0. Default to include only conventional RAM
>> @@ -289,44 +289,60 @@ static bool __hwdom_init hwdom_iommu_map
>>   * that fall in unusable ranges for PV Dom0.
>>   */
>>  if ( (pfn > max_pfn && !mfn_valid(mfn)) || xen_in_range(pfn) )
>> -return false;
>> +return 0;
>>  
>>  switch ( type = page_get_ram_type(mfn) )
>>  {
>>  case RAM_TYPE_UNUSABLE:
>> -return false;
>> +return 0;
>>  
>>  case RAM_TYPE_CONVENTIONAL:
>>  if ( iommu_hwdom_strict )
>> -return false;
>> +return 0;
>>  break;
>>  
>>  default:
>>  if ( type & RAM_TYPE_RESERVED )
>>  {
>>  if ( !iommu_hwdom_inclusive && !iommu_hwdom_reserved )
>> -return false;
>> +perms = 0;
>>  }
>> -else if ( is_hvm_domain(d) || !iommu_hwdom_inclusive || pfn > 
>> max_pfn )
>> -return false;
>> +else if ( is_hvm_domain(d) )
>> +return 0;
>> +else if ( !iommu_hwdom_inclusive || pfn > max_pfn )
>> +perms = 0;
>>  }
>>  
>>  /* Check that it doesn't overlap with the Interrupt Address Range. */
>>  if ( pfn >= 0xfee00 && pfn <= 0xfeeff )
>> -return false;
>> +return 0;
>>  /* ... or the IO-APIC */
>> -for ( i = 0; has_vioapic(d) && i < d->arch.hvm.nr_vioapics; i++ )
>> -if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
>> -return false;
>> +if ( has_vioapic(d) )
>> +{
>> +for ( i = 0; i < d->arch.hvm.nr_vioapics; i++ )
>> +if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
>> +return 0;
>> +}
>> +else if ( is_pv_domain(d) )
>> +{
>> +/*
>> + * Be consistent with CPU mappings: Dom0 is permitted to establish 
>> r/o
>> + * ones there, so it should also have such established for IOMMUs.
>> + */
>> +for ( i = 0; i < nr_ioapics; i++ )
>> +if ( pfn == PFN_DOWN(mp_ioapics[i].mpc_apicaddr) )
>> +return rangeset_contains_singleton(mmio_ro_ranges, pfn)
>> +   ? IOMMUF_readable : 0;
> 
> If we really are after consistency with CPU side mappings, we should
> likely take the whole contents of mmio_ro_ranges and d->iomem_caps
> into account, not just the pages belonging to the IO-APIC?
> 
> There could also be HPET pages mapped as RO for PV.

Hmm. This would be a yet bigger functional change, but indeed would further
improve consistency. But shouldn't we then also establish r/w mappings for
stuff in ->iomem_caps but not in mmio_ro_ranges? This would feel like going
too far ...

Jan

[ovmf test] 170049: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  782 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

Re: [PATCH] arm/acpi: don't expose the ACPI IORT SMMUv3 entry to dom0

[Julien Grall]

On 29/04/2022 19:18, Rahul Singh wrote:

Hi Julien,


Hi Rahul,


On 27 Apr 2022, at 7:26 pm, Julien Grall  wrote:

Hi Rahul,

On 27/04/2022 17:12, Rahul Singh wrote:

Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.


Looking at the IORT spec (ARM DEN 0049E), 255 (0xff) is marked as reserved. So I don't 
think we can "allocate" 0xff to mean invalid without updating the spec. Did you 
engage with whoever own the spec?


Yes I agree with you 0xff is reserved for future use. I didn’t find any other 
value to make node invalid.
Linux kernel is mostly using the node->type to process the SMMUv3 or other IORT 
node so I thought this is the only possible solution to hide SMMUv3 for dom0
If you have any other suggestion to hide the SMMUv3 node I am okay to use that.
The other solution is to remove completely the SMMUv3 node from the 
IORT. This would require more work as you would need to fully rewrite 
the IORT.


Hence why I suggested to speak with the spec owner (it seems to be Arm) 
to reserve 0xff as "Invalid/Ignore".



+ smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
+ mfn = paddr_to_pfn(smmu->base_address);
+ rc = iomem_deny_access(d, mfn, mfn + PFN_UP(SZ_128K));
+ if ( rc )
+ printk("iomem_deny_access failed for SMMUv3\n");
+ node->type = 0xff;


'node' points to the Xen copy of the ACPI table. We should really not touch 
this copy. Instead, we should modify the version that will be used by dom0.


As of now IORT is untouched by Xen and mapped to dom0. I will create the IORT 
table for dom0 and modify the node SMMUv3 that will be used by dom0.


Furthermore, if we go down the road to update node->type, we should 0 the node 
to avoid leaking the information to dom0.


I am not sure if we can zero the node, let me check and come back to you.


By writing node->type, you already invalidate the content because the 
software cannot know how to interpret it. At which point, zeroing it 
should make no difference for software parsing the table afterwards. 
This may be a problem for software parsing before hand and keeping a 
pointer to the entry. But then, this is yet another reason to no updated 
the host IORT and create a copy for dom0.


Cheers,

--
Julien Grall

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

[Juergen Gross]

On 28.04.22 17:53, 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.
We can't, for example, simply turn on the MTRR bit in CPUID, as that
would implicitly lead to the kernel trying to write the PAT MSR (if,
see below, it didn't itself zap the bit). We also can't simply
ignore PAT MSR writes, as the kernel won't check whether writes
actually took effect. (All of that did work on top of old Xen
apparently only because xen_init_capabilities() itself also forces
the MTRR feature to off.)


I've sent an alternative patch addressing this problem:

https://lore.kernel.org/lkml/20220503132207.17234-3-jgr...@suse.com/T/#u

Lets see whether it is accepted.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] xen/arm: smmuv1: remove iommu group when deassign a device

[Julien Grall]

On 29/04/2022 15:33, Rahul Singh wrote:

Hi Julien,


Hi Rahul,


On 27 Apr 2022, at 6:42 pm, Julien Grall  wrote:

Hi,

On 27/04/2022 17:15, Rahul Singh wrote:

When a device is deassigned from the domain it is required to remove the
iommu group.


This read wrong to me. We should not need to re-create the IOMMU group (and 
call arm_smmu_add_device()) every time a device is re-assigned.

Ok.



If we don't remove the group, the next time when we assign
a device, SME and S2CR will not be setup correctly for the device
because of that SMMU fault will be observed.


I think this is a bug fix for 0435784cc75dcfef3b5f59c29deb1dbb84265ddb. If so, 
please add a Fixes tag.


Ok Let me add the Fixes tag in next version.



Signed-off-by: Rahul Singh 
---
xen/drivers/passthrough/arm/smmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 5cacb2dd99..9a31c332d0 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -1690,6 +1690,8 @@ static void arm_smmu_detach_dev(struct iommu_domain 
*domain, struct device *dev)
if (cfg)
arm_smmu_master_free_smes(cfg);
+   iommu_group_put(dev_iommu_group(dev));
+   dev_iommu_group(dev) = NULL;
}


The goal of arm_smmu_detach_dev() is to revert the change made in 
arm_smmu_attach_dev(). But looking at the code, neither the IOMMU group nor the 
smes are allocated in arm_smmu_attach_dev().

Are the SMES meant to be re-allocated everytime we assign to a different 
domain? If yes, the allocation should be done in arm_smmu_attach_dev().


Yes SMES have to be re-allocated every time a device is assigned.


H Looking at the code, arm_smmu_alloc_smes() doesn't seem to use 
the domain information. So why would it need to be done every time it is 
assigned?




Is that okay if I will move the function arm_smmu_master_alloc_smes() from 
arm_smmu_add_device() to arm_smmu_attach_dev().
In this case we don’t need to remove the IOMMU group and also 
arm_smmu_detach_dev() will also revert the  change made in 
arm_smmu_attach_dev().

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 5cacb2dd99..ff1b73d3d8 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -1680,6 +1680,10 @@ static int arm_smmu_attach_dev(struct iommu_domain 
*domain, struct device *dev)
 if (!cfg)
 return -ENODEV;
  
+   ret = arm_smmu_master_alloc_smes(dev);

+   if (ret)
+   return ret;
+
 return arm_smmu_domain_add_master(smmu_domain, cfg);


If we go down this route, then you will likely need to revert the change 
made by arm_smmu_master_alloc_smes().



  }
  
@@ -2075,7 +2079,7 @@ static int arm_smmu_add_device(struct device *dev)

 iommu_group_add_device(group, dev);
 iommu_group_put(group);
  
-   return arm_smmu_master_alloc_smes(dev);

+   return 0;
  }

Regards,
Rahul


If not, then we should not free the SMES here

IIUC, the SMES have to be re-allocated every time a device is assigned. 
Therefore, I think we should move the call to arm_smmu_master_alloc_smes() out 
of the detach callback and in a helper that would be used when removing a 
device (not yet supported by Xen).

Cheers,

--
Julien Grall




--
Julien Grall

Re: [PATCH] arm/its: enable LPIs before mapping the collection table

[Julien Grall]

On 28/04/2022 15:11, Rahul Singh wrote:

Hi Julien,


Hi Rahul,


On 28 Apr 2022, at 1:59 pm, Julien Grall  wrote:



On 28/04/2022 11:00, Rahul Singh wrote:

Hi Julien,

On 27 Apr 2022, at 6:59 pm, Julien Grall  wrote:

Hi Rahul,

On 27/04/2022 17:14, Rahul Singh wrote:

MAPC_LPI_OFF ITS command error can be reported to software if LPIs are


Looking at the spec (ARM IHI 0069H), I can't find a command error named 
MAPC_LPI_OFF. Is it something specific to your HW?

I found the issue on HW that implements GIC-600 and GIC-600 TRM specify the 
MAPC_LPI_OFF its command error.
https://developer.arm.com/documentation/100336/0106/introduction/about-the-gic-600
{Table 3-15 ITS command and translation errors, records 13+ page 3-89}


Please provide a pointer to the spec in the commit message. This would help the 
reviewer to know where MAPC_LPI_OFF come from.

Ok.





not enabled before mapping the collection table using MAPC command.
Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
table.
Signed-off-by: Rahul Singh 
---
xen/arch/arm/gic-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 3c472ed768..8fb0014b16 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -812,11 +812,11 @@ static int gicv3_cpu_init(void)
/* If the host has any ITSes, enable LPIs now. */
if ( gicv3_its_host_has_its() )
{
+ if ( !gicv3_enable_lpis() )
+ return -EBUSY;
ret = gicv3_its_setup_collection(smp_processor_id());
if ( ret )
return ret;
- if ( !gicv3_enable_lpis() )
- return -EBUSY;


AFAICT, Linux is using the same ordering as your are proposing. It seems to 
have been introduced from the start, so it is not clear why we chose this 
approach.

Yes I also confirmed that before sending the patch for review. I think this is 
okay if we enable the enable LPIs before mapping the collection table.


In general, I expect change touching the GICv3 code based on the specification rather 
than "we think this is okay". This reduce the risk to make modification that 
could break other platforms (we can't possibly test all of them).

Reading through the spec, the definition of GICR.EnableLPIs contains the 
following:

"
0b0 LPI support is disabled. Any doorbell interrupt generated as a result of a 
write to a virtual LPI register must be discarded, and any ITS translation 
requests or commands involving LPIs in this Redistributor are ignored.

0b1 LPI support is enabled.
"

So your change is correct. But the commit message needs to be updated with more 
details on which GIC HW the issue was seen and why your proposal is correct 
(i.e. quoting the spec).


Ok. I will modify the commit msg as below.Please let me know if it is okay.

arm/its: enable LPIs before mapping the collection table

When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is oberved.


s/oberved/observed/



As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be reported if the ITS MAPC command has tried to map a collection to a core
that does not have LPIs enabled.


Please add a quote from the GICv3 specification (see my previous reply).



To fix this issue, enable the LPIs using GICR_CTLR.EnableLPIs before
mapping the collection table.


Cheers,

--
Julien Grall

Re: [PATCH] arm/its: enable LPIs before mapping the collection table

[Julien Grall]

Hi Rahul,

On 27/04/2022 17:14, Rahul Singh wrote:

MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
not enabled before mapping the collection table using MAPC command.

Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
table.

Signed-off-by: Rahul Singh 
---
  xen/arch/arm/gic-v3.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 3c472ed768..8fb0014b16 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -812,11 +812,11 @@ static int gicv3_cpu_init(void)
  /* If the host has any ITSes, enable LPIs now. */
  if ( gicv3_its_host_has_its() )
  {
+if ( !gicv3_enable_lpis() )
+return -EBUSY;


gicv3_enable_lpis() is using writel_relaxed(). So in theory, the write 
may not be visible before gicv3_its_setup_collection() send the command.


So I think we need to add an smp_wmb() to ensure the ordering with a 
comment explaning why this is necessary.


Cheers,

--
Julien Grall

[ovmf test] 170050: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  783 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

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

[Jan Beulich]

On 03.05.2022 11:15, Roger Pau Monné wrote:
> On Tue, May 03, 2022 at 10:17:44AM +0200, Jan Beulich wrote:
>> On 02.05.2022 17:20, Roger Pau Monne wrote:
>>> 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
>>
>> I'm puzzled by "almost" - is there a pattern of which ones aren't
>> converted?
> 
> This is the list of the ones that aren't converted:
> 
> __x86_indirect_thunk_r11
> s3_resume
> start
> __image_base__
> __high_start
> wakeup_stack
> wakeup_stack_start
> handle_exception
> dom_crash_sync_extable
> common_interrupt
> __x86_indirect_thunk_rbx
> __x86_indirect_thunk_rcx
> __x86_indirect_thunk_rax
> __x86_indirect_thunk_rdx
> __x86_indirect_thunk_rbp
> __x86_indirect_thunk_rsi
> __x86_indirect_thunk_rdi
> __x86_indirect_thunk_r8
> __x86_indirect_thunk_r9
> __x86_indirect_thunk_r10
> __x86_indirect_thunk_r12
> __x86_indirect_thunk_r13
> __x86_indirect_thunk_r14
> __x86_indirect_thunk_r15
> 
> I assume there's some kind of pattern, but I haven't yet been able to
> spot where triggers the conversion from global to local in lld.

At least this looks to all be symbols defined in assembly files, which
don't have a C-visible declaration.

>>> 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.
>>
>> If, as the last paragraph of the description is worded, you did this
>> just once (as a prereq), I could see this working.
> 
> Yes, my comment was about splitting the:
> 
> $(NM) -pa --format=bsd $< | awk '{ if($$2 == "T") print $$3}' \
>   > $(@D)/.$(@F).global-syms
> 
> rune into a separate $(TARGET)-syms.global-syms target or some such.
> Not sure it's really worth it.

Probably indeed only when splitting up the rule as a whole.

>>> --- 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 $@
>>
>> Is this very useful? It only affects ...
>>
>>> $(NM) -pa --format=sysv $(@D)/$(@F) \
>>> | $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
>>> --sort \
>>> >$(@D)/$(@F).map
>>
>> ... the actual map file; what's in the binary and in this map file doesn't
>> depend on local vs global anymore (and you limit this to text symbols
>> anyway; I wonder in how far livepatching might also be affected by the
>> same issue with data symbols).
> 
> If I don't add this step then the map file will also end up with lines
> like:
> 
> 0x82d0405b6968 b lib/xxhash64.c#iommuv2_enabled
> 0x82d0405b6970 b lib/xxhash64.c#nr_ioapic_sbdf
> 0x82d0405b6980 b lib/xxhash64.c#ioapic_sbdf
> 
> I see the same happen with other non-text symbols, so I would likely
> need to extend the fixing to preserve all global symbols from the
> input file, not just text ones.

Oh, I see - yes, this wants avoiding.

Jan

Re: [PATCH v4 07/21] IOMMU/x86: support freeing of pagetables

[Roger Pau Monné]

On Mon, Apr 25, 2022 at 10:35:45AM +0200, Jan Beulich wrote:
> For vendor specific code to support superpages we need to be able to
> deal with a superpage mapping replacing an intermediate page table (or
> hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
> needed to free individual page tables while a domain is still alive.
> Since the freeing needs to be deferred until after a suitable IOTLB
> flush was performed, released page tables get queued for processing by a
> tasklet.
> 
> Signed-off-by: Jan Beulich 
> ---
> I was considering whether to use a softirq-tasklet instead. This would
> have the benefit of avoiding extra scheduling operations, but come with
> the risk of the freeing happening prematurely because of a
> process_pending_softirqs() somewhere.

I'm sorry again if I already raised this, I don't seem to find a
reference.

What about doing the freeing before resuming the guest execution in
guest vCPU context?

We already have a hook like this on HVM in hvm_do_resume() calling
vpci_process_pending().  I wonder whether we could have a similar hook
for PV and keep the pages to be freed in the vCPU instead of the pCPU.
This would have the benefit of being able to context switch the vCPU
in case the operation takes too long.

Not that the current approach is wrong, but doing it in the guest
resume path we could likely prevent guests doing heavy p2m
modifications from hogging CPU time.

> ---
> v4: Change type of iommu_queue_free_pgtable()'s 1st parameter. Re-base.
> v3: Call process_pending_softirqs() from free_queued_pgtables().
> 
> --- a/xen/arch/x86/include/asm/iommu.h
> +++ b/xen/arch/x86/include/asm/iommu.h
> @@ -147,6 +147,7 @@ void iommu_free_domid(domid_t domid, uns
>  int __must_check iommu_free_pgtables(struct domain *d);
>  struct domain_iommu;
>  struct page_info *__must_check iommu_alloc_pgtable(struct domain_iommu *hd);
> +void iommu_queue_free_pgtable(struct domain_iommu *hd, struct page_info *pg);
>  
>  #endif /* !__ARCH_X86_IOMMU_H__ */
>  /*
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -12,6 +12,7 @@
>   * this program; If not, see .
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -550,6 +551,91 @@ struct page_info *iommu_alloc_pgtable(st
>  return pg;
>  }
>  
> +/*
> + * Intermediate page tables which get replaced by large pages may only be
> + * freed after a suitable IOTLB flush. Hence such pages get queued on a
> + * per-CPU list, with a per-CPU tasklet processing the list on the assumption
> + * that the necessary IOTLB flush will have occurred by the time tasklets get
> + * to run. (List and tasklet being per-CPU has the benefit of accesses not
> + * requiring any locking.)
> + */
> +static DEFINE_PER_CPU(struct page_list_head, free_pgt_list);
> +static DEFINE_PER_CPU(struct tasklet, free_pgt_tasklet);
> +
> +static void free_queued_pgtables(void *arg)
> +{
> +struct page_list_head *list = arg;
> +struct page_info *pg;
> +unsigned int done = 0;
> +

With the current logic I think it might be helpful to assert that the
list is not empty when we get here?

Given the operation requires a context switch we would like to avoid
such unless there's indeed pending work to do.

> +while ( (pg = page_list_remove_head(list)) )
> +{
> +free_domheap_page(pg);
> +
> +/* Granularity of checking somewhat arbitrary. */
> +if ( !(++done & 0x1ff) )
> + process_pending_softirqs();
> +}
> +}
> +
> +void iommu_queue_free_pgtable(struct domain_iommu *hd, struct page_info *pg)
> +{
> +unsigned int cpu = smp_processor_id();
> +
> +spin_lock(&hd->arch.pgtables.lock);
> +page_list_del(pg, &hd->arch.pgtables.list);
> +spin_unlock(&hd->arch.pgtables.lock);
> +
> +page_list_add_tail(pg, &per_cpu(free_pgt_list, cpu));
> +
> +tasklet_schedule(&per_cpu(free_pgt_tasklet, cpu));
> +}
> +
> +static int cf_check cpu_callback(
> +struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +unsigned int cpu = (unsigned long)hcpu;
> +struct page_list_head *list = &per_cpu(free_pgt_list, cpu);
> +struct tasklet *tasklet = &per_cpu(free_pgt_tasklet, cpu);
> +
> +switch ( action )
> +{
> +case CPU_DOWN_PREPARE:
> +tasklet_kill(tasklet);
> +break;
> +
> +case CPU_DEAD:
> +page_list_splice(list, &this_cpu(free_pgt_list));

I think you could check whether list is empty before queuing it?

Thanks, Roger.

Re: [PATCH v4 02/21] IOMMU: simplify unmap-on-error in iommu_map()

[Roger Pau Monné]

On Tue, May 03, 2022 at 04:37:29PM +0200, Jan Beulich wrote:
> On 03.05.2022 12:25, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:32:10AM +0200, Jan Beulich wrote:
> >> As of 68a8aa5d7264 ("iommu: make map and unmap take a page count,
> >> similar to flush") there's no need anymore to have a loop here.
> >>
> >> Suggested-by: Roger Pau Monné 
> >> Signed-off-by: Jan Beulich 
> > 
> > Reviewed-by: Roger Pau Monné 
> 
> Thanks.
> 
> > I wonder whether we should have a macro to ignore returns from
> > __must_check attributed functions.  Ie:
> > 
> > #define IGNORE_RETURN(exp) while ( exp ) break;
> > 
> > As to avoid confusion (and having to reason) whether the usage of
> > while is correct.  I always find it confusing to assert such loop
> > expressions are correct.
> 
> I've been considering some form of wrapper macro (not specifically
> the one you suggest), but I'm of two minds: On one hand I agree it
> would help readers, but otoh I fear it may make it more attractive
> to actually override the __must_check (which really ought to be an
> exception).

Well, I think anyone reviewing the code would realize that the error
is being ignored, and hence check that this is actually intended.

Thanks, Roger.

Re: fix and cleanup discard_alignment handling

[Jens Axboe]

On Mon, 18 Apr 2022 06:53:03 +0200, Christoph Hellwig wrote:
> the somewhat confusing name of the discard_alignment queue limit, that
> really is an offset for the discard granularity mislead a lot of driver
> authors to set it to an incorrect value.  This series tries to fix up
> all these cases.
> 
> Diffstat:
>  arch/um/drivers/ubd_kern.c |1 -
>  drivers/block/loop.c   |1 -
>  drivers/block/nbd.c|3 ---
>  drivers/block/null_blk/main.c  |1 -
>  drivers/block/rnbd/rnbd-srv-dev.h  |2 +-
>  drivers/block/virtio_blk.c |7 ---
>  drivers/block/xen-blkback/xenbus.c |4 ++--
>  drivers/md/dm-zoned-target.c   |2 +-
>  drivers/md/raid5.c |1 -
>  drivers/nvme/host/core.c   |1 -
>  drivers/s390/block/dasd_fba.c  |1 -
>  11 files changed, 8 insertions(+), 16 deletions(-)
> 
> [...]

Applied, thanks!

[01/11] ubd: don't set the discard_alignment queue limit
commit: 07c6e92a8478770a7302f7dde72f03a5465901bd
[02/11] nbd: don't set the discard_alignment queue limit
commit: 4a04d517c56e0616c6f69afc226ee2691e543712
[03/11] null_blk: don't set the discard_alignment queue limit
commit: fb749a87f4536d2fa86ea135ae4eff1072903438
[04/11] virtio_blk: fix the discard_granularity and discard_alignment queue 
limits
commit: 62952cc5bccd89b76d710de1d0b43244af0f2903
[05/11] dm-zoned: don't set the discard_alignment queue limit
commit: 44d583702f4429763c558624fac763650a1f05bf
[06/11] raid5: don't set the discard_alignment queue limit
commit: 3d50d368c92ade2f98a3d0d28b842a57c35284e9
[07/11] dasd: don't set the discard_alignment queue limit
commit: c3f765299632727fa5ea5a0acf118665227a4f1a
[08/11] loop: remove a spurious clear of discard_alignment
commit: 4418bfd8fb9602d9cd8747c3ad52fdbaa02e2ffd
[09/11] nvme: remove a spurious clear of discard_alignment
commit: 4e7f0ece41e1be8f876f320a0972a715daec0a50
[10/11] rnbd-srv: use bdev_discard_alignment
commit: 18292faa89d2bff3bdd33ab9c065f45fb6710e47
[11/11] xen-blkback: use bdev_discard_alignment
commit: c899b23533866910c90ef4386b501af50270d320

Best regards,
-- 
Jens Axboe

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

[Oleksandr]

On 03.05.22 00:59, Rob Herring wrote:

Hello Rob



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?


From my understanding - yes.

As, I think, any device node describing virtulized device in the guest 
device tree can have this property.  Initially (in the RFC series) the 
"solution to restrict memory access using Xen grant mappings" was 
virtio-specific.


Although the support of virtio is a primary target of this series, we 
decided to generalize this work and expand it to any device [1]. So the 
Xen grant mappings scheme (this property to be used for) can be 
theoretically used for any device emulated by the Xen backend.




+
+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


ok, will change





+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


Thank you for pointing this out, my fault, I haven't "properly" checked 
this before. I think, we need to remove "compatible = "virtio,mmio"; here



diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml 
b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml

index 2daa8aa..d2f2140 100644
--- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
+++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
@@ -28,7 +28,7 @@ additionalProperties: true
 examples:
   - |
 virtio_block@3000 {
-    compatible = "virtio,mmio";
+    /* ... */
 reg = <0x3000 0x100>;
 interrupts = <41>;





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


As I described above, the property is not virtio specific and can be 
used for any virtualized device for which Xen grant mappings scheme 
needs to be enabled (xen-grant DMA-mapping layer).



[1] 
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2204181202080.915916@ubuntu-linux-20-04-desktop/





Rob


--
Regards,

Oleksandr Tyshchenko

[ovmf test] 170052: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  784 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

[PATCH V8 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Hello all.

The purpose of this patch series is to add missing virtio-mmio bits to Xen 
toolstack on Arm.
The Virtio support for toolstack [1] was postponed as the main target was to 
upstream IOREQ/DM
support on Arm in the first place. Now, we already have IOREQ support in, so we 
can resume Virtio
enabling work. You can find previous discussions at [2].

Patch series [3] is based on recent "staging" branch
(fa6dc0879ffd3daea2837953c7a8761a9ba0 page_alloc: assert IRQs are enabled 
in heap alloc/free)
and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio 
based virtio-disk backend [4]
running in Dom0 (or Driver domain) and unmodified Linux Guest running on 
existing virtio-blk driver (frontend).
No issues were observed. Guest domain 'reboot/destroy' use-cases work properly.

Any feedback/help would be highly appreciated.

[1]
https://lore.kernel.org/xen-devel/1610488352-18494-24-git-send-email-olekst...@gmail.com/
https://lore.kernel.org/xen-devel/1610488352-18494-25-git-send-email-olekst...@gmail.com/
[2]
https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02403.html
https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02536.html
https://lore.kernel.org/xen-devel/1621626361-29076-1-git-send-email-olekst...@gmail.com/
https://lore.kernel.org/xen-devel/1638982784-14390-1-git-send-email-olekst...@gmail.com/
https://lore.kernel.org/xen-devel/1649442065-8332-1-git-send-email-olekst...@gmail.com/

[3] https://github.com/otyshchenko1/xen/commits/libxl_virtio3
[4] https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant

Julien Grall (1):
  libxl: Introduce basic virtio-mmio support on Arm

Oleksandr Tyshchenko (1):
  libxl: Add support for Virtio disk configuration

 docs/man/xl-disk-configuration.5.pod.in   |  38 +-
 tools/golang/xenlight/helpers.gen.go  |   8 +
 tools/golang/xenlight/types.gen.go|  18 +
 tools/include/libxl.h |   7 +
 tools/libs/light/libxl_arm.c  | 118 +++-
 tools/libs/light/libxl_device.c   |  62 +-
 tools/libs/light/libxl_disk.c | 136 -
 tools/libs/light/libxl_internal.h |   2 +
 tools/libs/light/libxl_types.idl  |  16 +
 tools/libs/light/libxl_types_internal.idl |   1 +
 tools/libs/light/libxl_utils.c|   2 +
 tools/libs/util/libxlu_disk_l.c   | 959 +++---
 tools/libs/util/libxlu_disk_l.h   |   2 +-
 tools/libs/util/libxlu_disk_l.l   |   9 +
 tools/xl/xl_block.c   |  11 +
 xen/include/public/arch-arm.h |   7 +
 16 files changed, 914 insertions(+), 482 deletions(-)

-- 
2.7.4

[PATCH V8 2/2] libxl: Introduce basic virtio-mmio support on Arm

[Oleksandr Tyshchenko]

From: Julien Grall 

This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory region) and create specific device node in
the Guest device-tree with allocated params. In order to deal
with multiple Virtio devices, reserve corresponding ranges.
For now, we reserve 1MB for memory regions and 10 SPIs.

As these helpers should be used for every Virtio device attached
to the Guest, call them for Virtio disk(s).

Please note, with statically allocated Virtio IRQs there is
a risk of a clash with a physical IRQs of passthrough devices.
For the first version, it's fine, but we should consider allocating
the Virtio IRQs automatically. Thankfully, we know in advance which
IRQs will be used for passthrough to be able to choose non-clashed
ones.

Signed-off-by: Julien Grall 
Signed-off-by: Oleksandr Tyshchenko 
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forwarding to a device emulator"

Changes RFC -> V1:
   - was squashed with:
 "[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
 "[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into 
virtio-mmio device node"
 "[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
   - move VirtIO MMIO #define-s to xen/include/public/arch-arm.h

Changes V1 -> V2:
   - update the author of a patch

Changes V2 -> V3:
   - no changes

Changes V3 -> V4:
   - no changes

Changes V4 -> V5:
   - split the changes, change the order of the patches
   - drop an extra "virtio" configuration option
   - update patch description
   - use CONTAINER_OF instead of own implementation
   - reserve ranges for Virtio MMIO params and put them
 in correct location
   - create helpers to allocate Virtio MMIO params, add
 corresponding sanity-сhecks
   - add comment why MMIO size 0x200 is chosen
   - update debug print
   - drop Wei's T-b

Changes V5 -> V6:
   - rebase on current staging

Changes V6 -> V7:
   - rebase on current staging
   - add T-b and R-b tags
   - update according to the recent changes to
 "libxl: Add support for Virtio disk configuration"

Changes V7 -> V8:
   - drop T-b and R-b tags
   - make virtio_mmio_base/irq global variables to be local in
 libxl__arch_domain_prepare_config() and initialize them at
 the beginning of the function, then rework alloc_virtio_mmio_base/irq()
 to take a pointer to virtio_mmio_base/irq variables as an argument
   - update according to the recent changes to
 "libxl: Add support for Virtio disk configuration"
---
 tools/libs/light/libxl_arm.c  | 118 +-
 xen/include/public/arch-arm.h |   7 +++
 2 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index eef1de0..37403a2 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -8,6 +8,46 @@
 #include 
 #include 
 
+/*
+ * There is no clear requirements for the total size of Virtio MMIO region.
+ * The size of control registers is 0x100 and device-specific configuration
+ * registers starts at the offset 0x100, however it's size depends on the 
device
+ * and the driver. Pick the biggest known size at the moment to cover most
+ * of the devices (also consider allowing the user to configure the size via
+ * config file for the one not conforming with the proposed value).
+ */
+#define VIRTIO_MMIO_DEV_SIZE   xen_mk_ullong(0x200)
+
+static uint64_t alloc_virtio_mmio_base(libxl__gc *gc, uint64_t 
*virtio_mmio_base)
+{
+uint64_t base = *virtio_mmio_base;
+
+/* Make sure we have enough reserved resources */
+if ((base + VIRTIO_MMIO_DEV_SIZE >
+GUEST_VIRTIO_MMIO_BASE + GUEST_VIRTIO_MMIO_SIZE)) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO BASE 
0x%"PRIx64"\n",
+base);
+return 0;
+}
+*virtio_mmio_base += VIRTIO_MMIO_DEV_SIZE;
+
+return base;
+}
+
+static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc, uint32_t *virtio_mmio_irq)
+{
+uint32_t irq = *virtio_mmio_irq;
+
+/* Make sure we have enough reserved resources */
+if (irq > GUEST_VIRTIO_MMIO_SPI_LAST) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO IRQ %u\n", irq);
+return 0;
+}
+(*virtio_mmio_irq)++;
+
+return irq;
+}
+
 static const char *gicv_to_string(libxl_gic_version gic_version)
 {
 switch (gic_version) {
@@ -26,8 +66,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 {
 uint32_t nr_spis = 0;
 unsigned int i;
-uint32_t vuart_irq;
-bool vuart_enabled = false;
+uint32_t vuart_irq, virtio_irq = 0;
+bool vuart_enabled = false, virtio_enabled = false;
+uint64_t virtio_mmio_base = GUEST_VIRTIO_MMIO_BASE;
+uint32_t virtio_mmio_irq = GUEST_VIRTIO_MMIO_SPI_FIRST;
 
 /*
  * If pl011 vuart is enabled then increment the nr_spis to allow allocation
@@ -39,6 +81,30 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
  

[PATCH V8 1/2] libxl: Add support for Virtio disk configuration

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This patch adds basic support for configuring and assisting virtio-mmio
based virtio-disk backend (emulator) which is intended to run out of
Qemu and could be run in any domain.
Although the Virtio block device is quite different from traditional
Xen PV block device (vbd) from the toolstack's point of view:
 - as the frontend is virtio-blk which is not a Xenbus driver, nothing
   written to Xenstore are fetched by the frontend currently ("vdev"
   is not passed to the frontend). But this might need to be revised
   in future, so frontend data might be written to Xenstore in order to
   support hotplugging virtio devices or passing the backend domain id
   on arch where the device-tree is not available.
 - the ring-ref/event-channel are not used for the backend<->frontend
   communication, the proposed IPC for Virtio is IOREQ/DM
it is still a "block device" and ought to be integrated in existing
"disk" handling. So, re-use (and adapt) "disk" parsing/configuration
logic to deal with Virtio devices as well.

For the immediate purpose and an ability to extend that support for
other use-cases in future (Qemu, virtio-pci, etc) perform the following
actions:
- Add new disk backend type (LIBXL_DISK_BACKEND_OTHER) and reflect
  that in the configuration
- Introduce new disk "specification" and "transport" fields to struct
  libxl_device_disk. Both are written to the Xenstore. The transport
  field is only used for the specification "virtio" and it assumes
  only "mmio" value for now.
- Introduce new "specification" option with "xen" communication
  protocol being default value.
- Add new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
  one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model

An example of domain configuration for Virtio disk:
disk = [ 'phy:/dev/mmcblk0p3, xvda1, backendtype=other, specification=virtio']

Nothing has changed for default Xen disk configuration.

Please note, this patch is not enough for virtio-disk to work
on Xen (Arm), as for every Virtio device (including disk) we need
to allocate Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree. The subsequent
patch will add these missing bits. For the current patch,
the default "irq" and "base" are just written to the Xenstore.
This is not an ideal splitting, but this way we avoid breaking
the bisectability.

Signed-off-by: Oleksandr Tyshchenko 
---
Changes RFC -> V1:
   - no changes

Changes V1 -> V2:
   - rebase according to the new location of libxl_virtio_disk.c

Changes V2 -> V3:
   - no changes

Changes V3 -> V4:
   - rebase according to the new argument for DEFINE_DEVICE_TYPE_STRUCT

Changes V4 -> V5:
   - split the changes, change the order of the patches
   - update patch description
   - don't introduce new "vdisk" configuration option with own parsing logic,
 re-use Xen PV block "disk" parsing/configuration logic for the virtio-disk
   - introduce "virtio" flag and document it's usage
   - add LIBXL_HAVE_DEVICE_DISK_VIRTIO
   - update libxlu_disk_l.[ch]
   - drop num_disks variable/MAX_VIRTIO_DISKS
   - drop Wei's T-b

Changes V5 -> V6:
   - rebase on current staging
   - use "%"PRIu64 instead of %lu for disk->base in device_disk_add()
   - update *.gen.go files

Changes V6 -> V7:
   - rebase on current staging
   - update *.gen.go files and libxlu_disk_l.[ch] files
   - update patch description
   - rework significantly to support more flexible configuration
 and have more generic basic implementation for being able to extend
 that for other use-cases (virtio-pci, qemu, etc).

Changes V7 -> V8:
   - update *.gen.go files and libxlu_disk_l.[ch] files
   - update patch description and comments in the code
   - use "specification" config option instead of "protocol"
   - update libxl_types.idl and code according to new fields
 in libxl_device_disk
---
 docs/man/xl-disk-configuration.5.pod.in   |  38 +-
 tools/golang/xenlight/helpers.gen.go  |   8 +
 tools/golang/xenlight/types.gen.go|  18 +
 tools/include/libxl.h |   7 +
 tools/libs/light/libxl_device.c   |  62 +-
 tools/libs/light/libxl_disk.c | 136 -
 tools/libs/light/libxl_internal.h |   2 +
 tools/libs/light/libxl_types.idl  |  16 +
 tools/libs/light/libxl_types_internal.idl |   1 +
 tools/libs/light/libxl_utils.c|   2 +
 tools/libs/util/libxlu_disk_l.c   | 959 +++---
 tools/libs/util/libxlu_disk_l.h   |   2 +-
 tools/libs/util/libxlu_disk_l.l   |   9 +
 tools/xl/xl_block.c   |  11 +
 14 files changed, 791 insertions(+), 480 deletions(-)

diff --git a/docs/man/xl-disk-configuration.5.pod.in 
b/docs/man/xl-disk-configuration.5.pod.in
index 71d0e86..487ffef 100644
--- a/docs/man/xl-disk-configuration.5.pod.in
+++ b/docs/man/xl-disk-configuration.5.pod.in
@@ -232,7 +232,7 @@ Specifies the backend implementation to use
 
 =i

RE: [PATCH 24/30] panic: Refactor the panic path

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Friday, April 29, 2022 
1:38 PM
> 
> On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
> > 2022
> 3:49 PM
> >> [...]
> >> +  panic_notifiers_level=
> >> +  [KNL] Set the panic notifiers execution order.
> >> +  Format: 
> >> +  We currently have 4 lists of panic notifiers; based
> >> +  on the functionality and risk (for panic success) the
> >> +  callbacks are added in a given list. The lists are:
> >> +  - hypervisor/FW notification list (low risk);
> >> +  - informational list (low/medium risk);
> >> +  - pre_reboot list (higher risk);
> >> +  - post_reboot list (only run late in panic and after
> >> +  kdump, not configurable for now).
> >> +  This parameter defines the ordering of the first 3
> >> +  lists with regards to kdump; the levels determine
> >> +  which set of notifiers execute before kdump. The
> >> +  accepted levels are:
> >> +  0: kdump is the first thing to run, NO list is
> >> +  executed before kdump.
> >> +  1: only the hypervisor list is executed before kdump.
> >> +  2 (default level): the hypervisor list and (*if*
> >> +  there's any kmsg_dumper defined) the informational
> >> +  list are executed before kdump.
> >> +  3: both the hypervisor and the informational lists
> >> +  (always) execute before kdump.
> >
> > I'm not clear on why level 2 exists.  What is the scenario where
> > execution of the info list before kdump should be conditional on the
> > existence of a kmsg_dumper?   Maybe the scenario is described
> > somewhere in the patch set and I just missed it.
> >
> 
> Hi Michael, thanks for your review/consideration. So, this idea started
> kind of some time ago. It all started with a need of exposing more
> information on kernel log *before* kdump and *before* pstore -
> specifically, we're talking about panic_print. But this cause some
> reactions, Baoquan was very concerned with that [0]. Soon after, I've
> proposed a panic notifiers filter (orthogonal) approach, to which Petr
> suggested instead doing a major refactor [1] - it finally is alive in
> the form of this series.
> 
> The theory behind the level 2 is to allow a scenario of kdump with the
> minimum amount of notifiers - what is the point in printing more
> information if the user doesn't care, since it's going to kdump? Now, if
> there is a kmsg dumper, it means that there is likely some interest in
> collecting information, and that might as well be required before the
> potential kdump (which is my case, hence the proposal on [0]).
> 
> Instead of forcing one of the two behaviors (level 1 or level 3), we
> have a middle-term/compromise: if there's interest in collecting such
> data (in the form of a kmsg dumper), we then execute the informational
> notifiers before kdump. If not, why to increase (even slightly) the risk
> for kdump?
> 
> I'm OK in removing the level 2 if people prefer, but I don't feel it's a
> burden, quite opposite - seems a good way to accommodate the somewhat
> antagonistic ideas (jump to kdump ASAP vs collecting more info in the
> panicked kernel log).
> 
> [0] https://lore.kernel.org/lkml/20220126052246.GC2086@MiWiFi-R3L-srv/
> 
> [1] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
> 

To me, it's a weak correlation between having a kmsg dumper, and
wanting or not wanting the info level output to come before kdump.
Hyper-V is one of only a few places that register a kmsg dumper, so most
Linux instances outside of Hyper-V guest (and PowerPC systems?) will have
the info level output after kdump.  It seems like anyone who cared strongly
about the info level output would set the panic_notifier_level to 1 or to 3
so that the result is more deterministic.  But that's just my opinion, and
it's probably an opinion that is not as well informed on the topic as some
others in the discussion. So keeping things as in your patch set is not a
show-stopper for me.

However, I would request a clarification in the documentation.   The
panic_notifier_level affects not only the hypervisor, informational,
and pre_reboot lists, but it also affects panic_print_sys_info() and
kmsg_dump().  Specifically, at level 1, panic_print_sys_info() and
kmsg_dump() will not be run before kdump.  At level 3, they will
always be run before kdump.  Your documentation above mentions
"informational lists" (plural), which I take to vaguely include
kmsg_dump() and panic_print_sys_info(), but being explicit about
the effect would be better.

Michael

> 
> >[...]
> >> +   * Based on the level configured (smaller than 4), we clear the
> >> +   * proper bits in "panic_notifiers_bits". Not

Re: [PATCH v2] xen/arm: gnttab: cast unused macro arguments to void

[Julien Grall]

Hi,

On 28/04/2022 10:46, Michal Orzel wrote:

Function unmap_common_complete (common/grant_table.c) defines and sets
a variable ld that is later on passed to a macro:
gnttab_host_mapping_get_page_type().
On Arm this macro does not make use of any arguments causing a compiler
to warn about unused-but-set variable (when -Wunused-but-set-variable
is enabled). Fix it by casting the arguments to void in macro's body.

While there, take the opportunity to modify other macros in this file
that do not make use of all the arguments to prevent similar issues in
the future.

Signed-off-by: Michal Orzel 
---
Changes since v1:
-standalone patch carved out from a series (other patches already merged)
-v1 was ([3/8] gnttab: Remove unused-but-set variable)
-modify macro on Arm instead of removing ld variable
---
  xen/arch/arm/include/asm/grant_table.h | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/include/asm/grant_table.h 
b/xen/arch/arm/include/asm/grant_table.h
index d31a4d6805..5bcd1ec528 100644
--- a/xen/arch/arm/include/asm/grant_table.h
+++ b/xen/arch/arm/include/asm/grant_table.h
@@ -31,10 +31,11 @@ static inline void gnttab_mark_dirty(struct domain *d, 
mfn_t mfn)
  
  int create_grant_host_mapping(unsigned long gpaddr, mfn_t mfn,

unsigned int flags, unsigned int cache_flags);
-#define gnttab_host_mapping_get_page_type(ro, ld, rd) (0)
+#define gnttab_host_mapping_get_page_type(ro, ld, rd) \
+((void)(ro), (void)(ld), (void)(rd), 0)


I would switch to a static inline helper:

static inline bool
gnttab_host_mapping_get_page_type(bool ro, struct domain *ld,
  struct domian *rd)
{
return false;
}

Note the switch from 0 to false as the function is technically returning 
a boolean (see the x86 implementation).



  int replace_grant_host_mapping(unsigned long gpaddr, mfn_t mfn,
 unsigned long new_gpaddr, unsigned int flags);
-#define gnttab_release_host_mappings(domain) 1
+#define gnttab_release_host_mappings(domain) ((void)(domain), 1)


Same here.

  
  /*

   * The region used by Xen on the memory will never be mapped in DOM0
@@ -89,10 +90,12 @@ int replace_grant_host_mapping(unsigned long gpaddr, mfn_t 
mfn,
  })
  
  #define gnttab_shared_gfn(d, t, i)   \

-(((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i])
+((void)(d),  \
+ ((i) >= nr_grant_frames(t)) ? INVALID_GFN : (t)->arch.shared_gfn[i])
  
-#define gnttab_status_gfn(d, t, i)   \

-(((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i])
+#define gnttab_status_gfn(d, t, i)\
+((void)(d),   \
+ ((i) >= nr_status_frames(t)) ? INVALID_GFN : (t)->arch.status_gfn[i])


I share Jan's opinion here. If we want to evaluate d, then we should 
make sure t and i should be also evaluated once. However, IIRC, they 
can't be turned to static inline because the type of t (struct 
grant_table) is not fully defined yet.


Cheers

--
Julien Grall

RE: [PATCH 19/30] panic: Add the panic hypervisor notifier list

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Friday, April 29, 2022 
11:04 AM
> 
> On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
> > 2022
> 3:49 PM
> >> [...]
> >>
> >> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
> >>if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
> >>kmsg_dump_unregister(&hv_kmsg_dumper);
> >>unregister_die_notifier(&hyperv_die_report_block);
> >> -  atomic_notifier_chain_unregister(&panic_notifier_list,
> >> +  atomic_notifier_chain_unregister(&panic_hypervisor_list,
> >>&hyperv_panic_report_block);
> >>}
> >>
> >
> > Using the hypervisor_list here produces a bit of a mismatch.  In many cases
> > this notifier will do nothing, and will defer to the kmsg_dump() mechanism
> > to notify the hypervisor about the panic.   Running the kmsg_dump()
> > mechanism is linked to the info_list, so I'm thinking the Hyper-V panic 
> > report
> > notifier should be on the info_list as well.  That way the reporting 
> > behavior
> > is triggered at the same point in the panic path regardless of which
> > reporting mechanism is used.
> >
> 
> Hi Michael, thanks for your feedback! I agree that your idea could work,
> but...there is one downside: imagine the kmsg_dump() approach is not set
> in some Hyper-V guest, then we would rely in the regular notification
> mechanism [hv_die_panic_notify_crash()], right?
> But...you want then to run this notifier in the informational list,
> which...won't execute *by default* before kdump if no kmsg_dump() is
> set. So, this logic is convoluted when you mix it with the default level
> concept + kdump.

Yes, you are right.  But to me that speaks as much to the linkage
between the informational list and kmsg_dump() being the core
problem.  But as I described in my reply to Patch 24, I can live with
the linkage as-is.

FWIW, guests on newer versions of Hyper-V will always register a
kmsg dumper.  The flags that are tested to decide whether to
register provide compatibility with older versions of Hyper-V that 
don’t support the 4K bytes of notification info.

> 
> May I suggest something? If possible, take a run with this patch set +
> DEBUG_NOTIFIER=y, in *both* cases (with and without the kmsg_dump()
> set). I did that and they run almost at the same time...I've checked the
> notifiers called, it's like almost nothing runs in-between.
> 
> I feel the panic notification mechanism does really fit with a
> hypervisor list, it's a good match with the nature of the list, which
> aims at informing the panic notification to the hypervisor/FW.
> Of course we can modify it if you prefer...but please take into account
> the kdump case and how it complicates the logic.

I agree that the runtime effect of one list vs. the other is nil.  The
code works and can stay as you written it.

I was trying to align from a conceptual standpoint.  It was a bit
unexpected that one path would be on the hypervisor list, and the
other path effectively on the informational list.  When I see
conceptual mismatches like that, I tend to want to understand why,
and if there is something more fundamental that is out-of-whack.


> 
> Let me know your considerations, in case you can experiment with the
> patch set as-is.
> Cheers,
> 
> 
> Guilherme

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

[Guilherme G. Piccoli]

On 03/05/2022 14:44, Michael Kelley (LINUX) wrote:
> [...]
>>
>> Hi Michael, thanks for your feedback! I agree that your idea could work,
>> but...there is one downside: imagine the kmsg_dump() approach is not set
>> in some Hyper-V guest, then we would rely in the regular notification
>> mechanism [hv_die_panic_notify_crash()], right?
>> But...you want then to run this notifier in the informational list,
>> which...won't execute *by default* before kdump if no kmsg_dump() is
>> set. So, this logic is convoluted when you mix it with the default level
>> concept + kdump.
> 
> Yes, you are right.  But to me that speaks as much to the linkage
> between the informational list and kmsg_dump() being the core
> problem.  But as I described in my reply to Patch 24, I can live with
> the linkage as-is.

Thanks for the feedback Michael!

> [...] 
>> I feel the panic notification mechanism does really fit with a
>> hypervisor list, it's a good match with the nature of the list, which
>> aims at informing the panic notification to the hypervisor/FW.
>> Of course we can modify it if you prefer...but please take into account
>> the kdump case and how it complicates the logic.
> 
> I agree that the runtime effect of one list vs. the other is nil.  The
> code works and can stay as you written it.
> 
> I was trying to align from a conceptual standpoint.  It was a bit
> unexpected that one path would be on the hypervisor list, and the
> other path effectively on the informational list.  When I see
> conceptual mismatches like that, I tend to want to understand why,
> and if there is something more fundamental that is out-of-whack.
> 

Totally agree with you here, I am like that as well - try to really
understand the details, this is very important specially in this patch
set, since it's a refactor and affects every user of the notifiers
infrastructure.

Again, just to double-say it: feel free to suggest any change for the
Hyper-V portion (might as well for any patch in the series, indeed) -
you and the other Hyper-V maintainers own this code and I'd be glad to
align with your needs, you are honor citizens in the panic notifiers
area, being one the most heavy users for that =)

Cheers,


Guilherme

Re: [PATCH 24/30] panic: Refactor the panic path

[Guilherme G. Piccoli]

On 03/05/2022 14:31, Michael Kelley (LINUX) wrote:
> [...]
> 
> To me, it's a weak correlation between having a kmsg dumper, and
> wanting or not wanting the info level output to come before kdump.
> Hyper-V is one of only a few places that register a kmsg dumper, so most
> Linux instances outside of Hyper-V guest (and PowerPC systems?) will have
> the info level output after kdump.  It seems like anyone who cared strongly
> about the info level output would set the panic_notifier_level to 1 or to 3
> so that the result is more deterministic.  But that's just my opinion, and
> it's probably an opinion that is not as well informed on the topic as some
> others in the discussion. So keeping things as in your patch set is not a
> show-stopper for me.
> 
> However, I would request a clarification in the documentation.   The
> panic_notifier_level affects not only the hypervisor, informational,
> and pre_reboot lists, but it also affects panic_print_sys_info() and
> kmsg_dump().  Specifically, at level 1, panic_print_sys_info() and
> kmsg_dump() will not be run before kdump.  At level 3, they will
> always be run before kdump.  Your documentation above mentions
> "informational lists" (plural), which I take to vaguely include
> kmsg_dump() and panic_print_sys_info(), but being explicit about
> the effect would be better.
> 
> Michael

Thanks again Michael, to express your points and concerns - great idea
of documentation improvement here, I'll do that for V2, for sure.

The idea of "defaulting" to skip the info list on kdump (if no
kmsg_dump() is set) is again a mechanism that aims at accommodating all
users and concerns of antagonistic goals, kdump vs notifier lists.

Before this patch set, by default no notifier executed before kdump. So,
the "pendulum"  was strongly on kdump side, and clearly this was a
sub-optimal decision - proof of that is that both Hyper-V / PowerPC code
forcibly set the "crash_kexec_post_notifiers". The goal here is to have
a more lightweight list that by default runs before kdump, a secondary
list that only runs before kdump if there's usage for that (either user
sets that or kmsg_dumper set is considered a valid user), and the
remaining notifiers run by default only after kdump, all of that very
customizable through the levels idea.

Now, one thing we could do to improve consistency for the hyper-v case:
having a kmsg_dump_once() helper, and *for Hyper-V only*, call it on the
hypervisor list, within the info notifier (that would be moved to
hypervisor list, ofc).
Let's wait for more feedback on that, just throwing some ideas in order
we can have everyone happy with the end-result!

Cheers,


Guilherme

Re: [PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3

[Julien Grall]

Hi Bertrand,

On 03/05/2022 10:38, Bertrand Marquis wrote:

Sync arm64 sysreg bit shift definitions with status of Linux kernel as
of 5.18-rc3 version (linux commit b2d229d4ddb1).
Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
sanitization of ISAR2 registers.
Please outline which specific commits you are actually backported. This 
would help to know what changed, why and also keep track of the autorships.


When possible, the changes should be separated to match each Linux 
commit we backport.



Complete AA64ISAR2 and AA64MMFR1 with more fields.
While there add a comment for MMFR bitfields as for other registers in
the cpuinfo structure definition.


AFAICT, this patch is doing 3 different things that are somewhat related:
  - Sync cpufeature.c
  - Update the headers with unused defines
  - Complete the structure cpufeature.h

All those changes seem to be independent, so I think they should be done 
separately. This would help to keep the authorship right (your code vs 
Linux code).




Signed-off-by: Bertrand Marquis 
---
  xen/arch/arm/arm64/cpufeature.c  | 18 +-
  xen/arch/arm/include/asm/arm64/sysregs.h | 76 
  xen/arch/arm/include/asm/cpufeature.h| 14 -
  3 files changed, 91 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
index 6e5d30dc7b..d9039d37b2 100644
--- a/xen/arch/arm/arm64/cpufeature.c
+++ b/xen/arch/arm/arm64/cpufeature.c
@@ -143,6 +143,16 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
ARM64_FTR_END,
  };
  
+static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {

+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, 
ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
+   ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+  FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
+   ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
So we are using CONFIG_ARM64_PTR_AUTH. But this is not defined in 
Kconfig. I realize there are more in cpufeature.c (somehow I didn't spot 
during preview), but I don't think this is right to define CONFIG_* 
without an associated entry in Kconfig.


In one hand, I think it would be odd to add an entry in Kconfig because 
Xen wouldn't properly work if selected. On the other hand, it is useful 
if when we will implement pointer authentification.


So maybe we should just add the Kconfig entry with a comment explaning 
why they are not selected. Any thoughts?


Cheers,

--
Julien Grall

RE: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Friday, April 29, 2022 
3:35 PM
> 
> Hi Michael, first of all thanks for the great review, much appreciated.
> Some comments inline below:
> 
> On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> > [...]
> >> hypervisor I/O completion), so we postpone that to run late. But more
> >> relevant: this *same* vmbus unloading happens in the crash_shutdown()
> >> handler, so if kdump is set, we can safely skip this panic notifier and
> >> defer such clean-up to the kexec crash handler.
> >
> > While the last sentence is true for Hyper-V on x86/x64, it's not true for
> > Hyper-V on ARM64.  x86/x64 has the 'machine_ops' data structure
> > with the ability to provide a custom crash_shutdown() function, which
> > Hyper-V does in the form of hv_machine_crash_shutdown().  But ARM64
> > has no mechanism to provide such a custom function that will eventually
> > do the needed vmbus_initiate_unload() before running kdump.
> >
> > I'm not immediately sure what the best solution is for ARM64.  At this
> > point, I'm just pointing out the problem and will think about the tradeoffs
> > for various possible solutions.  Please do the same yourself. :-)
> >
> 
> Oh, you're totally right! I just assumed ARM64 would the the same, my
> bad. Just to propose some alternatives, so you/others can also discuss
> here and we can reach a consensus about the trade-offs:
> 
> (a) We could forget about this change, and always do the clean-up here,
> not relying in machine_crash_shutdown().
> Pro: really simple, behaves the same as it is doing currently.
> Con: less elegant/concise, doesn't allow arm64 customization.
> 
> (b) Add a way to allow ARM64 customization of shutdown crash handler.
> Pro: matches x86, more customizable, improves arm64 arch code.
> Con: A tad more complex.
> 
> Also, a question that came-up: if ARM64 has no way of calling special
> crash shutdown handler, how can you execute hv_stimer_cleanup() and
> hv_synic_disable_regs() there? Or are they not required in ARM64?
> 

My suggestion is to do (a) for now.  I suspect (b) could be a more
extended discussion and I wouldn't want your patch set to get held
up on that discussion.  I don't know what the sense of the ARM64
maintainers would be toward (b).  They have tried to avoid picking
up code warts like have accumulated on the x86/x64 side over the
years, and I agree with that effort.  But as more and varied
hypervisors become available for ARM64, it seems like a framework
for supporting a custom shutdown handler may become necessary.
But that could take a little time.

You are right about hv_stimer_cleanup() and hv_synic_disable_regs().
We are not running these when a panic occurs on ARM64, and we
should be, though the risk is small.   We will pursue (b) and add
these additional cleanups as part of that.  But again, I would suggest
doing (a) for now, and we will switch back to your solution once
(b) is in place.

> 
> >>
> >> (c) There is also a Hyper-V framebuffer panic notifier, which relies in
> >> doing a vmbus operation that demands a valid connection. So, we must
> >> order this notifier with the panic notifier from vmbus_drv.c, in order to
> >> guarantee that the framebuffer code executes before the vmbus connection
> >> is unloaded.
> >
> > Patch 21 of this set puts the Hyper-V FB panic notifier on the pre_reboot
> > notifier list, which means it won't execute before the VMbus connection
> > unload in the case of kdump.   This notifier is making sure that Hyper-V
> > is notified about the last updates made to the frame buffer before the
> > panic, so maybe it needs to be put on the hypervisor notifier list.  It
> > sends a message to Hyper-V over its existing VMbus channel, but it
> > does not wait for a reply.  It does, however, obtain a spin lock on the
> > ring buffer used to communicate with Hyper-V.   Unless someone has
> > a better suggestion, I'm inclined to take the risk of blocking on that
> > spin lock.
> 
> The logic behind that was: when kdump is set, we'd skip the vmbus
> disconnect on notifiers, deferring that to crash_shutdown(), logic this
> one refuted in the above discussion on ARM64 (one more Pro argument to
> the idea of refactoring aarch64 code to allow a custom crash shutdown
> handler heh). But you're right, for the default level 2, we skip the
> pre_reboot notifiers on kdump, effectively skipping this notifier.
> 
> Some ideas of what we can do here:
> 
> I) we could change the framebuffer notifier to rely on trylocks, instead
> of risking a lockup scenario, and with that, we can execute it before
> the vmbus disconnect in the hypervisor list;

I think we have to do this approach for now.

> 
> II) we ignore the hypervisor notifier in case of kdump _by default_, and
> if the users don't want that, they can always set the panic notifier
> level to 4 and run all notifiers prior to kdump; would that be terrible
> you think? Kdump users might don't care about the framebuffer...
> 
> III) we go with approach (b

Re: [PATCH 2/3] xen/arm: Advertise workaround 1 if we apply 3

[Julien Grall]

Hi Bertrand,

On 03/05/2022 10:38, Bertrand Marquis wrote:

SMCC_WORKAROUND_3 is handling both Spectre v2 and spectre BHB.
So when a guest is asking if we support workaround 1, tell yes if we
apply workaround 3 on exception entry as it handles it.

This will allow guests not supporting Spectre BHB but impacted by
spectre v2 to still handle it correctly.
The modified behaviour is coherent with what the Linux kernel does in
KVM for guests.

While there use ARM_SMCCC_SUCCESS instead of 0 for the return code value
for workaround detection to be coherent with Workaround 2 handling.

Signed-off-by: Bertrand Marquis 


Acked-by: Julien Grall 

I think we should also consider for backport.

Cheers,

--
Julien Grall

Re: [PATCH 3/3] xen/arm: Add sb instruction support

[Julien Grall]

Hi Bertrand,

On 03/05/2022 10:38, Bertrand Marquis wrote:

This patch is adding sb instruction support when it is supported by a
CPU on arm64.
To achieve this, the "sb" macro is moved to sub-arch macros.h so that we
can use sb instruction when available through alternative on arm64 and
keep the current behaviour on arm32.


SB is also supported on Arm32. So I would prefer to introduce the 
encoding right now and avoid duplicating the .macro sb.



A new cpuerrata capability is introduced to enable the alternative


'sb' is definitely not an erratum. Errata are for stuff that are meant 
to be specific to one (or multiple) CPU and they are not part of the 
architecture.


This is the first time we introduce a feature in Xen. So we need to add 
a new array in cpufeature.c that will cover 'SB' for now. In future we 
could add feature like pointer auth, LSE atomics...



code for sb when the support is detected using isa64 coprocessor


s/coprocessor/system/


register.
The sb instruction is encoded using its hexadecimal value.


This is necessary to avoid recursive macro, right?


diff --git a/xen/arch/arm/include/asm/arm64/macros.h 
b/xen/arch/arm/include/asm/arm64/macros.h
index 140e223b4c..e639cec400 100644
--- a/xen/arch/arm/include/asm/arm64/macros.h
+++ b/xen/arch/arm/include/asm/arm64/macros.h
@@ -1,6 +1,24 @@
  #ifndef __ASM_ARM_ARM64_MACROS_H
  #define __ASM_ARM_ARM64_MACROS_H
  
+#include 

+
+/*
+ * Speculative barrier
+ */
+.macro sb
+alternative_if_not ARM64_HAS_SB
+dsb nsh
+isb
+alternative_else
+/*
+ * SB encoding as given in chapter C6.2.264 of ARM ARM (DDI 0487H.a).
+ */


NIT: Please align the comment with ".inst" below. I also don't think it 
is necessary to mention the spec here. The instruction encoding is not 
going to change.



+.inst 0xd50330ff
+nop


Why do we need the NOP?


+alternative_endif
+.endm
+
  /*
   * @dst: Result of get_cpu_info()
   */
diff --git a/xen/arch/arm/include/asm/cpufeature.h 
b/xen/arch/arm/include/asm/cpufeature.h
index 4719de47f3..9370805900 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -67,8 +67,9 @@
  #define ARM_WORKAROUND_BHB_LOOP_24 13
  #define ARM_WORKAROUND_BHB_LOOP_32 14
  #define ARM_WORKAROUND_BHB_SMCC_3 15
+#define ARM64_HAS_SB 16
  
-#define ARM_NCAPS   16

+#define ARM_NCAPS   17
  
  #ifndef __ASSEMBLY__
  
diff --git a/xen/arch/arm/include/asm/macros.h b/xen/arch/arm/include/asm/macros.h

index 1aa373760f..91ea3505e4 100644
--- a/xen/arch/arm/include/asm/macros.h
+++ b/xen/arch/arm/include/asm/macros.h
@@ -5,15 +5,6 @@
  # error "This file should only be included in assembly file"
  #endif
  
-/*

- * Speculative barrier
- * XXX: Add support for the 'sb' instruction
- */
-.macro sb
-dsb nsh
-isb
-.endm
-
  #if defined (CONFIG_ARM_32)
  # include 
  #elif defined(CONFIG_ARM_64)


Cheers,

--
Julien Grall

Re: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers

[Guilherme G. Piccoli]

On 03/05/2022 15:13, Michael Kelley (LINUX) wrote:
> [...]
>> (a) We could forget about this change, and always do the clean-up here,
>> not relying in machine_crash_shutdown().
>> Pro: really simple, behaves the same as it is doing currently.
>> Con: less elegant/concise, doesn't allow arm64 customization.
>>
>> (b) Add a way to allow ARM64 customization of shutdown crash handler.
>> Pro: matches x86, more customizable, improves arm64 arch code.
>> Con: A tad more complex.
>>
>> Also, a question that came-up: if ARM64 has no way of calling special
>> crash shutdown handler, how can you execute hv_stimer_cleanup() and
>> hv_synic_disable_regs() there? Or are they not required in ARM64?
>>
> 
> My suggestion is to do (a) for now.  I suspect (b) could be a more
> extended discussion and I wouldn't want your patch set to get held
> up on that discussion.  I don't know what the sense of the ARM64
> maintainers would be toward (b).  They have tried to avoid picking
> up code warts like have accumulated on the x86/x64 side over the
> years, and I agree with that effort.  But as more and varied
> hypervisors become available for ARM64, it seems like a framework
> for supporting a custom shutdown handler may become necessary.
> But that could take a little time.
> 
> You are right about hv_stimer_cleanup() and hv_synic_disable_regs().
> We are not running these when a panic occurs on ARM64, and we
> should be, though the risk is small.   We will pursue (b) and add
> these additional cleanups as part of that.  But again, I would suggest
> doing (a) for now, and we will switch back to your solution once
> (b) is in place.
> 

Thanks again Michael, I'll stick with (a) for now. I'll check with ARM64
community about that, and I might even try to implement something in
parallel (if you are not already working on that - lemme know please),
so we don't get stuck here. As you said, I feel that this is more and
more relevant as the number of panic/crash/kexec scenarios tend to
increase in ARM64.


>> [...]
>> Some ideas of what we can do here:
>>
>> I) we could change the framebuffer notifier to rely on trylocks, instead
>> of risking a lockup scenario, and with that, we can execute it before
>> the vmbus disconnect in the hypervisor list;
> 
> I think we have to do this approach for now.
> 
>>
>> II) we ignore the hypervisor notifier in case of kdump _by default_, and
>> if the users don't want that, they can always set the panic notifier
>> level to 4 and run all notifiers prior to kdump; would that be terrible
>> you think? Kdump users might don't care about the framebuffer...
>>
>> III) we go with approach (b) above and refactor arm64 code to allow the
>> custom crash handler on kdump time, then [with point (I) above] the
>> logic proposed in this series is still valid - seems more and more the
>> most correct/complete solution.
> 
> But even when/if we get approach (b) implemented, having the
> framebuffer notifier on the pre_reboot list is still too late with the
> default of panic_notifier_level = 2.  The kdump path will reset the
> VMbus connection and then the framebuffer notifier won't work.
> 

OK, perfect! I'll work something along these lines in V2, allowing the
FB notifier to always run in the hypervisor list before the vmbus unload
mechanism.


>> [...]
 +static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long 
 val,
  void *args)
 +{
 +  if (!kexec_crash_loaded())
>>>
>>> I'm not clear on the purpose of this condition.  I think it means
>>> we will skip the vmbus_initiate_unload() if a panic occurs in the
>>> kdump kernel.  Is there a reason a panic in the kdump kernel
>>> should be treated differently?  Or am I misunderstanding?
>>
>> This is really related with the point discussed in the top of this
>> response - I assumed both ARM64/x86_64 would behave the same and
>> disconnect the vmbus through the custom crash handler when kdump is set,
>> so worth skipping it here in the notifier. But that's not true for ARM64
>> as you pointed, so this guard against kexec is really part of the
>> decision/discussion on what to do with ARM64 heh
> 
> But note that vmbus_initiate_unload() already has a guard built-in.
> If the intent of this test is just as a guard against running twice,
> then it isn't needed.

Since we're going to avoid relying in the custom crash_shutdown(), due
to the lack of ARM64 support for now, this check will be removed in V2.

Its purpose was to skip the notifier *proactively* in case kexec is set,
given that...once kexec happens, the custom crash_shutdown() would run
the same function (wrong assumption for ARM64, my bad).

Postponing that slightly would maybe gain us some time while the
hypervisor finish its work, so we'd delay less in the vmbus unload path
- that was the rationale behind this check.


Cheers!

[ovmf test] 170054: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  785 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

[Guilherme G. Piccoli]

On 03/05/2022 15:03, Evan Green wrote:
> [...]
> gsmi_shutdown_reason() is a common function called in other scenarios
> as well, like reboot and thermal trip, where it may still make sense
> to wait to acquire a spinlock. Maybe we should add a parameter to
> gsmi_shutdown_reason() so that you can get your change on panic, but
> we don't convert other callbacks into try-fail scenarios causing us to
> miss logs.
> 

Hi Evan, thanks for your feedback, much appreciated!
What I've done in other cases like this was to have a helper checking
the spinlock in the panic notifier - if we can acquire that, go ahead
but if not, bail out. For a proper example of an implementation, check
patch 13 of the series:
https://lore.kernel.org/lkml/20220427224924.592546-14-gpicc...@igalia.com/ .

Do you agree with that, or prefer really a parameter in
gsmi_shutdown_reason() ? I'll follow your choice =)


> Though thinking more about it, is this really a Good Change (TM)? The
> spinlock itself already disables interrupts, meaning the only case
> where this change makes a difference is if the panic happens from
> within the function that grabbed the spinlock (in which case the
> callback is also likely to panic), or in an NMI that panics within
> that window. The downside of this change is that if one core was
> politely working through an event with the lock held, and another core
> panics, we now might lose the panic log, even though it probably would
> have gone through fine assuming the other core has a chance to
> continue.

My feeling is that this is a good change, indeed - a lot of places are
getting changed like this, in this series.

Reasoning: the problem with your example is that, by default, secondary
CPUs are disabled in the panic path, through an IPI mechanism. IPIs take
precedence and interrupt the work in these CPUs, effectively
interrupting the "polite work" with the lock held heh

Then, such CPU is put to sleep and we finally reach the panic notifier
hereby discussed, in the main CPU. If the other CPU was shut-off *with
the lock held*, it's never finishing such work, so the lock is never to
be released. Conclusion: the spinlock can't be acquired, hence we broke
the machine (which is already broken, given it's panic) in the path of
this notifier.
This should be really rare, but..possible. So I think we should protect
against this scenario.

We can grab others' feedback if you prefer, and of course you have the
rights to refuse this change in the gsmi code, but from my
point-of-view, I don't see any advantage in just assume the risk,
specially since the change is very very simple.

Cheers,


Guilherme

[ovmf test] 170055: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  786 attempts
Testing same since   170038  2022-05-03 10:12:47 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 
  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 5915 lines long.)

[ovmf test] 170059: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  787 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   11 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  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 
  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 5915 lines long.)

[qemu-mainline test] 170051: tolerable FAIL - PUSHED

[osstest service owner]

flight 170051 qemu-mainline real [real]
flight 170057 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170051/
http://logs.test-lab.xenproject.org/osstest/logs/170057/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt   8 xen-bootfail pass in 170057-retest
 test-amd64-i386-libvirt-raw  16 guest-saverestore   fail pass in 170057-retest

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

version targeted for testing:
 qemuu5f14cfe187e2fc3c71f4536b2021b8118d224239
baseline version:
 qemuuf5643914a9e8f79

[ovmf test] 170062: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  788 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   12 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 
  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 5915 lines long.)

Re: [PATCH V8 2/2] libxl: Introduce basic virtio-mmio support on Arm

[Stefano Stabellini]

On Tue, 3 May 2022, Oleksandr Tyshchenko wrote:
> From: Julien Grall 
> 
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple Virtio devices, reserve corresponding ranges.
> For now, we reserve 1MB for memory regions and 10 SPIs.
> 
> As these helpers should be used for every Virtio device attached
> to the Guest, call them for Virtio disk(s).
> 
> Please note, with statically allocated Virtio IRQs there is
> a risk of a clash with a physical IRQs of passthrough devices.
> For the first version, it's fine, but we should consider allocating
> the Virtio IRQs automatically. Thankfully, we know in advance which
> IRQs will be used for passthrough to be able to choose non-clashed
> ones.
> 
> Signed-off-by: Julien Grall 
> Signed-off-by: Oleksandr Tyshchenko 

Reviewed-by: Stefano Stabellini 


> ---
> Please note, this is a split/cleanup/hardening of Julien's PoC:
> "Add support for Guest IO forwarding to a device emulator"
> 
> Changes RFC -> V1:
>- was squashed with:
>  "[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
>  "[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into 
> virtio-mmio device node"
>  "[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
>- move VirtIO MMIO #define-s to xen/include/public/arch-arm.h
> 
> Changes V1 -> V2:
>- update the author of a patch
> 
> Changes V2 -> V3:
>- no changes
> 
> Changes V3 -> V4:
>- no changes
> 
> Changes V4 -> V5:
>- split the changes, change the order of the patches
>- drop an extra "virtio" configuration option
>- update patch description
>- use CONTAINER_OF instead of own implementation
>- reserve ranges for Virtio MMIO params and put them
>  in correct location
>- create helpers to allocate Virtio MMIO params, add
>  corresponding sanity-сhecks
>- add comment why MMIO size 0x200 is chosen
>- update debug print
>- drop Wei's T-b
> 
> Changes V5 -> V6:
>- rebase on current staging
> 
> Changes V6 -> V7:
>- rebase on current staging
>- add T-b and R-b tags
>- update according to the recent changes to
>  "libxl: Add support for Virtio disk configuration"
> 
> Changes V7 -> V8:
>- drop T-b and R-b tags
>- make virtio_mmio_base/irq global variables to be local in
>  libxl__arch_domain_prepare_config() and initialize them at
>  the beginning of the function, then rework alloc_virtio_mmio_base/irq()
>  to take a pointer to virtio_mmio_base/irq variables as an argument
>- update according to the recent changes to
>  "libxl: Add support for Virtio disk configuration"
> ---
>  tools/libs/light/libxl_arm.c  | 118 
> +-
>  xen/include/public/arch-arm.h |   7 +++
>  2 files changed, 123 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index eef1de0..37403a2 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -8,6 +8,46 @@
>  #include 
>  #include 
>  
> +/*
> + * There is no clear requirements for the total size of Virtio MMIO region.
> + * The size of control registers is 0x100 and device-specific configuration
> + * registers starts at the offset 0x100, however it's size depends on the 
> device
> + * and the driver. Pick the biggest known size at the moment to cover most
> + * of the devices (also consider allowing the user to configure the size via
> + * config file for the one not conforming with the proposed value).
> + */
> +#define VIRTIO_MMIO_DEV_SIZE   xen_mk_ullong(0x200)
> +
> +static uint64_t alloc_virtio_mmio_base(libxl__gc *gc, uint64_t 
> *virtio_mmio_base)
> +{
> +uint64_t base = *virtio_mmio_base;
> +
> +/* Make sure we have enough reserved resources */
> +if ((base + VIRTIO_MMIO_DEV_SIZE >
> +GUEST_VIRTIO_MMIO_BASE + GUEST_VIRTIO_MMIO_SIZE)) {
> +LOG(ERROR, "Ran out of reserved range for Virtio MMIO BASE 
> 0x%"PRIx64"\n",
> +base);
> +return 0;
> +}
> +*virtio_mmio_base += VIRTIO_MMIO_DEV_SIZE;
> +
> +return base;
> +}
> +
> +static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc, uint32_t 
> *virtio_mmio_irq)
> +{
> +uint32_t irq = *virtio_mmio_irq;
> +
> +/* Make sure we have enough reserved resources */
> +if (irq > GUEST_VIRTIO_MMIO_SPI_LAST) {
> +LOG(ERROR, "Ran out of reserved range for Virtio MMIO IRQ %u\n", 
> irq);
> +return 0;
> +}
> +(*virtio_mmio_irq)++;
> +
> +return irq;
> +}
> +
>  static const char *gicv_to_string(libxl_gic_version gic_version)
>  {
>  switch (gic_version) {
> @@ -26,8 +66,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  {
>  uint32_t nr_spis = 0;
>  unsigned int i;
> -uint32_t vuart_irq;
> -bool vuart_enabled = false;
> +uint32_t vuar

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

[Rob Herring]

On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
> 
> On 03.05.22 00:59, Rob Herring wrote:
> 
> Hello Rob
> 
> 
> > 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?
> 
> From my understanding - yes.
> 
> As, I think, any device node describing virtulized device in the guest
> device tree can have this property.  Initially (in the RFC series) the
> "solution to restrict memory access using Xen grant mappings" was
> virtio-specific.
> 
> Although the support of virtio is a primary target of this series, we
> decided to generalize this work and expand it to any device [1]. So the Xen
> grant mappings scheme (this property to be used for) can be theoretically
> used for any device emulated by the Xen backend.
> 
> 
> > > +
> > > +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
> 
> ok, will change
> 
> 
> > 
> > > +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
> 
> Thank you for pointing this out, my fault, I haven't "properly" checked this
> before. I think, we need to remove "compatible = "virtio,mmio"; here

Uhh, no. That just means the example is incomplete. You need to add this 
property or reference this schema from virtio/mmio.yaml.


> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> index 2daa8aa..d2f2140 100644
> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -28,7 +28,7 @@ additionalProperties: true
>  examples:
>    - |
>  virtio_block@3000 {
> -    compatible = "virtio,mmio";
> +    /* ... */
>  reg = <0x3000 0x100>;
>  interrupts = <41>;
> 
> 
> 
> > 
> > The property has to be added to the virtio/mmio.yaml schema. If it is
> > not needed elsewhere, then *just* add the property there.
> 
> As I described above, the property is not virtio specific and can be used
> for any virtualized device for which Xen grant mappings s

[ovmf test] 170066: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   63 days  789 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   13 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 
  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 5915 lines long.)

[linux-linus test] 170053: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine-uefi  5 host-install  broken REGR. vs. 170001
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 170001

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

version targeted for testing:
 linuxef8e4d3c2ab1f47f63b6c7e578266b7e5cc9cd1b
baseline version:
 linux9050ba3a61a4b5bd84c2cde092a100404f814f31

Last test of basis   170001  2022-05-02 19:09:59 Z1 days
Testing same since   170053  2022-05-03 17:42:45 Z0 days1 attempts


People who touched revisions under test:
  Adam Wujek 
  Armin Wolf 
  Denis Pauk 
  Guenter Roeck 
  Ji-Ze Hong (Peter Hong) 
  Ji-Ze Hong (Peter Hong) 
  Linus Torvalds 
  Rob Herring 
  Zev Weiss 
  Zheyu Ma 

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

[ovmf test] 170069: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   64 days  790 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   14 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 
  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 5915 lines long.)

[ovmf test] 170073: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   64 days  791 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   15 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 
  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 5915 lines long.)

[ovmf test] 170077: regressions - FAIL

[osstest service owner]

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   64 days
Failing since168258  2022-03-01 01:55:31 Z   64 days  792 attempts
Testing same since   170038  2022-05-03 10:12:47 Z0 days   16 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 
  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 5915 lines long.)

OPNSense running in domU has no network connectivity on 5.15.29+

[Colton Reeder]

Hello,

I am running the FreeBSD-based router OS OPNSense in a domU. I
recently upgraded my dom0 kernel from 5.15.26 to 5.15.32 and with the
new kernel, OPNSense had no connectivity. I downloaded from kernel.org
5.15.26-32, built and installed each version and booted them
consecutively until I found the version that no longer worked. It
turned out to be 5.15.29.

I looked through the change log of 5.15.29 and found two commits for xen-netback

commit 2708ceb4e5cc84ef179bad25a2d7890573ef78be commit
fe39ab30dcc204e321c2670cc1cf55904af35d01

I reverted these changes (a revert of a revert, yes)  in 5.15.32,
built and installed. Now the network works. Now I dont know enough to
know thats for sure the right fix. Maybe I have a config issue, I dont
know, but reverting that change fixes the problem. What should I do?
I was asked to provide xenstore -ls https://pastebin.com/hHPWgrEy

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

[Evan Green]

On Wed, Apr 27, 2022 at 3:51 PM Guilherme G. Piccoli
 wrote:
>
> Currently the gsmi driver registers a panic notifier as well as
> reboot and die notifiers. The callbacks registered are called in
> atomic and very limited context - for instance, panic disables
> preemption, local IRQs and all other CPUs that aren't running the
> current panic function.
>
> With that said, taking a spinlock in this scenario is a
> dangerous invitation for a deadlock scenario. So, we fix
> that in this commit by changing the regular spinlock with
> a trylock, which is a safer approach.
>
> Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
> Cc: Ard Biesheuvel 
> Cc: David Gow 
> Cc: Evan Green 
> Cc: Julius Werner 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  drivers/firmware/google/gsmi.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
> index adaa492c3d2d..b01ed02e4a87 100644
> --- a/drivers/firmware/google/gsmi.c
> +++ b/drivers/firmware/google/gsmi.c
> @@ -629,7 +629,10 @@ static int gsmi_shutdown_reason(int reason)
> if (saved_reason & (1 << reason))
> return 0;
>
> -   spin_lock_irqsave(&gsmi_dev.lock, flags);
> +   if (!spin_trylock_irqsave(&gsmi_dev.lock, flags)) {
> +   rc = -EBUSY;
> +   goto out;
> +   }

gsmi_shutdown_reason() is a common function called in other scenarios
as well, like reboot and thermal trip, where it may still make sense
to wait to acquire a spinlock. Maybe we should add a parameter to
gsmi_shutdown_reason() so that you can get your change on panic, but
we don't convert other callbacks into try-fail scenarios causing us to
miss logs.

Though thinking more about it, is this really a Good Change (TM)? The
spinlock itself already disables interrupts, meaning the only case
where this change makes a difference is if the panic happens from
within the function that grabbed the spinlock (in which case the
callback is also likely to panic), or in an NMI that panics within
that window. The downside of this change is that if one core was
politely working through an event with the lock held, and another core
panics, we now might lose the panic log, even though it probably would
have gone through fine assuming the other core has a chance to
continue.

-Evan