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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ac682fbac14a4286645810c02f60a2ba844b6c0a
baseline version:
 xen  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1

Last test of basis   185222  2024-04-03 01:53:42 Z1 days
Testing same since   185229  2024-04-03 17:11:21 Z0 days1 attempts


People who touched revisions under test:
  Federico Serafini 
  Jan Beulich 
  Marek Marczykowski-Górecki 
  Nicola Vetrini 
  Tamas K Lengyel 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6117179dd99958e4ef2687617d12c9b15bdbae24
baseline version:
 xen  ac682fbac14a4286645810c02f60a2ba844b6c0a

Last test of basis   185225  2024-04-03 08:02:08 Z0 days
Testing same since   185234  2024-04-04 00:00:24 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Jens Wiklander 
  Stefano Stabellini 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   ac682fbac1..6117179dd9  6117179dd99958e4ef2687617d12c9b15bdbae24 -> smoke

[PATCH v3] docs/misra: document the expected sizes of integer types

[Stefano Stabellini]

Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.

Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- add links to System V, AAPCS32 and AAPCS64

---
 docs/misra/C-language-toolchain.rst | 69 +
 1 file changed, 69 insertions(+)

diff --git a/docs/misra/C-language-toolchain.rst 
b/docs/misra/C-language-toolchain.rst
index b7c2000992..84b21992bc 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -480,4 +480,73 @@ The table columns are as follows:
  - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section 
"11.1 Implementation-defined behavior" of CPP_MANUAL.
 
 
+Sizes of Integer types
+__
+
+Xen expects System V ABI on x86_64:
+  https://gitlab.com/x86-psABIs/x86-64-ABI
+
+Xen expects AAPCS32 on ARMv8-A AArch32:
+  https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
+
+Xen expects AAPCS64 LP64 on ARMv8-A AArch64:
+  https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
+
+A summary table of data types, sizes and alignment is below:
+
+.. list-table::
+   :widths: 10 10 10 45
+   :header-rows: 1
+
+   * - Type
+ - Size
+ - Alignment
+ - Architectures
+
+   * - char 
+ - 8 bits
+ - 8 bits
+ - all architectures
+
+   * - short
+ - 16 bits
+ - 16 bits
+ - all architectures
+
+   * - int
+ - 32 bits
+ - 32 bits
+ - all architectures
+
+   * - long
+ - 32 bits
+ - 32 bits 
+ - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - long
+ - 64 bits
+ - 64 bits 
+ - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+   * - long long
+ - 64-bit
+ - 32-bit
+ - x86_32
+
+   * - long long
+ - 64-bit
+ - 64-bit
+ - 64-bit architectures, ARMv8-A AArch32, ARMv8-R AArch32
+
+   * - pointer
+ - 32-bit
+ - 32-bit
+ - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - pointer
+ - 64-bit
+ - 64-bit
+ - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+
 END OF DOCUMENT.
-- 
2.25.1

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux3e92c1e6cd876754b64d1998ec0a01800ed954a6
baseline version:
 linuxb1e6ec0a0fd0252af046e542f91234cd6c30b2cb

Last test of basis   185220  2024-04-02 20:12:58 Z1 days
Testing same since   185228  2024-04-03 14:39:38 Z0 days1 attempts


People who touched revisions under test:
  Christian Göttsche 
  Linus Torvalds 
  Paul Moore 

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

Re: [PATCH] docs/misra: add 13.6 to rules.rst

[Stefano Stabellini]

On Wed, 3 Apr 2024, Jan Beulich wrote:
> On 03.04.2024 01:21, Stefano Stabellini wrote:
> > As agreed during MISRA C meetings, add Rule 13.6 to rules.rst.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > There was a request to expand the scope to also include alignof and
> > typeof. Depending on whether the MISRA C scanners support it, and under
> > which rules violations will be listed, rules.rst will be updated
> > accordingly (either updating the notes section of 13.6 or adding a new
> > entry.)
> 
> Hmm. Imo ...
> 
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -445,6 +445,12 @@ maintainers if you want to suggest a change.
> >   - Initializer lists shall not contain persistent side effects
> >   -
> >  
> > +   * - `Rule 13.6 
> > `_
> > + - Required
> > + - The operand of the sizeof operator shall not contain any
> > +   expression which has potential side-effects
> > + -
> 
> ... a note to this effect should be put here right away. We _want_ to
> respect the rule for the other two similar keywords, after all. What we
> don't know at this point is whether we can get help towards this from
> Eclair.
> 
> With such a note added:
> Acked-by: Jan Beulich 

Turns out 13.6 was already in rules.rst and I didn't notice it
immediately because it was not in order. So as I commit this patch I
took the opportunity to remove the older out of order entry, and also
add the note as requested

Re: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines

[Stefano Stabellini]

On Thu, 27 Mar 2024, Julien Grall wrote:
> Hi Bertrand,
> 
> On 27/03/2024 13:40, Bertrand Marquis wrote:
> > Hi Jens,
> > 
> > > On 25 Mar 2024, at 10:39, Jens Wiklander 
> > > wrote:
> > > 
> > > Move memory sharing routines into a separate file for easier navigation
> > > in the source code.
> > > 
> > > Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
> > > ffa_domain_teardown_continue().
> > > 
> > > Signed-off-by: Jens Wiklander 
> > 
> > With the copyright date mentioned after fixed (which can be done on commit):
> > Reviewed-by: Bertrand Marquis  
> I have fixed and committed the series. However, it wasn't trivial to find the
> comment in your reply. In the future, can you try to trim your reply?

I think you forgot to push. I committed and pushed now.

[linux-6.1 test] 185227: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64   6 xen-buildfail REGR. vs. 185167

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 185167
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185167
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185167
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 185167
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 185167
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185167
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-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-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-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-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow214 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow215 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-raw  15 saverestore-support-checkfail   never pass

version targeted for testing:
 linux347385861c50adc8d4801d4b899eded38a2f04cd
baseline version:
 linuxe5cd595e23c1a075359a337c0e5c3a4f2dc28dd1

Last test of basis   185167  2024-03-26 22:43:26 Z7 days
Testing same since   185227  2024-04-03 13:42:39 Z0 days1 attempts


People who touched revisions under test:
  "Andrey Jr. Melnikov" 
  "Huang, Ying" 
  "Rafael J. Wysocki" 
  Adamos Ttofari 
  Adrian Hunter 
  Alan Stern 
  Alex Deucher 
  Alex Hung 
  Alex Williamson 
  Alexander Aring 
  Alexander Stein 
  Alexander Usyskin 
  Alexei Starovoitov 
  Amit Pundir 
  Andi Shyti 
  Andi Shyti 
  Andreas Larsson 
  Andrew Morton 
  Andrey Jr. Melnikov 
  André Rösti 
  Andy Chi 
  Anton Altaparmakov 
  Ard Biesheuvel 
  Arend van Spriel 
  Arnaud Pouliquen 
  Arnd Bergmann 
  Arseniy Krasnov 
  Aurélien Jacobs 
  Baokun Li 
  Bart Van Assche 
  Biju Das 
  Bikash Hazarika 
  Bjorn Andersson 
  Bjorn Helgaas 
  Borislav Petkov (AMD) 
  Borislav Petkov 
  Cameron Williams 
  Casey Schaufler 
  Chang S. Bae 
  Charan Teja Kalla 
  Charlie Jenkins 
  Chengming Zhou 
  Chris Wilson 
  Christian A. Ehrhardt 
  Christian Brauner 
  Christian Gmeiner 
  Christian Häggström 
  Christoph Hellwig 
  Christoph Niedermaier 
  

[PATCH AUTOSEL 6.1 11/15] x86/xen: attempt to inflate the memory balloon on PVH

[Sasha Levin]

From: Roger Pau Monne 

[ Upstream commit 38620fc4e8934f1801c7811ef39a041914ac4c1d ]

When running as PVH or HVM Linux will use holes in the memory map as scratch
space to map grants, foreign domain pages and possibly miscellaneous other
stuff.  However the usage of such memory map holes for Xen purposes can be
problematic.  The request of holesby Xen happen quite early in the kernel boot
process (grant table setup already uses scratch map space), and it's possible
that by then not all devices have reclaimed their MMIO space.  It's not
unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO
window memory, which (as expected) causes quite a lot of issues in the system.

At least for PVH dom0 we have the possibility of using regions marked as
UNUSABLE in the e820 memory map.  Either if the region is UNUSABLE in the
native memory map, or it has been converted into UNUSABLE in order to hide RAM
regions from dom0, the second stage translation page-tables can populate those
areas without issues.

PV already has this kind of logic, where the balloon driver is inflated at
boot.  Re-use the current logic in order to also inflate it when running as
PVH.  onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to
RAM, while reserving them using xen_add_extra_mem() (which is also moved so
it's no longer tied to CONFIG_PV).

[jgross: fixed build for CONFIG_PVH without CONFIG_XEN_PVH]

Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/20240220174341.56131-1-roger@citrix.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/xen/hypervisor.h |  5 ++
 arch/x86/platform/pvh/enlighten.c |  3 ++
 arch/x86/xen/enlighten.c  | 32 +
 arch/x86/xen/enlighten_pvh.c  | 68 +++
 arch/x86/xen/setup.c  | 44 -
 arch/x86/xen/xen-ops.h| 14 ++
 drivers/xen/balloon.c |  2 -
 7 files changed, 122 insertions(+), 46 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h 
b/arch/x86/include/asm/xen/hypervisor.h
index 16f548a661cf6..b3bfefdb7793a 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -59,6 +59,11 @@ void xen_arch_unregister_cpu(int num);
 #ifdef CONFIG_PVH
 void __init xen_pvh_init(struct boot_params *boot_params);
 void __init mem_map_via_hcall(struct boot_params *boot_params_p);
+#ifdef CONFIG_XEN_PVH
+void __init xen_reserve_extra_memory(struct boot_params *bootp);
+#else
+static inline void xen_reserve_extra_memory(struct boot_params *bootp) { }
+#endif
 #endif
 
 #endif /* _ASM_X86_XEN_HYPERVISOR_H */
diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index ed0442e354344..f15dc1e3ad7dd 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -74,6 +74,9 @@ static void __init init_pvh_bootparams(bool xen_guest)
} else
xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
+   if (xen_guest)
+   xen_reserve_extra_memory(_bootparams);
+
pvh_bootparams.hdr.cmd_line_ptr =
pvh_start_info.cmdline_paddr;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3c61bb98c10e2..a01ca255b0c64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -350,3 +351,34 @@ void xen_arch_unregister_cpu(int num)
 }
 EXPORT_SYMBOL(xen_arch_unregister_cpu);
 #endif
+
+/* Amount of extra memory space we add to the e820 ranges */
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
+void __init xen_add_extra_mem(unsigned long start_pfn, unsigned long n_pfns)
+{
+   unsigned int i;
+
+   /*
+* No need to check for zero size, should happen rarely and will only
+* write a new entry regarded to be unused due to zero size.
+*/
+   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+   /* Add new region. */
+   if (xen_extra_mem[i].n_pfns == 0) {
+   xen_extra_mem[i].start_pfn = start_pfn;
+   xen_extra_mem[i].n_pfns = n_pfns;
+   break;
+   }
+   /* Append to existing region. */
+   if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
+   start_pfn) {
+   xen_extra_mem[i].n_pfns += n_pfns;
+   break;
+   }
+   }
+   if (i == XEN_EXTRA_MEM_MAX_REGIONS)
+   printk(KERN_WARNING "Warning: not enough extra memory 
regions\n");
+
+   memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
+}
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index ada3868c02c23..c28f073c1df52 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ 

[PATCH AUTOSEL 6.6 13/20] x86/xen: attempt to inflate the memory balloon on PVH

[Sasha Levin]

From: Roger Pau Monne 

[ Upstream commit 38620fc4e8934f1801c7811ef39a041914ac4c1d ]

When running as PVH or HVM Linux will use holes in the memory map as scratch
space to map grants, foreign domain pages and possibly miscellaneous other
stuff.  However the usage of such memory map holes for Xen purposes can be
problematic.  The request of holesby Xen happen quite early in the kernel boot
process (grant table setup already uses scratch map space), and it's possible
that by then not all devices have reclaimed their MMIO space.  It's not
unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO
window memory, which (as expected) causes quite a lot of issues in the system.

At least for PVH dom0 we have the possibility of using regions marked as
UNUSABLE in the e820 memory map.  Either if the region is UNUSABLE in the
native memory map, or it has been converted into UNUSABLE in order to hide RAM
regions from dom0, the second stage translation page-tables can populate those
areas without issues.

PV already has this kind of logic, where the balloon driver is inflated at
boot.  Re-use the current logic in order to also inflate it when running as
PVH.  onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to
RAM, while reserving them using xen_add_extra_mem() (which is also moved so
it's no longer tied to CONFIG_PV).

[jgross: fixed build for CONFIG_PVH without CONFIG_XEN_PVH]

Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/20240220174341.56131-1-roger@citrix.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/xen/hypervisor.h |  5 ++
 arch/x86/platform/pvh/enlighten.c |  3 ++
 arch/x86/xen/enlighten.c  | 32 +
 arch/x86/xen/enlighten_pvh.c  | 68 +++
 arch/x86/xen/setup.c  | 44 -
 arch/x86/xen/xen-ops.h| 14 ++
 drivers/xen/balloon.c |  2 -
 7 files changed, 122 insertions(+), 46 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h 
b/arch/x86/include/asm/xen/hypervisor.h
index a9088250770f2..64fbd2dbc5b76 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -62,6 +62,11 @@ void xen_arch_unregister_cpu(int num);
 #ifdef CONFIG_PVH
 void __init xen_pvh_init(struct boot_params *boot_params);
 void __init mem_map_via_hcall(struct boot_params *boot_params_p);
+#ifdef CONFIG_XEN_PVH
+void __init xen_reserve_extra_memory(struct boot_params *bootp);
+#else
+static inline void xen_reserve_extra_memory(struct boot_params *bootp) { }
+#endif
 #endif
 
 /* Lazy mode for batching updates / context switch */
diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index 00a92cb2c8147..a12117f3d4de7 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -74,6 +74,9 @@ static void __init init_pvh_bootparams(bool xen_guest)
} else
xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
+   if (xen_guest)
+   xen_reserve_extra_memory(_bootparams);
+
pvh_bootparams.hdr.cmd_line_ptr =
pvh_start_info.cmdline_paddr;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3c61bb98c10e2..a01ca255b0c64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -350,3 +351,34 @@ void xen_arch_unregister_cpu(int num)
 }
 EXPORT_SYMBOL(xen_arch_unregister_cpu);
 #endif
+
+/* Amount of extra memory space we add to the e820 ranges */
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
+void __init xen_add_extra_mem(unsigned long start_pfn, unsigned long n_pfns)
+{
+   unsigned int i;
+
+   /*
+* No need to check for zero size, should happen rarely and will only
+* write a new entry regarded to be unused due to zero size.
+*/
+   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+   /* Add new region. */
+   if (xen_extra_mem[i].n_pfns == 0) {
+   xen_extra_mem[i].start_pfn = start_pfn;
+   xen_extra_mem[i].n_pfns = n_pfns;
+   break;
+   }
+   /* Append to existing region. */
+   if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
+   start_pfn) {
+   xen_extra_mem[i].n_pfns += n_pfns;
+   break;
+   }
+   }
+   if (i == XEN_EXTRA_MEM_MAX_REGIONS)
+   printk(KERN_WARNING "Warning: not enough extra memory 
regions\n");
+
+   memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
+}
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index ada3868c02c23..c28f073c1df52 100644
--- 

[PATCH AUTOSEL 6.8 18/28] x86/xen: attempt to inflate the memory balloon on PVH

[Sasha Levin]

From: Roger Pau Monne 

[ Upstream commit 38620fc4e8934f1801c7811ef39a041914ac4c1d ]

When running as PVH or HVM Linux will use holes in the memory map as scratch
space to map grants, foreign domain pages and possibly miscellaneous other
stuff.  However the usage of such memory map holes for Xen purposes can be
problematic.  The request of holesby Xen happen quite early in the kernel boot
process (grant table setup already uses scratch map space), and it's possible
that by then not all devices have reclaimed their MMIO space.  It's not
unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO
window memory, which (as expected) causes quite a lot of issues in the system.

At least for PVH dom0 we have the possibility of using regions marked as
UNUSABLE in the e820 memory map.  Either if the region is UNUSABLE in the
native memory map, or it has been converted into UNUSABLE in order to hide RAM
regions from dom0, the second stage translation page-tables can populate those
areas without issues.

PV already has this kind of logic, where the balloon driver is inflated at
boot.  Re-use the current logic in order to also inflate it when running as
PVH.  onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to
RAM, while reserving them using xen_add_extra_mem() (which is also moved so
it's no longer tied to CONFIG_PV).

[jgross: fixed build for CONFIG_PVH without CONFIG_XEN_PVH]

Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/20240220174341.56131-1-roger@citrix.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/xen/hypervisor.h |  5 ++
 arch/x86/platform/pvh/enlighten.c |  3 ++
 arch/x86/xen/enlighten.c  | 32 +
 arch/x86/xen/enlighten_pvh.c  | 68 +++
 arch/x86/xen/setup.c  | 44 -
 arch/x86/xen/xen-ops.h| 14 ++
 drivers/xen/balloon.c |  2 -
 7 files changed, 122 insertions(+), 46 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h 
b/arch/x86/include/asm/xen/hypervisor.h
index a9088250770f2..64fbd2dbc5b76 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -62,6 +62,11 @@ void xen_arch_unregister_cpu(int num);
 #ifdef CONFIG_PVH
 void __init xen_pvh_init(struct boot_params *boot_params);
 void __init mem_map_via_hcall(struct boot_params *boot_params_p);
+#ifdef CONFIG_XEN_PVH
+void __init xen_reserve_extra_memory(struct boot_params *bootp);
+#else
+static inline void xen_reserve_extra_memory(struct boot_params *bootp) { }
+#endif
 #endif
 
 /* Lazy mode for batching updates / context switch */
diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index 00a92cb2c8147..a12117f3d4de7 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -74,6 +74,9 @@ static void __init init_pvh_bootparams(bool xen_guest)
} else
xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
+   if (xen_guest)
+   xen_reserve_extra_memory(_bootparams);
+
pvh_bootparams.hdr.cmd_line_ptr =
pvh_start_info.cmdline_paddr;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3c61bb98c10e2..a01ca255b0c64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -350,3 +351,34 @@ void xen_arch_unregister_cpu(int num)
 }
 EXPORT_SYMBOL(xen_arch_unregister_cpu);
 #endif
+
+/* Amount of extra memory space we add to the e820 ranges */
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
+void __init xen_add_extra_mem(unsigned long start_pfn, unsigned long n_pfns)
+{
+   unsigned int i;
+
+   /*
+* No need to check for zero size, should happen rarely and will only
+* write a new entry regarded to be unused due to zero size.
+*/
+   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
+   /* Add new region. */
+   if (xen_extra_mem[i].n_pfns == 0) {
+   xen_extra_mem[i].start_pfn = start_pfn;
+   xen_extra_mem[i].n_pfns = n_pfns;
+   break;
+   }
+   /* Append to existing region. */
+   if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
+   start_pfn) {
+   xen_extra_mem[i].n_pfns += n_pfns;
+   break;
+   }
+   }
+   if (i == XEN_EXTRA_MEM_MAX_REGIONS)
+   printk(KERN_WARNING "Warning: not enough extra memory 
regions\n");
+
+   memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
+}
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index ada3868c02c23..c28f073c1df52 100644
--- 

Re: text-tsx fails on Intel core 8th gen system

[Andrew Cooper]

On 03/04/2024 3:50 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel
> Core i7-8750H. Specific error I get:
>
> [user@dom0 tsx]$ ./test-tsx 
> TSX tests
>   Got 16 CPUs
> Testing MSR_TSX_FORCE_ABORT consistency
>   CPU0 val 0
> Testing MSR_TSX_CTRL consistency
> Testing MSR_MCU_OPT_CTRL consistency
>   CPU0 val 0
> Testing RTM behaviour
>   Got #UD
>   Host reports RTM, but appears unavailable

Hmm - I should make this failure report more obviously distinguishable
from the general logging.

This is reporting a consistency-check failure, with a mismatch between
actual-behaviour and what's in CPUID (host policy in practice).

This is CoffeeLake, and was one of the CPUs which had TSX taken out, but
something looks wonky.


> When I try it on a newer system (11th gen) then it works fine (exit code
> 0, just "Got #UD", no "Host reports RTM, but appears unavailable" line).

RocketLake was after the decision to remove TSX from the client line, so
will either genuinely not have the silicon, or it should be properly
fused out.

Anyway, back to CoffeeLake.

The Raw policy shows rtm-always-abort and tsx-force-abort.  Test-tsx
says the value in MSR_TSX_FORCE_ABORT is 0, but that shouldn't be the
case seeing as the RTM/HLE bits are hidden in real CPUID, but the
CPUID_HIDE bit is clear.

We do intentionally force RTM_ALWAYS_ABORT in some cases, because it
self-hides in some cases.  I wonder if we've got bug in that path.

>From the state in Raw, we then synthesise HLE/RTM in the Host policy
because MSR_TSX_FORCE_ABORT only exists on TSX-capable systems. 
However, if XBEGIN is really #UD-ing, we can't offer it as an opt-in to
guests.

Let me see about putting some debugging together.

~Andrew

[xen-unstable test] 185222: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
baseline version:
 xen  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1

Last test of basis   185222  2024-04-03 01:53:42 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 

Re: text-tsx fails on Intel core 8th gen system

[Marek Marczykowski-Górecki]

On Wed, Apr 03, 2024 at 05:04:20PM +0200, Jan Beulich wrote:
> On 03.04.2024 16:50, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel
> > Core i7-8750H. Specific error I get:
> > 
> > [user@dom0 tsx]$ ./test-tsx 
> > TSX tests
> >   Got 16 CPUs
> > Testing MSR_TSX_FORCE_ABORT consistency
> >   CPU0 val 0
> > Testing MSR_TSX_CTRL consistency
> > Testing MSR_MCU_OPT_CTRL consistency
> >   CPU0 val 0
> > Testing RTM behaviour
> >   Got #UD
> >   Host reports RTM, but appears unavailable
> 
> Isn't this ...
> 
> > Testing PV default/max policies
> >   Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   HLE/RTM offered to guests despite not being available
> > Testing HVM default/max policies
> >   Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   HLE/RTM offered to guests despite not being available
> > Testing PV guest
> >   Created d8
> >   Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> > Testing HVM guest
> >   Created d9
> >   Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> >   Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> > [user@dom0 tsx]$ echo $?
> > 1
> 
> ... the reason for this?

I think so, but the question is why it behaves this way. Could be an
issue with MSR/CPUID values presented by Xen, or values Xen gets from
the CPU.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [PATCH] x86: Address MISRA Rule 13.6

[Federico Serafini]

On 02/04/24 18:09, Andrew Cooper wrote:

On 02/04/2024 5:06 pm, Jan Beulich wrote:

On 02.04.2024 17:54, Andrew Cooper wrote:

On 02/04/2024 4:46 pm, Jan Beulich wrote:

On 02.04.2024 17:43, Andrew Cooper wrote:

MISRA Rule 13.6 doesn't like having an expression in a sizeof() which
potentially has side effects.

Address several violations by pulling the expression out into a local
variable.

No functional change.

Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one caveat:


--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1150,8 +1150,9 @@ static void cf_check irq_guest_eoi_timer_fn(void *data)
  {
  struct domain *d = action->guest[i];
  unsigned int pirq = domain_irq_to_pirq(d, irq);
+struct pirq *pirq_info = pirq_info(d, pirq);

Misra won't like the var's name matching the macro's. Can we go with just
"info"?

Ah - missed that.

I can name it to just info, but I considered "struct pirq *info" to be a
little odd.

I agree, but what do you do with another "pirq" already there.

Or wait, what about

 struct pirq *pirq = pirq_info(d, domain_irq_to_pirq(d, irq));

?


That should work.  I'll switch to this locally, and wait for the
feedback on whether the patch works for 13.6.


I confirm that both versions of the patch address some violations of
13.6.

--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

Re: [PATCH v3 2/2] xen: fix stubdom PCI addr

[Anthony PERARD]

On Wed, Mar 27, 2024 at 04:05:15AM +0100, Marek Marczykowski-Górecki wrote:
> When running in a stubdomain, the config space access via sysfs needs to
> use BDF as seen inside stubdomain (connected via xen-pcifront), which is
> different from the real BDF. For other purposes (hypercall parameters
> etc), the real BDF needs to be used.
> Get the in-stubdomain BDF by looking up relevant PV PCI xenstore
> entries.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH v3 1/2] hw/xen: detect when running inside stubdomain

[Anthony PERARD]

On Wed, Mar 27, 2024 at 04:05:14AM +0100, Marek Marczykowski-Górecki wrote:
> Introduce global xen_is_stubdomain variable when qemu is running inside
> a stubdomain instead of dom0. This will be relevant for subsequent
> patches, as few things like accessing PCI config space need to be done
> differently.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Reviewed-by: Anthony PERARD 

Thanks,


-- 
Anthony PERARD

Re: [PATCH] do_multicall and MISRA Rule 8.3

[George Dunlap]

On Tue, Mar 19, 2024 at 3:39 AM Stefano Stabellini
 wrote:
> > The main use of fixed width types, to me, is in interface structure
> > definitions - between Xen and hardware / firmware, or in hypercall
> > structures. I'm afraid I have a hard time seeing good uses outside of
> > that. Even in inline assembly, types of variables used for inputs or
> > outputs don't strictly need to be fixed-width; I can somewhat accept
> > their use there for documentation purposes.
>
>
> Non-ABI interfaces are OK with native types.
>
> Our ABI interfaces are, for better or for worse, described using C
> header files. Looking at these header files, it should be clear the size
> and alignment of all integer parameters.
>
> To that end, I think we should use fixed-width types in all ABIs,
> including hypercall entry points. In my opinion, C hypercall entry
> points are part of the ABI and should match the integer types used in
> the public header files. I don't consider the little assembly code on
> hypercall entry as important.

So as Jan pointed out in the recent call, the "actual" ABI is
"register X, Y, Z are arguments 1-3".  The key thing for me then is
whether it's clear what values in register X are acceptable.  If the C
function implementing the hypercall has an argument of type "unsigned
int", is it clear what values the guest is allowed to be put into the
corresponding register, and how they'll be interpreted, as opposed to
"unsigned long"?

If we can document the expectations, for each architecture, for how
the "native types" map to sizes, then I think that should be
sufficient.

 -George

Re: text-tsx fails on Intel core 8th gen system

[Jan Beulich]

On 03.04.2024 16:50, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel
> Core i7-8750H. Specific error I get:
> 
> [user@dom0 tsx]$ ./test-tsx 
> TSX tests
>   Got 16 CPUs
> Testing MSR_TSX_FORCE_ABORT consistency
>   CPU0 val 0
> Testing MSR_TSX_CTRL consistency
> Testing MSR_MCU_OPT_CTRL consistency
>   CPU0 val 0
> Testing RTM behaviour
>   Got #UD
>   Host reports RTM, but appears unavailable

Isn't this ...

> Testing PV default/max policies
>   Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   HLE/RTM offered to guests despite not being available
> Testing HVM default/max policies
>   Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   HLE/RTM offered to guests despite not being available
> Testing PV guest
>   Created d8
>   Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> Testing HVM guest
>   Created d9
>   Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
>   Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
> [user@dom0 tsx]$ echo $?
> 1

... the reason for this?

Jan

text-tsx fails on Intel core 8th gen system

[Marek Marczykowski-Górecki]

Hi,

I've noticed that tools/tests/tsx/test-tsx fails on a system with Intel
Core i7-8750H. Specific error I get:

[user@dom0 tsx]$ ./test-tsx 
TSX tests
  Got 16 CPUs
Testing MSR_TSX_FORCE_ABORT consistency
  CPU0 val 0
Testing MSR_TSX_CTRL consistency
Testing MSR_MCU_OPT_CTRL consistency
  CPU0 val 0
Testing RTM behaviour
  Got #UD
  Host reports RTM, but appears unavailable
Testing PV default/max policies
  Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  HLE/RTM offered to guests despite not being available
Testing HVM default/max policies
  Max: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  Def: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  HLE/RTM offered to guests despite not being available
Testing PV guest
  Created d8
  Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
Testing HVM guest
  Created d9
  Cur: RTM 0, HLE 0, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
  Cur: RTM 1, HLE 1, TSX_FORCE_ABORT 0, RTM_ALWAYS_ABORT 0, TSX_CTRL 0
[user@dom0 tsx]$ echo $?
1


When I try it on a newer system (11th gen) then it works fine (exit code
0, just "Got #UD", no "Host reports RTM, but appears unavailable" line).


/proc/cpuinfo says:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 158
model name  : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
stepping: 10
microcode   : 0xf6
cpu MHz : 2207.990
cache size  : 9216 KB
physical id : 0
siblings: 6
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good 
nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 
sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 
3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp fsgsbase bmi1 avx2 bmi2 erms 
rdseed adx clflushopt xsaveopt xsavec xgetbv1 md_clear arch_capabilities
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips: 4415.98
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

...


Full `xen-cpuid detail` output attached.

Just in case, I'm attaching also full xl dmesg, but I don't see anything
related there.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
nr_features: 18

Static sets:
Known   
bfebfbff:fffef3ff:ee500800:2469bfff:000f:ffbf:3a405fdf:0780:779fd205:fc91ef1c:1c30:38000144:0001:0037::0004:1fbe:
  [00] CPUID 0x0001.edx fpu vme de pse tsc msr pae mce cx8 apic 
sysenter mtrr pge mca cmov pat pse36 clflush ds acpi mmx fxsr sse sse2 ss htt 
tm pbe
  [01] CPUID 0x0001.ecx sse3 pclmulqdq dtes64 monitor ds-cpl vmx smx 
est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse41 sse42 x2apic movebe popcnt 
tsc-dl aesni xsave osxsave avx f16c rdrnd hyper
  [02] CPUID 0x8001.edx syscall nx mmx+ fxsr+ pg1g rdtscp lm 3dnow+ 
3dnow
  [03] CPUID 0x8001.ecx lahf-lm cmp svm extapic cr8d lzcnt sse4a msse 
3dnowpf osvw ibs xop skinit wdt lwp fma4 nodeid tbm topoext dbx monitorx
  [04] CPUID 0x000d:1.eax   xsaveopt xsavec xgetbv1 xsaves
  [05] CPUID 0x0007:0.ebx   fsgsbase tsc-adj sgx bmi1 hle avx2 fdp-exn smep 
bmi2 erms invpcid rtm pqm depfpp mpx pqe avx512f avx512dq rdseed adx smap 
avx512-ifma clflushopt clwb proc-trace avx512pf avx512er avx512cd sha avx512bw 
avx512vl
  [06] CPUID 0x0007:0.ecx   prefetchwt1 avx512-vbmi umip pku ospke 
avx512-vbmi2 cet-ss gfni vaes vpclmulqdq avx512-vnni avx512-bitalg 
avx512-vpopcntdq rdpid cldemote movdiri movdir64b enqcmd
  [07] CPUID 0x8007.edx hw-pstate itsc cpb efro
  [08] CPUID 0x8008.ebx clzero rstr-fp-err-ptrs wbnoinvd ibpb ibrs 
amd-stibp ibrs-always stibp-always ibrs-fast ibrs-same-mode no-lmsl ppin 
amd-ssbd virt-ssbd ssb-no psfd btc-no ibpb-ret
  [09] CPUID 0x0007:0.edx   avx512-4vnniw avx512-4fmaps fsrm 
avx512-vp2intersect srbds-ctrl md-clear rtm-always-abort tsx-force-abort 
serialize hybrid tsxldtrk cet-ibt avx512-fp16 ibrsb stibp l1d-flush arch-caps 
core-caps ssbd
  [10] CPUID 0x0007:1.eax   avx-vnni avx512-bf16 fzrm fsrs fsrcs
  [11] CPUID 0x8021.eax lfence+ nscb auto-ibrs sbpb ibpb-brtype srso-no
  [12] CPUID 0x0007:1.ebx   ppin
  [13] CPUID 

Re: [RFC XEN PATCH v6 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

[Anthony PERARD]

On Thu, Mar 28, 2024 at 02:34:02PM +0800, Jiqian Chen wrote:
> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> index 2cec83e0b734..debf6ec6ddc7 100644
> @@ -1500,13 +1510,25 @@ static void pci_add_dm_done(libxl__egc *egc,
>  rc = ERROR_FAIL;
>  goto out;
>  }
> -r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
> -if (r < 0) {
> -LOGED(ERROR, domainid,
> -  "xc_domain_irq_permission irq=%d (error=%d)", irq, r);
> -fclose(f);
> -rc = ERROR_FAIL;
> -goto out;
> +if (is_gsi) {
> +r = xc_domain_gsi_permission(ctx->xch, domid, gsi, 1);
> +if (r < 0 && r != -EOPNOTSUPP) {

Is it correct to check `r` for "-EOPNOTSUPP" ? Because `man ioctl` and
"xenctrl.h:105" says that `r` is 0 on success or -1 on error with `errno`
set.

> +LOGED(ERROR, domainid,
> +  "xc_domain_gsi_permission gsi=%d (error=%d)", gsi, r);

Is the `r` value useful to print? Because LOGED() already prints
strerror(errno).

> +fclose(f);
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +}
> +if (!is_gsi || r == -EOPNOTSUPP) {
> +r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
> +if (r < 0) {
> +LOGED(ERROR, domainid,
> +"xc_domain_irq_permission irq=%d (error=%d)", irq, r);
> +fclose(f);
> +rc = ERROR_FAIL;
> +goto out;
> +}
>  }
>  }
>  fclose(f);
> @@ -2180,6 +2202,7 @@ static void pci_remove_detached(libxl__egc *egc,
>  FILE *f;
>  uint32_t domainid = prs->domid;
>  bool isstubdom;
> +bool is_gsi = true;
>  
>  /* Convenience aliases */
>  libxl_device_pci *const pci = >pci;
> @@ -2243,6 +2266,7 @@ skip_bar:
>  /* To compitable with old version of kernel, still need to use irq */
>  sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/irq", pci->domain,
> pci->bus, pci->dev, pci->func);
> +is_gsi = false;
>  }
>  f = fopen(sysfs_path, "r");
>  if (f == NULL) {
> @@ -2261,9 +2285,17 @@ skip_bar:
>   */
>  LOGED(ERROR, domid, "xc_physdev_unmap_pirq irq=%d", irq);
>  }
> -rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);
> -if (rc < 0) {
> -LOGED(ERROR, domid, "xc_domain_irq_permission irq=%d", irq);
> +if (is_gsi) {
> +rc = xc_domain_gsi_permission(ctx->xch, domid, irq, 0);

Could you store the return code of this system call into `r` instead?
`rc` is supposed to be use exclusively for libxl error code, so the
current code is wrong, but we can partially fixed that in your patch.

> +if (rc < 0 && rc != -EOPNOTSUPP) {

Shouldn't you check EOPNOTSUPP in `errno` instead?

> +LOGED(ERROR, domid, "xc_domain_gsi_permission gsi=%d", irq);
> +}
> +}
> +if (!is_gsi || rc == -EOPNOTSUPP) {
> +rc = xc_domain_irq_permission(ctx->xch, domid, irq, 0);

Same here, use `r` instead of `rc`.

> +if (rc < 0) {
> +LOGED(ERROR, domid, "xc_domain_irq_permission irq=%d", irq);
> +}
>  }
>  }
>  

Thanks,

-- 
Anthony PERARD

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-raw  10 host-ping-check-xen fail pass in 185226-retest

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

version targeted for testing:
 linuxb1e6ec0a0fd0252af046e542f91234cd6c30b2cb
baseline version:
 linux026e680b0a08a62b1d948e5a8ca78700bfac0e6e

Last test of basis   185214  2024-04-01 22:11:44 Z1 days
Testing same since   185220  2024-04-02 20:12:58 Z0 days1 attempts


People who touched revisions under test:
  Brendan Jackman 
  Daniel Bristot de Oliveira 
  Donald Hunter 
  Hongbo Li 
  Jonathan Corbet 
  Kent Overstreet 
  Linus Torvalds 
  Randy Dunlap 
  Thomas Bertschinger 
  Vitaly Chikunov 
  Weiji Wang 
  zhuxiaohui 
  zhuxiaohui 

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

Re: preparations for 4.17.4

[Jan Beulich]

On 03.04.2024 16:08, Andrew Cooper wrote:
> On 02/04/2024 3:26 pm, Jan Beulich wrote:
>> On 27.03.2024 13:33, Andrew Cooper wrote:
>>> 5) Ucode scan stability  (For 4.18 only)
>>>
>>> Xen 4.18 had "x86/ucode: Refresh raw CPU policy after microcode load" in
>>> it's .0 release, so should also gain:
>>>
>>> cf7fe8b72dea - x86/ucode: Fix stability of the raw CPU Policy rescan
>> This already is in 4.18.1, ...
>>
>>> I've only noticed because I've got them both backported to 4.17 in
>>> XenServer, but I don't think upstream wants to take that route.
>> ... while, as you suggest, not (and not intended to be) in 4.17.
> 
> Oh, so it is.  Although comparing my backport to what you put into 4.18,
> you also want
> 
> 930605f155cc - x86/ucode: Remove accidentally introduced tabs
> 
> which I apparently folded into my 4.17 backport.  I have a feeling I
> noticed at the point of doing the backport.

Well, no, if need be that can be folded into a future backport touching
that area again.

Jan

Re: [PATCH] xen/include: move definition of ASM_INT() to xen/linkage.h

[Jan Beulich]

On 03.04.2024 15:59, Andrew Cooper wrote:
> On 03/04/2024 1:51 pm, Jan Beulich wrote:
>> On 03.04.2024 14:03, Juergen Gross wrote:
>>> ASM_INT() is defined in arch/[arm|x86]/include/asm/asm_defns.h in
>>> exactly the same way. Instead of replicating this definition for riscv
>>> and ppc, move it to include/xen/linkage.h, where other arch agnostic
>>> definitions for assembler code are living already.
>> And this is why I didn't make a change right away, back when noticing the
>> duplication: Arch-agnostic really means ...
>>
>>> --- a/xen/include/xen/linkage.h
>>> +++ b/xen/include/xen/linkage.h
>>> @@ -60,6 +60,8 @@
>>>  #define DATA_LOCAL(name, align...) \
>>>  SYM(name, DATA, LOCAL, LASTARG(DATA_ALIGN, ## align), DATA_FILL)
>>>  
>>> +#define ASM_INT(label, val)DATA(label, 4) .long (val); END(label)
>> ... to avoid .long [1]. There's no arch-independent aspect guaranteeing
>> that what .long emits matches "unsigned int" as used e.g. in the
>> declaration of xen_config_data_size.
> 
> I'd forgotten that point, but I don't think it's a good reason force
> every architecture to implement the same thing.

Of course.

> Borrowing a trick from the alternatives, what about this as a sanity check?
> 
> diff --git a/xen/tools/binfile b/xen/tools/binfile
> index 0299326ccc3f..21593debc872 100755
> --- a/xen/tools/binfile
> +++ b/xen/tools/binfile
> @@ -35,4 +35,10 @@ DATA($varname, 1 << $align)
>  END($varname)
>  
>  ASM_INT(${varname}_size, .Lend - $varname)
> +.Lsize_end:
> +
> +    .section .discard
> +    # Build assert sizeof(ASM_INT) == 4
> +    .byte 0xff - ((.Lsize_end - ${varname}_size) == 4)
> +
>  EOF

Hmm, tools/binfile may not be involved in a build, yet ASM_INT() may
still be used. Since there may not be any good place, I think we're
okay-ish for now without such a check.

> Ideally we'd want BYTES_PER_INT here but it turns out that doesn't exist
> in Xen.  If we find an architecture where .long isn't the right thing,
> we can make ASM_INT optionally arch-specific.

We don't even need to go this far - merely introducing an abstraction
for .long would suffice, and then also allow using that in bug.h.

Jan

Re: preparations for 4.17.4

[Andrew Cooper]

On 02/04/2024 3:26 pm, Jan Beulich wrote:
> On 27.03.2024 13:33, Andrew Cooper wrote:
>> 1) livepatching of .rodata:
>>
>> 989556c6f8ca - xen/virtual-region: Rename the start/end fields
>> ef969144a425 - xen/virtual-region: Include rodata pointers
>> b083b1c393dc - x86/livepatch: Relax permissions on rodata too
>>
>> And technically "x86/mm: fix detection of last L1 entry in
>> modify_xen_mappings_lite()" too but you've already backported this one.
>>
>> Patching .rodata worked before Xen 4.17, and was broken (left as a TODO)
>> when I adjusted Xen to stop using CR0.WP=0 for patching.
>>
>>
>> 2) Policy fixes:
>>
>> e2d8a6522516 - x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max
>> policies
>>
>> This is a real bugfix for a real regression we found updating from Xen
>> 4.13 -> 4.17.  It has a dependency on
>>
>> 5420aa165dfa - x86/cpu-policy: Hide x2APIC from PV guests
>>
>> which I know you had more concern with.  FWIW, I'm certain its a good
>> fix, and should be backported.
>>
>>
>> 3) Test fixes:
>>
>> 0263dc9069dd - tests/resource: Fix HVM guest in !SHADOW builds
>>
>> It's minor, but does make a difference for those of us who run these
>> tests regularly.
>>
>>
>> 4) Watchdog fixes:
>>
>> 9e18f339830c - x86/boot: Improve the boot watchdog determination of
>> stuck cpus
>> 131892e0dcc1 - x86/boot: Support the watchdog on newer AMD systems
>>
>> You took "x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly"
>> and the first of the two patches is in the same category IMO.  The
>> second I also feel ok to take for the in-support releases, particularly
>> as all it is doing is dropping a family list.
> I've pushed all of the above.

Thanks.

>
>> 5) Ucode scan stability  (For 4.18 only)
>>
>> Xen 4.18 had "x86/ucode: Refresh raw CPU policy after microcode load" in
>> it's .0 release, so should also gain:
>>
>> cf7fe8b72dea - x86/ucode: Fix stability of the raw CPU Policy rescan
> This already is in 4.18.1, ...
>
>> I've only noticed because I've got them both backported to 4.17 in
>> XenServer, but I don't think upstream wants to take that route.
> ... while, as you suggest, not (and not intended to be) in 4.17.

Oh, so it is.  Although comparing my backport to what you put into 4.18,
you also want

930605f155cc - x86/ucode: Remove accidentally introduced tabs

which I apparently folded into my 4.17 backport.  I have a feeling I
noticed at the point of doing the backport.

~Andrew

Re: [PATCH] xen/include: move definition of ASM_INT() to xen/linkage.h

[Andrew Cooper]

On 03/04/2024 1:51 pm, Jan Beulich wrote:
> On 03.04.2024 14:03, Juergen Gross wrote:
>> ASM_INT() is defined in arch/[arm|x86]/include/asm/asm_defns.h in
>> exactly the same way. Instead of replicating this definition for riscv
>> and ppc, move it to include/xen/linkage.h, where other arch agnostic
>> definitions for assembler code are living already.
> And this is why I didn't make a change right away, back when noticing the
> duplication: Arch-agnostic really means ...
>
>> --- a/xen/include/xen/linkage.h
>> +++ b/xen/include/xen/linkage.h
>> @@ -60,6 +60,8 @@
>>  #define DATA_LOCAL(name, align...) \
>>  SYM(name, DATA, LOCAL, LASTARG(DATA_ALIGN, ## align), DATA_FILL)
>>  
>> +#define ASM_INT(label, val)DATA(label, 4) .long (val); END(label)
> ... to avoid .long [1]. There's no arch-independent aspect guaranteeing
> that what .long emits matches "unsigned int" as used e.g. in the
> declaration of xen_config_data_size.

I'd forgotten that point, but I don't think it's a good reason force
every architecture to implement the same thing.

Borrowing a trick from the alternatives, what about this as a sanity check?

diff --git a/xen/tools/binfile b/xen/tools/binfile
index 0299326ccc3f..21593debc872 100755
--- a/xen/tools/binfile
+++ b/xen/tools/binfile
@@ -35,4 +35,10 @@ DATA($varname, 1 << $align)
 END($varname)
 
 ASM_INT(${varname}_size, .Lend - $varname)
+.Lsize_end:
+
+    .section .discard
+    # Build assert sizeof(ASM_INT) == 4
+    .byte 0xff - ((.Lsize_end - ${varname}_size) == 4)
+
 EOF


Ideally we'd want BYTES_PER_INT here but it turns out that doesn't exist
in Xen.  If we find an architecture where .long isn't the right thing,
we can make ASM_INT optionally arch-specific.

~Andrew

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Daniel P. Smith]

On 4/2/24 13:06, Andrew Cooper wrote:

The commit makes a claim without any kind of justification.

The claim is false, and the commit broke lsevtchn in dom0.  It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.

Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.

This reverts commit f60ab5337f968e2f10c639ab59db7afb0fe4f7c3.

Fixes: f60ab5337f96 ("evtchn: refuse EVTCHNOP_status for Xen-bound event 
channels")
Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Daniel Smith 
---
  xen/common/event_channel.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 20f586cf5ecd..ae6c2f902645 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1040,12 +1040,6 @@ int evtchn_status(evtchn_status_t *status)
  
  read_lock(>event_lock);
  
-if ( consumer_is_xen(chn) )

-{
-rc = -EACCES;
-goto out;
-}
-
  rc = xsm_evtchn_status(XSM_TARGET, d, chn);
  if ( rc )
  goto out;

base-commit: 7a09966e7b2823b70f6d56d0cf66c11124f4a3c1


Acked-by: Daniel P. Smith 

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Daniel P. Smith]

On 4/3/24 07:54, Jan Beulich wrote:

On 03.04.2024 13:50, Daniel P. Smith wrote:

On 4/3/24 02:52, Jan Beulich wrote:

On 03.04.2024 08:16, Jan Beulich wrote:

On 02.04.2024 19:06, Andrew Cooper wrote:

Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.


I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.


Further to this: Is there even a way to express the same denial in XSM?
alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
channel, and (yes, it could in principle be open-coded in Flask code)
consumer_is_xen() is private to event_channel.c. I also dare to question
whether in SILO mode status information like this should be available.


To build on the previous response: if the natural failure return value
is -EACCESS in response to a domain resource access attempt, then the
probability is extremely high that it should be implemented under a XSM
hook and not hard-coded into the resource logic.


Possibly. But first of all - could you answer the earlier question I raised?


Don't need to, this change subverts/violates the access control 
framework. If the desire is to make this access decision for the 
default/dummy policy, then codify it there. Otherwise I will be ack'ing 
this change since it is access control and falls under the purview of XSM.


v/r,
dps

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Daniel P. Smith]

On 4/3/24 08:05, Jan Beulich wrote:

On 03.04.2024 13:10, Daniel P. Smith wrote:

On 4/3/24 02:16, Jan Beulich wrote:

On 02.04.2024 19:06, Andrew Cooper wrote:

The commit makes a claim without any kind of justification.


Well, what does "have no business" leave open?


Why does it not have any business? Why should a domain that creates an
event channel not be able to inquire about its status?


Event channels we talk about here are created via
alloc_unbound_xen_event_channel(). IOW it's not any domain creating them.
Once connected, the respective domain is of course fine to query its end
of the channel.



I would disagree, for instance alloc_unbound_xen_event_channel() is used 
in response to XEN_DOMCTL_vuart_op:XEN_DOMCTL_VUART_OP_INIT and 
XEN_DOMCTL_VM_EVENT_OP_PAGING:XEN_VM_EVENT_ENABLE, which are hypercalls 
by a domain and not something initiated by the hypervisor.



The claim is false, and the commit broke lsevtchn in dom0.


Or alternatively lsevtchn was doing something that was never meant to work
(from Xen's perspective).


Again, you have not said why this is a problem. What concern does it
create? Does it open the door for access elevation, resource
deprivation, or some other malicious behaviors?


It exposes information that perhaps better wouldn't be exposed. Imo if
Xen owned resource state is of interest, it would want exposing via
hypfs.


You didn't answer why, just again expressed your opinion that it is not 
better exposed. And I would have to wholly disagree with the sentiment 
that hypfs exposure is the deciding factor what is or is not worth 
exposing. This thinking is completely orthogonal to FLASK and 
fine-grained access control.



   It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.


Why would that be "obvious"? What business would a stubdom have to look at
Xen's side of an evtchn?


Again, you have not expressed why it shouldn't be able to do so.


See above - not its resource, nor its guest's.


It is a resource provided to a domain that the domain can send/raise an 
event to and a backing domain that can bind to it, ie. the two 
parameters that must be passed to the allocation call.



Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.


I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.


In fact, this commit is in violation of the XSM. It hard-codes a
resource access check outside XSM, thus breaking the fine-grained access
control of FLASK.


Perhaps; see below and see the question raised in the subsequent reply
to the patch.


In summary: The supposed justification you claim is missing in the original
change is imo also missing here then: What business would any entity in the
system have to look at Xen's side of an event channel? Back at the time, 3
people agreed that it's "none".


As stated, you provided no reason or justification for "has no business"
and by face value is an opinion that a few people agreed with. As for
why, there could be a myriad number of reasons a domain may want to
check the status of an interface it has with the hypervisor. From just
logging its state for debug to throttling attempts at sending an event.
So why, from a security/access control decision, does this access have
to absolutely blocked, even from FLASK?


I didn't say it absolutely needs to be blocked. I'm okay to become
convinced otherwise. But in the description complaining about lack of
reasons in the 3-4 year old change, just to then again not provide any
reasons looks "interesting" to me. (And no, just to take that example,
lsevtchn not working anymore on such channels is not on its own a
reason. As indicated, it may well be that conceptually it was never
supposed to be able to have access to this information. The latest not
anymore when hypfs was introduced.)


This broke an existing behavior, whether that behavior is correct can 
always be questioned, does not justify leaving an incorrect 
implementation. And it is incorrect because as again you have not 
articulated why the lsevtchn behavior is wrong and thus whether this is 
the valid corrective action.


v/r,
dps

Re: [PATCH v6 2/4] tools: Move MB/GB() to common-macros.h

[Anthony PERARD]

On Wed, Mar 27, 2024 at 05:51:00PM -0400, Jason Andryuk wrote:
> Consolidate to a single set of common macros for tools.
> 
> MB() will gain another use in libelf, so this movement makes it
> available.
> 
> Requested-by: Jan Beulich 
> Signed-off-by: Jason Andryuk 
> Reviewed-by: Jan Beulich 
> ---

So, this patch fixes potential use issues with the macros in hvmloader
and init-xenstore-domain. While it's not perfect, it still better.

I'll try "MB(memory + 0)" with the different macros:


> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 87be213dec..14078bde1e 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -38,9 +38,6 @@ void __bug(const char *file, int line) 
> __attribute__((noreturn));
>  #define BUG() __bug(__FILE__, __LINE__)
>  #define BUG_ON(p) do { if (p) BUG(); } while (0)
>  
> -#define MB(mb) (mb##ULL << 20)
> -#define GB(gb) (gb##ULL << 30)

With this change we have this change for MB(memory + 0) when applied:
-  (memory + 0ULL << 20)
+  ((memory + 0ULL) << 20)

>  static inline int test_bit(unsigned int b, const void *p)
>  {
>  return !!(((const uint8_t *)p)[b>>3] & (1u<<(b&7)));
> diff --git a/tools/helpers/init-xenstore-domain.c 
> b/tools/helpers/init-xenstore-domain.c
> index 5405842dfe..f38ba8d6b5 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -20,7 +20,6 @@
>  #include "init-dom-json.h"
>  
>  #define LAPIC_BASE_ADDRESS  0xfee0UL
> -#define GB(x)   ((uint64_t)x << 30)

With this change we have this change for GB(memory + 0) when applied:
-  ((uint64_t)memory + 0 << 30)
+  ((memory + 0ULL) << 30)


So overall, patch makes things better and less duplication:
Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH v6 1/4] tools/init-xenstore-domain: Replace variable MB() usage

[Jason Andryuk]

On 2024-04-03 08:41, Anthony PERARD wrote:

On Wed, Mar 27, 2024 at 05:50:59PM -0400, Jason Andryuk wrote:

The local MB() & GB() macros will be replaced with a common
implementation, but those only work with constant values.  Introduce a


By the way, this is not true, the macro introduce in the following patch
("tools: Move MB/GB() to common-macros.h") works (compiler doesn't
complain) if you do something like MB(maxmem+0) ;-).


Well, I think I wrote the wrong word for the description.  The old Macro 
might have been okay, but the new one as (_AC(_mb, ULL) << 20) fails for 
MB(memory):


init-xenstore-domain.c: In function ‘build’:
init-xenstore-domain.c:82:28: error: ‘memoryULL’ undeclared (first use 
in this function); did you mean ‘memory’?

   82 | uint64_t mem_size = MB(memory);
  |^~

I should have written "only work for numeric values."


static inline mb_to_bytes() in place of the MB() macro to convert the
variable values.

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 1683438c5c..5405842dfe 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -20,7 +20,6 @@
  #include "init-dom-json.h"
  
  #define LAPIC_BASE_ADDRESS  0xfee0UL

-#define MB(x)   ((uint64_t)x << 20)
  #define GB(x)   ((uint64_t)x << 30)
  
  static uint32_t domid = ~0;

@@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
  static xentoollog_level minmsglevel = XTL_PROGRESS;
  static void *logger;
  
+static inline uint64_t mb_to_bytes(int mem)

+{
+   return (uint64_t)mem << 20;
+}
+
  static struct option options[] = {
  { "kernel", 1, NULL, 'k' },
  { "memory", 1, NULL, 'm' },
@@ -76,8 +80,8 @@ static int build(xc_interface *xch)
  int rv, xs_fd;
  struct xc_dom_image *dom = NULL;
  int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
-uint64_t mem_size = MB(memory);
-uint64_t max_size = MB(maxmem ? : memory);
+uint64_t mem_size = mb_to_bytes(memory);
+uint64_t max_size = mb_to_bytes(maxmem ? : memory);
  struct e820entry e820[3];
  struct xen_domctl_createdomain config = {
  .ssidref = SECINITSID_DOMU,
  
Sorry, just notice they were more versions of the series, so repeating

here:

Looks like this change actually fix a bug. When `maxmem` is set, we
would have "max_size = maxmem", otherwise, it would be
"max_size = memory << 20"

The macro should have been written as
  #define MB(x)   ((uint64_t)(x) << 20)

This patch could be backported to 4.17 and later, with:
 Fixes: 134d53f57707 ("tools/init-xenstore-domain: fix memory map for PVH 
stubdom")


Nice catch!


Anyway, this patch on it's own looks fine:
Reviewed-by: Anthony PERARD 


Thank you.

Regards,
Jason

Re: [PATCH] xen/include: move definition of ASM_INT() to xen/linkage.h

[Jan Beulich]

On 03.04.2024 14:03, Juergen Gross wrote:
> ASM_INT() is defined in arch/[arm|x86]/include/asm/asm_defns.h in
> exactly the same way. Instead of replicating this definition for riscv
> and ppc, move it to include/xen/linkage.h, where other arch agnostic
> definitions for assembler code are living already.

And this is why I didn't make a change right away, back when noticing the
duplication: Arch-agnostic really means ...

> --- a/xen/include/xen/linkage.h
> +++ b/xen/include/xen/linkage.h
> @@ -60,6 +60,8 @@
>  #define DATA_LOCAL(name, align...) \
>  SYM(name, DATA, LOCAL, LASTARG(DATA_ALIGN, ## align), DATA_FILL)
>  
> +#define ASM_INT(label, val)DATA(label, 4) .long (val); END(label)

... to avoid .long [1]. There's no arch-independent aspect guaranteeing
that what .long emits matches "unsigned int" as used e.g. in the
declaration of xen_config_data_size. The arch-agnostic directives are
.dc.l and friends. Sadly Clang looks to support this only starting with
version 4.

Nevertheless, seeing that Andrew ack-ed the change already, it's perhaps
good enough for the moment. If an obscure port appeared, the further
abstraction could be taken care of by them.

Jan

[1] Note how in gas doc .long refers to .int, .int says "32-bit", just
to then have a special case of H8/300 emitting 16-bit values. Things
must have been confusing enough for someone to come and add .dc.?.

Re: [PATCH v6 1/4] tools/init-xenstore-domain: Replace variable MB() usage

[Anthony PERARD]

On Wed, Mar 27, 2024 at 05:50:59PM -0400, Jason Andryuk wrote:
> The local MB() & GB() macros will be replaced with a common
> implementation, but those only work with constant values.  Introduce a

By the way, this is not true, the macro introduce in the following patch
("tools: Move MB/GB() to common-macros.h") works (compiler doesn't
complain) if you do something like MB(maxmem+0) ;-).

> static inline mb_to_bytes() in place of the MB() macro to convert the
> variable values.
> 
> diff --git a/tools/helpers/init-xenstore-domain.c 
> b/tools/helpers/init-xenstore-domain.c
> index 1683438c5c..5405842dfe 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -20,7 +20,6 @@
>  #include "init-dom-json.h"
>  
>  #define LAPIC_BASE_ADDRESS  0xfee0UL
> -#define MB(x)   ((uint64_t)x << 20)
>  #define GB(x)   ((uint64_t)x << 30)
>  
>  static uint32_t domid = ~0;
> @@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
>  static xentoollog_level minmsglevel = XTL_PROGRESS;
>  static void *logger;
>  
> +static inline uint64_t mb_to_bytes(int mem)
> +{
> + return (uint64_t)mem << 20;
> +}
> +
>  static struct option options[] = {
>  { "kernel", 1, NULL, 'k' },
>  { "memory", 1, NULL, 'm' },
> @@ -76,8 +80,8 @@ static int build(xc_interface *xch)
>  int rv, xs_fd;
>  struct xc_dom_image *dom = NULL;
>  int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
> -uint64_t mem_size = MB(memory);
> -uint64_t max_size = MB(maxmem ? : memory);
> +uint64_t mem_size = mb_to_bytes(memory);
> +uint64_t max_size = mb_to_bytes(maxmem ? : memory);
>  struct e820entry e820[3];
>  struct xen_domctl_createdomain config = {
>  .ssidref = SECINITSID_DOMU,
 
Sorry, just notice they were more versions of the series, so repeating
here:

Looks like this change actually fix a bug. When `maxmem` is set, we
would have "max_size = maxmem", otherwise, it would be
"max_size = memory << 20"

The macro should have been written as
 #define MB(x)   ((uint64_t)(x) << 20)

This patch could be backported to 4.17 and later, with:
Fixes: 134d53f57707 ("tools/init-xenstore-domain: fix memory map for PVH 
stubdom")

Anyway, this patch on it's own looks fine:
Reviewed-by: Anthony PERARD 



-- 
Anthony PERARD

Re: [PATCH v4 2/5] tools/init-xenstore-domain: Replace variable MB() usage

[Anthony PERARD]

On Mon, Mar 25, 2024 at 04:45:12PM -0400, Jason Andryuk wrote:
> The local MB() & GB() macros will be replaced with a common
> implementation, but those only work with constant values.  Introduce a
> static inline mb_to_bytes() in place of the MB() macro to convert the
> variable values.
> 
> Signed-off-by: Jason Andryuk 
> ---
> v4:
> New
> ---
>  tools/helpers/init-xenstore-domain.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/helpers/init-xenstore-domain.c 
> b/tools/helpers/init-xenstore-domain.c
> index 1683438c5c..5405842dfe 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -20,7 +20,6 @@
>  #include "init-dom-json.h"
>  
>  #define LAPIC_BASE_ADDRESS  0xfee0UL
> -#define MB(x)   ((uint64_t)x << 20)
>  #define GB(x)   ((uint64_t)x << 30)
>  
>  static uint32_t domid = ~0;
> @@ -36,6 +35,11 @@ static xc_evtchn_port_or_error_t console_evtchn;
>  static xentoollog_level minmsglevel = XTL_PROGRESS;
>  static void *logger;
>  
> +static inline uint64_t mb_to_bytes(int mem)
> +{
> + return (uint64_t)mem << 20;
> +}
> +
>  static struct option options[] = {
>  { "kernel", 1, NULL, 'k' },
>  { "memory", 1, NULL, 'm' },
> @@ -76,8 +80,8 @@ static int build(xc_interface *xch)
>  int rv, xs_fd;
>  struct xc_dom_image *dom = NULL;
>  int limit_kb = (maxmem ? : memory) * 1024 + X86_HVM_NR_SPECIAL_PAGES * 4;
> -uint64_t mem_size = MB(memory);
> -uint64_t max_size = MB(maxmem ? : memory);
> +uint64_t mem_size = mb_to_bytes(memory);
> +uint64_t max_size = mb_to_bytes(maxmem ? : memory);

Looks like this change actually fix a bug. When `maxmem` is set, we
would have "max_size = maxmem", otherwise, it would be 
"max_size = memory << 20"

The macro should have been written as
 #define MB(x)   ((uint64_t)(x) << 20)

This patch could be backported to 4.17 and later, with:
Fixes: 134d53f57707 ("tools/init-xenstore-domain: fix memory map for PVH 
stubdom")

Anyway, this patch on it's own looks fine:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH] xen/include: move definition of ASM_INT() to xen/linkage.h

[Andrew Cooper]

On 03/04/2024 1:03 pm, Juergen Gross wrote:
> ASM_INT() is defined in arch/[arm|x86]/include/asm/asm_defns.h in
> exactly the same way. Instead of replicating this definition for riscv
> and ppc, move it to include/xen/linkage.h, where other arch agnostic
> definitions for assembler code are living already.
>
> Adapt the generation of assembler sources via tools/binfile to include
> the new home of ASM_INT().
>
> Signed-off-by: Juergen Gross 

Acked-by: Andrew Cooper 

Xen 4.19 release status tracking list [ April ]

[Oleksii]

Hello everyone,

I would like to share with you a list for status tracking based on Xen
ML and community members comments:

*** Arm ***:
  * [PATCH v7 00/14] Arm cache coloring [
https://patchew.org/Xen/20240315105902.160047-1-carlo.non...@minervasys.tech/
]:
- new patch series version [v7] was sent

  * [PATCH v13 00/14] PCI devices passthrough on Arm, part 3 [
https://lore.kernel.org/xen-devel/20240202213321.1920347-1-stewart.hildebr...@amd.com/
]
  
  * [PATCH v3 0/4] DOMCTL-based guest magic region allocation for 11
domUs [
https://patchew.org/Xen/20240403081626.375313-1-xin.wa...@amd.com/ ]
  
  * [XEN v6 0/3] xen/arm: Add emulation of Debug Data Transfer
Registers [
https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.hal...@amd.com/
]


*** PPC ***:
  * [PATCH v3 0/9] Early Boot Allocation on Power [
https://patchew.org/Xen/cover.1710443965.git.sanasta...@raptorengineering.com/
]:
new patch series version [v3] was sent

*** RISC-V ***:
  * [PATCH v4 05/23]  Enable build of full Xen for RISC-V [
https://lore.kernel.org/xen-devel/cover.1708962629.git.oleksii.kuroc...@gmail.com/
]:
- one patch of the patch series was merged
- new patch series version [v7] were sent


*** x86 ***:
  * [PATCH 0/4] iommu/x86: fixes/improvements for unity range checks [
https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger@citrix.com/
]: 
- almost patch series have been merged already except the patch:
[PATCH 4/4] iommu/x86: make unity range checking more strict

  * [PATCH 0/8] x86: support AVX10.1 [
https://lore.kernel.org/xen-devel/298db76f-d0ee-4d47-931f-1baa1a754...@suse.com/
]
  
  * APX support?

  * [PATCH v4 0/8] x86emul: misc additions [
https://lore.kernel.org/xen-devel/9dd23064-c79e-4a50-9c71-c0e73b189...@suse.com/
]

  * [PATCH 0/7] VT-d: SATC handling and ATS tidying [
https://lore.kernel.org/xen-devel/25506838-b818-4686-8c16-3a198338a...@suse.com/
]

  * [XEN PATCH 0/9] x86: parallelize AP bring-up during boot [
https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.he...@3mdeb.com/
]

  * [PATCH v2 00/12] x86: memcpy() / memset() (non-)ERMS flavors plus
fallout [
https://lore.kernel.org/xen-devel/8f56a8f4-0482-932f-96a9-c791bebb4...@suse.com/
]
- 6/12 are merged.
  
  * [PATCH v6 0/4] x86/pvh: Support relocating dom0 kernel [
https://patchew.org/Xen/20240327215102.136001-1-jason.andr...@amd.com/
]
  
  * x86/spec-ctrl: IBPB improvements [
https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a7...@suse.com/
]


*** common ***:
  * annotate entry points with type and size" series:
The bulk of this has gone in, but there'll want to be follow-ups.

  * [PATCH v2 (resend) 00/27] Remove the directmap [
https://lore.kernel.org/xen-devel/20240116192611.41112-1-elias...@amazon.com/
]
- 7/27 were merged.
 
  * [PATCH] move __read_mostly to xen/cache.h [
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
]

  * [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [
https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.1706259490.git.federico.seraf...@bugseng.com/
]

  * MISRA rules updates:
   - [PATCH v2] docs/misra/rules.rst update [
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2402131431070.1925432@ubuntu-linux-20-04-desktop/T/#maded3df1bebe68d0fe53c73e89f996ec395a39e5
]: 1/3 were merged.

   - [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7[
https://patchew.org/Xen/cover.1711700095.git.nicola.vetr...@bugseng.com/
]: new patch series version (v3) were sent.

   - [XEN PATCH v3 00/16] xen: address violation of MISRA C:2012
Directive 4.10 [
https://patchew.org/Xen/cover.1710145041.git.simone.balla...@bugseng.com/
]: 2/16 were merged.

  * [PATCH v6 00/8] xen/spinlock: make recursive spinlocks a dedicated
type [ https://patchew.org/Xen/20240327152229.25847-1-jgr...@suse.com/
]:
- new patch series version were sent

  * [PATCH 0/7] GRUB: Supporting Secure Boot of xen.gz [
https://patchew.org/Xen/20240313150748.791236-1-ross.lagerw...@citrix.com/
]:

  * [PATCH v5 0/7] MSI-X support with qemu in stubdomain, and other
related changes:
 
  * [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs() [
https://patchew.org/Xen/20240313172716.2325427-1-andrew.coop...@citrix.com/
]:
  
  * [PATCH 0/7] xen/trace: Treewide API cleanup [
https://patchew.org/Xen/20240318163552.3808695-1-andrew.coop...@citrix.com/
]:
  
  * [PATCH v2 0/6] xenwatchdogd bugfixes and enhancements

  * [RFC XEN PATCH v6 0/5] Support device passthrough when dom0 is PVH
on Xen [
https://patchew.org/Xen/20240328063402.354496-1-jiqian.c...@amd.com/ ]


*** Completed ***:
  *** Arm ***:
 * xen/arm64: Rework the MMU-off code (idmap) so it is self-
contained

  *** x86 ***:
 * tools: enable xenstore-stubdom to use 9pfs

  *** common ***:
 * NUMA: no need for asm/numa.h when !NUMA
 * xen: move BUG_ON(), WARN_ON(), ASSERT(), ASSERT_UNREACHABLE() to
xen/bug.h
 * xen/lib: 

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Jan Beulich]

On 03.04.2024 13:10, Daniel P. Smith wrote:
> On 4/3/24 02:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>>
>> Well, what does "have no business" leave open?
> 
> Why does it not have any business? Why should a domain that creates an 
> event channel not be able to inquire about its status?

Event channels we talk about here are created via
alloc_unbound_xen_event_channel(). IOW it's not any domain creating them.
Once connected, the respective domain is of course fine to query its end
of the channel.

>>> The claim is false, and the commit broke lsevtchn in dom0.
>>
>> Or alternatively lsevtchn was doing something that was never meant to work
>> (from Xen's perspective).
> 
> Again, you have not said why this is a problem. What concern does it 
> create? Does it open the door for access elevation, resource 
> deprivation, or some other malicious behaviors?

It exposes information that perhaps better wouldn't be exposed. Imo if
Xen owned resource state is of interest, it would want exposing via
hypfs.

>>>   It is also quite
>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>>
>> Why would that be "obvious"? What business would a stubdom have to look at
>> Xen's side of an evtchn?
> 
> Again, you have not expressed why it shouldn't be able to do so.

See above - not its resource, nor its guest's.

>>> Whether to return information about a xen-owned evtchn is a matter of 
>>> policy,
>>> and it's not acceptable to short circuit the XSM on the matter.
>>
>> I can certainly accept this as one possible view point. As in so many cases
>> I'm afraid I dislike you putting it as if it was the only possible one.
> 
> In fact, this commit is in violation of the XSM. It hard-codes a 
> resource access check outside XSM, thus breaking the fine-grained access 
> control of FLASK.

Perhaps; see below and see the question raised in the subsequent reply
to the patch.

>> In summary: The supposed justification you claim is missing in the original
>> change is imo also missing here then: What business would any entity in the
>> system have to look at Xen's side of an event channel? Back at the time, 3
>> people agreed that it's "none".
> 
> As stated, you provided no reason or justification for "has no business" 
> and by face value is an opinion that a few people agreed with. As for 
> why, there could be a myriad number of reasons a domain may want to 
> check the status of an interface it has with the hypervisor. From just 
> logging its state for debug to throttling attempts at sending an event. 
> So why, from a security/access control decision, does this access have 
> to absolutely blocked, even from FLASK?

I didn't say it absolutely needs to be blocked. I'm okay to become
convinced otherwise. But in the description complaining about lack of
reasons in the 3-4 year old change, just to then again not provide any
reasons looks "interesting" to me. (And no, just to take that example,
lsevtchn not working anymore on such channels is not on its own a
reason. As indicated, it may well be that conceptually it was never
supposed to be able to have access to this information. The latest not
anymore when hypfs was introduced.)

Jan

[PATCH] xen/include: move definition of ASM_INT() to xen/linkage.h

[Juergen Gross]

ASM_INT() is defined in arch/[arm|x86]/include/asm/asm_defns.h in
exactly the same way. Instead of replicating this definition for riscv
and ppc, move it to include/xen/linkage.h, where other arch agnostic
definitions for assembler code are living already.

Adapt the generation of assembler sources via tools/binfile to include
the new home of ASM_INT().

Signed-off-by: Juergen Gross 
---
 xen/arch/arm/include/asm/asm_defns.h | 3 ---
 xen/arch/x86/include/asm/asm_defns.h | 3 ---
 xen/include/xen/linkage.h| 2 ++
 xen/tools/binfile| 2 +-
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/include/asm/asm_defns.h 
b/xen/arch/arm/include/asm/asm_defns.h
index c489547d29..47efdf5234 100644
--- a/xen/arch/arm/include/asm/asm_defns.h
+++ b/xen/arch/arm/include/asm/asm_defns.h
@@ -28,9 +28,6 @@
 label:  .asciz msg; \
 .popsection
 
-#define ASM_INT(label, val) \
-DATA(label, 4) .long (val); END(label)
-
 #endif /* __ARM_ASM_DEFNS_H__ */
 /*
  * Local variables:
diff --git a/xen/arch/x86/include/asm/asm_defns.h 
b/xen/arch/x86/include/asm/asm_defns.h
index a69fae78b1..0a3ff70566 100644
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -351,9 +351,6 @@ static always_inline void stac(void)
 4:  .p2align 2; \
 .popsection
 
-#define ASM_INT(label, val) \
-DATA(label, 4) .long (val); END(label)
-
 #define ASM_CONSTANT(name, value)\
 asm ( ".equ " #name ", %P0; .global " #name  \
   :: "i" ((value)) );
diff --git a/xen/include/xen/linkage.h b/xen/include/xen/linkage.h
index 478b1d7287..3d401b88c1 100644
--- a/xen/include/xen/linkage.h
+++ b/xen/include/xen/linkage.h
@@ -60,6 +60,8 @@
 #define DATA_LOCAL(name, align...) \
 SYM(name, DATA, LOCAL, LASTARG(DATA_ALIGN, ## align), DATA_FILL)
 
+#define ASM_INT(label, val)DATA(label, 4) .long (val); END(label)
+
 #endif /*  __ASSEMBLY__ */
 
 #endif /* __LINKAGE_H__ */
diff --git a/xen/tools/binfile b/xen/tools/binfile
index 099d7eda9a..0299326ccc 100755
--- a/xen/tools/binfile
+++ b/xen/tools/binfile
@@ -25,7 +25,7 @@ binsource=$2
 varname=$3
 
 cat <$target
-#include 
+#include 
 
 .section $section.rodata, "a", %progbits
 
-- 
2.35.3

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Jan Beulich]

On 03.04.2024 13:50, Daniel P. Smith wrote:
> On 4/3/24 02:52, Jan Beulich wrote:
>> On 03.04.2024 08:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
 Whether to return information about a xen-owned evtchn is a matter of 
 policy,
 and it's not acceptable to short circuit the XSM on the matter.
>>>
>>> I can certainly accept this as one possible view point. As in so many cases
>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>
>> Further to this: Is there even a way to express the same denial in XSM?
>> alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
>> channel, and (yes, it could in principle be open-coded in Flask code)
>> consumer_is_xen() is private to event_channel.c. I also dare to question
>> whether in SILO mode status information like this should be available.
> 
> To build on the previous response: if the natural failure return value 
> is -EACCESS in response to a domain resource access attempt, then the 
> probability is extremely high that it should be implemented under a XSM 
> hook and not hard-coded into the resource logic.

Possibly. But first of all - could you answer the earlier question I raised?

Jan

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Jan Beulich]

On 03.04.2024 12:54, Oleksii wrote:
> On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:
>> On 03.04.2024 12:19, Oleksii Kurochko wrote:
>>> This patch disables unnecessary configs for two cases:
>>> 1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds
>>> (GitLab CI jobs).
>>> 2. By using tiny64_defconfig for non-randconfig builds.
>>>
>>> Only configs which lead to compilation issues were disabled.
>>>
>>> Signed-off-by: Oleksii Kurochko 
>>> ---
>>> Changes in V7:
>>>  - Disable only configs which cause compilation issues.
>>
>> Since the description doesn't go into details: While I can see that
>> PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
>> work, are HYPFS, ARGO, and XSM really causing issues?
> For Argo, I recieved the following compilation errors:
>common/argo.c:1416:5: error: unknown type name 'p2m_type_t'; did you
>mean 'hvmmem_type_t'?
> 1416 | p2m_type_t p2mt;
>  | ^~
>  | hvmmem_type_t
>common/argo.c:1419:11: error: implicit declaration of function
>'check_get_page_from_gfn' [-Werror=implicit-function-declaration]
> 1419 | ret = check_get_page_from_gfn(d, gfn, false, , );
>  |   ^~~
>common/argo.c:1427:10: error: 'p2m_ram_rw' undeclared (first use in
>this function)
> 1427 | case p2m_ram_rw:
>
> It seems it should be included xen/p2m-common.h and asm/p2m.h in
> common/argo.c.
> 
> For CONFIG_HYPFS_CONFIG ( there is no issue with CONFIG_HYPFS,
> overlooked that ):
>common/config_data.S:1:10: fatal error: asm/asm_defns.h: No such file
>or directory
>1 | #include 
>
> 
> For XSM, I recieved the following error:
> 
>xsm/xsm_core.c:79:19: error: 'xsm_core_init' defined but not used [-
>Werror=unused-function]
>   79 | static int __init xsm_core_init(const void *policy_buffer,
>size_t policy_size)
> 
> I'll add an information with compilation errors to the commit message.

No need to quote full compiler diagnostics, but a hint at the problems
at least. That said, perhaps we want to rather sort the issues than
disable building stuff that sooner or later you will want to build
anyway. For hypfs we look to have an approach already. For Argo what
you suggest makes sense to me; it might be nice to understand where
the P2M headers needed are coming from on x86 and Arm. Ideally common
code .c files wouldn't include asm/*.h.

For XSM I'm a little puzzled: Shouldn't RISC-V have HAS_DEVICE_TREE=y?
Then xsm_core_init() would have a caller.

Jan

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Juergen Gross]

On 03.04.24 13:47, Jan Beulich wrote:

On 03.04.2024 13:18, Juergen Gross wrote:

On 03.04.24 12:54, Oleksii wrote:

On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:

On 03.04.2024 12:19, Oleksii Kurochko wrote:

This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds
(GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.

Only configs which lead to compilation issues were disabled.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
   - Disable only configs which cause compilation issues.


Since the description doesn't go into details: While I can see that
PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
work, are HYPFS, ARGO, and XSM really causing issues?

For Argo, I recieved the following compilation errors:
 common/argo.c:1416:5: error: unknown type name 'p2m_type_t'; did you
 mean 'hvmmem_type_t'?
  1416 | p2m_type_t p2mt;
   | ^~
   | hvmmem_type_t
 common/argo.c:1419:11: error: implicit declaration of function
 'check_get_page_from_gfn' [-Werror=implicit-function-declaration]
  1419 | ret = check_get_page_from_gfn(d, gfn, false, , );
   |   ^~~
 common/argo.c:1427:10: error: 'p2m_ram_rw' undeclared (first use in
 this function)
  1427 | case p2m_ram_rw:
 
It seems it should be included xen/p2m-common.h and asm/p2m.h in

common/argo.c.

For CONFIG_HYPFS_CONFIG ( there is no issue with CONFIG_HYPFS,
overlooked that ):
 common/config_data.S:1:10: fatal error: asm/asm_defns.h: No such file
 or directory
 1 | #include 


Hmm, this seems to be needed for ASM_INT(), which is currently defined the same
way for arm and x86. Maybe we should move that macro to xen/linkage.h and
include that one instead of asm_defns.h?


Indeed while doing the entry annotation work (also touching the build logic
here iirc) I was thinking of doing so.


Okay, I'm preparing a patch.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Daniel P. Smith]

On 4/3/24 02:52, Jan Beulich wrote:

On 03.04.2024 08:16, Jan Beulich wrote:

On 02.04.2024 19:06, Andrew Cooper wrote:

Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.


I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.


Further to this: Is there even a way to express the same denial in XSM?
alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
channel, and (yes, it could in principle be open-coded in Flask code)
consumer_is_xen() is private to event_channel.c. I also dare to question
whether in SILO mode status information like this should be available.


To build on the previous response: if the natural failure return value 
is -EACCESS in response to a domain resource access attempt, then the 
probability is extremely high that it should be implemented under a XSM 
hook and not hard-coded into the resource logic.


v/r,
dps

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Jan Beulich]

On 03.04.2024 13:18, Juergen Gross wrote:
> On 03.04.24 12:54, Oleksii wrote:
>> On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:
>>> On 03.04.2024 12:19, Oleksii Kurochko wrote:
 This patch disables unnecessary configs for two cases:
 1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds
 (GitLab CI jobs).
 2. By using tiny64_defconfig for non-randconfig builds.

 Only configs which lead to compilation issues were disabled.

 Signed-off-by: Oleksii Kurochko 
 ---
 Changes in V7:
   - Disable only configs which cause compilation issues.
>>>
>>> Since the description doesn't go into details: While I can see that
>>> PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
>>> work, are HYPFS, ARGO, and XSM really causing issues?
>> For Argo, I recieved the following compilation errors:
>> common/argo.c:1416:5: error: unknown type name 'p2m_type_t'; did you
>> mean 'hvmmem_type_t'?
>>  1416 | p2m_type_t p2mt;
>>   | ^~
>>   | hvmmem_type_t
>> common/argo.c:1419:11: error: implicit declaration of function
>> 'check_get_page_from_gfn' [-Werror=implicit-function-declaration]
>>  1419 | ret = check_get_page_from_gfn(d, gfn, false, , );
>>   |   ^~~
>> common/argo.c:1427:10: error: 'p2m_ram_rw' undeclared (first use in
>> this function)
>>  1427 | case p2m_ram_rw:
>> 
>> It seems it should be included xen/p2m-common.h and asm/p2m.h in
>> common/argo.c.
>>
>> For CONFIG_HYPFS_CONFIG ( there is no issue with CONFIG_HYPFS,
>> overlooked that ):
>> common/config_data.S:1:10: fatal error: asm/asm_defns.h: No such file
>> or directory
>> 1 | #include 
> 
> Hmm, this seems to be needed for ASM_INT(), which is currently defined the 
> same
> way for arm and x86. Maybe we should move that macro to xen/linkage.h and
> include that one instead of asm_defns.h?

Indeed while doing the entry annotation work (also touching the build logic
here iirc) I was thinking of doing so.

Jan

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Juergen Gross]

On 03.04.24 12:54, Oleksii wrote:

On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:

On 03.04.2024 12:19, Oleksii Kurochko wrote:

This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds
(GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.

Only configs which lead to compilation issues were disabled.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
  - Disable only configs which cause compilation issues.


Since the description doesn't go into details: While I can see that
PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
work, are HYPFS, ARGO, and XSM really causing issues?

For Argo, I recieved the following compilation errors:
common/argo.c:1416:5: error: unknown type name 'p2m_type_t'; did you
mean 'hvmmem_type_t'?
 1416 | p2m_type_t p2mt;
  | ^~
  | hvmmem_type_t
common/argo.c:1419:11: error: implicit declaration of function
'check_get_page_from_gfn' [-Werror=implicit-function-declaration]
 1419 | ret = check_get_page_from_gfn(d, gfn, false, , );
  |   ^~~
common/argo.c:1427:10: error: 'p2m_ram_rw' undeclared (first use in
this function)
 1427 | case p2m_ram_rw:

It seems it should be included xen/p2m-common.h and asm/p2m.h in

common/argo.c.

For CONFIG_HYPFS_CONFIG ( there is no issue with CONFIG_HYPFS,
overlooked that ):
common/config_data.S:1:10: fatal error: asm/asm_defns.h: No such file
or directory
1 | #include 


Hmm, this seems to be needed for ASM_INT(), which is currently defined the same
way for arm and x86. Maybe we should move that macro to xen/linkage.h and
include that one instead of asm_defns.h?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Daniel P. Smith]

On 4/3/24 02:16, Jan Beulich wrote:

On 02.04.2024 19:06, Andrew Cooper wrote:

The commit makes a claim without any kind of justification.


Well, what does "have no business" leave open?


Why does it not have any business? Why should a domain that creates an 
event channel not be able to inquire about its status?



The claim is false, and the commit broke lsevtchn in dom0.


Or alternatively lsevtchn was doing something that was never meant to work
(from Xen's perspective).


Again, you have not said why this is a problem. What concern does it 
create? Does it open the door for access elevation, resource 
deprivation, or some other malicious behaviors?



  It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.


Why would that be "obvious"? What business would a stubdom have to look at
Xen's side of an evtchn?


Again, you have not expressed why it shouldn't be able to do so.


Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.


I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.


In fact, this commit is in violation of the XSM. It hard-codes a 
resource access check outside XSM, thus breaking the fine-grained access 
control of FLASK.



In summary: The supposed justification you claim is missing in the original
change is imo also missing here then: What business would any entity in the
system have to look at Xen's side of an event channel? Back at the time, 3
people agreed that it's "none".


As stated, you provided no reason or justification for "has no business" 
and by face value is an opinion that a few people agreed with. As for 
why, there could be a myriad number of reasons a domain may want to 
check the status of an interface it has with the hypervisor. From just 
logging its state for debug to throttling attempts at sending an event. 
So why, from a security/access control decision, does this access have 
to absolutely blocked, even from FLASK?


v/r,
dps

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Oleksii]

On Wed, 2024-04-03 at 12:28 +0200, Jan Beulich wrote:
> On 03.04.2024 12:19, Oleksii Kurochko wrote:
> > This patch disables unnecessary configs for two cases:
> > 1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds
> > (GitLab CI jobs).
> > 2. By using tiny64_defconfig for non-randconfig builds.
> > 
> > Only configs which lead to compilation issues were disabled.
> > 
> > Signed-off-by: Oleksii Kurochko 
> > ---
> > Changes in V7:
> >  - Disable only configs which cause compilation issues.
> 
> Since the description doesn't go into details: While I can see that
> PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
> work, are HYPFS, ARGO, and XSM really causing issues?
For Argo, I recieved the following compilation errors:
   common/argo.c:1416:5: error: unknown type name 'p2m_type_t'; did you
   mean 'hvmmem_type_t'?
1416 | p2m_type_t p2mt;
 | ^~
 | hvmmem_type_t
   common/argo.c:1419:11: error: implicit declaration of function
   'check_get_page_from_gfn' [-Werror=implicit-function-declaration]
1419 | ret = check_get_page_from_gfn(d, gfn, false, , );
 |   ^~~
   common/argo.c:1427:10: error: 'p2m_ram_rw' undeclared (first use in
   this function)
1427 | case p2m_ram_rw:
   
It seems it should be included xen/p2m-common.h and asm/p2m.h in
common/argo.c.

For CONFIG_HYPFS_CONFIG ( there is no issue with CONFIG_HYPFS,
overlooked that ):
   common/config_data.S:1:10: fatal error: asm/asm_defns.h: No such file
   or directory
   1 | #include 
   

For XSM, I recieved the following error:

   xsm/xsm_core.c:79:19: error: 'xsm_core_init' defined but not used [-
   Werror=unused-function]
  79 | static int __init xsm_core_init(const void *policy_buffer,
   size_t policy_size)

I'll add an information with compilation errors to the commit message.

~ Oleksii

> 
> > --- a/xen/arch/riscv/configs/tiny64_defconfig
> > +++ b/xen/arch/riscv/configs/tiny64_defconfig
> > @@ -1,12 +1,11 @@
> > -# CONFIG_SCHED_CREDIT is not set
> > -# CONFIG_SCHED_RTDS is not set
> > -# CONFIG_SCHED_NULL is not set
> > -# CONFIG_SCHED_ARINC653 is not set
> > -# CONFIG_TRACEBUFFER is not set
> >  # CONFIG_HYPFS is not set
> >  # CONFIG_GRANT_TABLE is not set
> > -# CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
> >  # CONFIG_MEM_ACCESS is not set
> > +# CONFIG_ARGO is not set
> > +# CONFIG_PERF_COUNTERS is not set
> > +# CONFIG_COVERAGE is not set
> > +# CONFIG_LIVEPATCH is not set
> > +# CONFIG_XSM is not set
> >  
> >  CONFIG_RISCV_64=y
> >  CONFIG_DEBUG=y
> 
> The description also says nothing about the items being removed.
> 
> Jan

[PATCH v7 17/19] xen/riscv: add minimal amount of stubs to build full Xen

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V7:
 - Only rebase was done.
---
Changes in V6:
 - update the commit in stubs.c around /* ... common/irq.c ... */
 - add Acked-by: Jan Beulich 
---
Changes in V5:
 - drop unrelated changes
 - assert_failed("unimplmented...") change to BUG_ON()
---
Changes in V4:
  - added new stubs which are necessary for compilation after rebase: 
__cpu_up(), __cpu_disable(), __cpu_die()
from smpboot.c
  - back changes related to printk() in early_printk() as they should be 
removed in the next patch to avoid
compilation error.
  - update definition of cpu_khz: __read_mostly -> __ro_after_init.
  - drop vm_event_reset_vmtrace(). It is defibed in asm-generic/vm_event.h.
  - move vm_event_*() functions from stubs.c to riscv/vm_event.c.
  - s/BUG/BUG_ON("unimplemented") in stubs.c
  - back irq_actor_none() and irq_actor_none() as common/irq.c isn't compiled 
at this moment,
so this function are needed to avoid compilation error.
  - defined max_page to avoid compilation error, it will be removed as soon as 
common/page_alloc.c will
be compiled.
---
Changes in V3:
 - code style fixes.
 - update attribute for frametable_base_pdx  and frametable_virt_end to 
__ro_after_init.
   insteaf of read_mostly.
 - use BUG() instead of assert_failed/WARN for newly introduced stubs.
 - drop "#include " in stubs.c and use forward declaration 
instead.
 - drop ack_node() and end_node() as they aren't used now.
---
Changes in V2:
 - define udelay stub
 - remove 'select HAS_PDX' from RISC-V Kconfig because of
   
https://lore.kernel.org/xen-devel/20231006144405.1078260-1-andrew.coop...@citrix.com/
---
 xen/arch/riscv/Makefile |   1 +
 xen/arch/riscv/mm.c |  50 +
 xen/arch/riscv/setup.c  |   8 +
 xen/arch/riscv/stubs.c  | 439 
 xen/arch/riscv/traps.c  |  25 +++
 5 files changed, 523 insertions(+)
 create mode 100644 xen/arch/riscv/stubs.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 1ed1a8369b..60afbc0ad9 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -4,6 +4,7 @@ obj-y += mm.o
 obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
+obj-y += stubs.o
 obj-y += traps.o
 obj-y += vm_event.o
 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index fe3a43be20..2c3fb7d72e 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
@@ -14,6 +15,9 @@
 #include 
 #include 
 
+unsigned long __ro_after_init frametable_base_pdx;
+unsigned long __ro_after_init frametable_virt_end;
+
 struct mmu_desc {
 unsigned int num_levels;
 unsigned int pgtbl_count;
@@ -294,3 +298,49 @@ unsigned long __init calc_phys_offset(void)
 phys_offset = load_start - XEN_VIRT_START;
 return phys_offset;
 }
+
+void put_page(struct page_info *page)
+{
+BUG_ON("unimplemented");
+}
+
+unsigned long get_upper_mfn_bound(void)
+{
+/* No memory hotplug yet, so current memory limit is the final one. */
+return max_page - 1;
+}
+
+void arch_dump_shared_mem_info(void)
+{
+BUG_ON("unimplemented");
+}
+
+int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
+{
+BUG_ON("unimplemented");
+return -1;
+}
+
+int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
+  union add_to_physmap_extra extra,
+  unsigned long idx, gfn_t gfn)
+{
+BUG_ON("unimplemented");
+
+return 0;
+}
+
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+BUG_ON("unimplemented");
+return -1;
+}
+
+int map_pages_to_xen(unsigned long virt,
+ mfn_t mfn,
+ unsigned long nr_mfns,
+ unsigned int flags)
+{
+BUG_ON("unimplemented");
+return -1;
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 98a94c4c48..8bb5bdb2ae 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -1,11 +1,19 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+
 #include 
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+BUG_ON("unimplemented");
+}
+
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
 __aligned(STACK_SIZE);
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
new file mode 100644
index 00..8285bcffef
--- /dev/null
+++ b/xen/arch/riscv/stubs.c
@@ -0,0 +1,439 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* smpboot.c */
+
+cpumask_t cpu_online_map;
+cpumask_t cpu_present_map;
+cpumask_t cpu_possible_map;
+
+/* ID of the PCPU we're running on */
+DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ac682fbac14a4286645810c02f60a2ba844b6c0a
baseline version:
 xen  7a09966e7b2823b70f6d56d0cf66c11124f4a3c1

Last test of basis   185196  2024-03-28 21:04:03 Z5 days
Testing same since   185225  2024-04-03 08:02:08 Z0 days1 attempts


People who touched revisions under test:
  Federico Serafini 
  Jan Beulich 
  Marek Marczykowski-Górecki 
  Nicola Vetrini 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7a09966e7b..ac682fbac1  ac682fbac14a4286645810c02f60a2ba844b6c0a -> smoke

[PATCH v7 16/19] xen/riscv: introduce vm_event_*() functions

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
---
Changes in V5-V7:
 - Only rebase was done.
---
Changes in V4:
  - New patch.
---
 xen/arch/riscv/Makefile   |  1 +
 xen/arch/riscv/vm_event.c | 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 xen/arch/riscv/vm_event.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 2fefe14e7c..1ed1a8369b 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
 obj-y += traps.o
+obj-y += vm_event.o
 
 $(TARGET): $(TARGET)-syms
$(OBJCOPY) -O binary -S $< $@
diff --git a/xen/arch/riscv/vm_event.c b/xen/arch/riscv/vm_event.c
new file mode 100644
index 00..bb1fc73bc1
--- /dev/null
+++ b/xen/arch/riscv/vm_event.c
@@ -0,0 +1,19 @@
+#include 
+
+struct vm_event_st;
+struct vcpu;
+
+void vm_event_fill_regs(struct vm_event_st *req)
+{
+BUG_ON("unimplemented");
+}
+
+void vm_event_set_registers(struct vcpu *v, struct vm_event_st *rsp)
+{
+BUG_ON("unimplemented");
+}
+
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+/* Not supported on RISCV. */
+}
-- 
2.43.0

Re: [PATCH v7 03/19] xen/riscv: introduce extenstion support check by compiler

[Jan Beulich]

On 03.04.2024 12:19, Oleksii Kurochko wrote:
> Currently, RISC-V requires two extensions: _zbb and _zihintpause.
> 
> This patch introduces a compiler check to check if these extensions
> are supported.
> Additionally, it introduces the riscv/booting.txt file, which contains
> information about the extensions that should be supported by the platform.
> 
> In the future, a feature will be introduced to check whether an extension
> is supported at runtime.
> However, this feature requires functionality for parsing device tree
> source (DTS), which is not yet available.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 

However, ...

> --- a/xen/arch/riscv/arch.mk
> +++ b/xen/arch/riscv/arch.mk
> @@ -3,16 +3,27 @@
>  
>  $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
>  
> -CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64
> +riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
> +riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64
>  
>  riscv-march-$(CONFIG_RISCV_ISA_RV64G) := rv64g
>  riscv-march-$(CONFIG_RISCV_ISA_C)   := $(riscv-march-y)c
>  
> +riscv-generic-flags := $(riscv-abi-y) -march=$(riscv-march-y)
> +
> +zbb := $(call as-insn,$(CC) $(riscv-generic-flags)_zbb,"",_zbb)
> +zihintpause := $(call as-insn,\
> +   $(CC) $(riscv-generic-flags)_zihintpause,"pause",_zihintpause)

... this would better be indented thus

zihintpause := $(call as-insn, \
  $(CC) 
$(riscv-generic-flags)_zihintpause,"pause",_zihintpause)

to make nesting entirely obvious. I guess I'll table the liberty to adjust
while committing.

I'd also like to note that this is specifically not what I had suggested.
But it at least improves readability.

Jan

Re: [PATCH 4/4] xen/virtual-region: Drop setup_virtual_regions()

[Oleksii]

On Mon, 2024-03-18 at 13:49 +, Andrew Cooper wrote:
> On 18/03/2024 1:29 pm, Jan Beulich wrote:
> > On 18.03.2024 12:04, Andrew Cooper wrote:
> > > --- a/xen/common/virtual_region.c
> > > +++ b/xen/common/virtual_region.c
> > > @@ -39,6 +39,11 @@ static struct virtual_region core = {
> > >  { __start_bug_frames_2, __stop_bug_frames_2 },
> > >  { __start_bug_frames_3, __stop_bug_frames_3 },
> > >  },
> > > +
> > > +#ifdef CONFIG_X86
> > > +    .ex = __start___ex_table,
> > > +    .ex_end = __stop___ex_table,
> > > +#endif
> > >  };
> > >  
> > >  /* Becomes irrelevant when __init sections are cleared. */
> > > @@ -57,6 +62,11 @@ static struct virtual_region core_init
> > > __initdata = {
> > >  { __start_bug_frames_2, __stop_bug_frames_2 },
> > >  { __start_bug_frames_3, __stop_bug_frames_3 },
> > >  },
> > > +
> > > +#ifdef CONFIG_X86
> > > +    .ex = __start___ex_table,
> > > +    .ex_end = __stop___ex_table,
> > > +#endif
> > >  };
> > My main reservation here is this x86-specific code in a common
> > file.
> > Are we certain both RISC-V and PPC will get away without needing to
> > touch this? If so, I might consider ack-ing. But really I'd prefer
> > if
> > this could be minimally abstracted, via e.g. CONFIG_HAS_EXTABLE
> > (selected by x86 only for now).
> 
> This isn't the first bit of CONFIG_X86 in this file.  However, I'd
> not
> spotted that we have CONFIG_HAS_EX_TABLE already.  I can swap.
> 
> As to extable on other architectures, that's not something I can
> answer,
> although it's not something I can see in Oleksii's or Shawn's series
> so far.
That's correct for RISC-V. Currently, I'm not utilizing
__start___ex_table/__stop___ex_table, and setup_virtual_regions() is
called with setup_virtual_regions(NULL, NULL).

~ Oleksii

[PATCH v7 13/19] xen/riscv: add required things to current.h

[Oleksii Kurochko]

Add minimal requied things to be able to build full Xen.

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5/V6/V7:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - BUG() was changed to BUG_ON("unimplemented");
 - Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in xen/lib.h.
 - Add Acked-by: Jan Beulich 
---
Changes in V3:
 - add SPDX
 - drop a forward declaration of struct vcpu;
 - update guest_cpu_user_regs() macros
 - replace get_processor_id with smp_processor_id
 - update the commit message
 - code style fixes
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/current.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/riscv/include/asm/current.h 
b/xen/arch/riscv/include/asm/current.h
index d84f15dc50..aedb6dc732 100644
--- a/xen/arch/riscv/include/asm/current.h
+++ b/xen/arch/riscv/include/asm/current.h
@@ -3,6 +3,21 @@
 #ifndef __ASM_CURRENT_H
 #define __ASM_CURRENT_H
 
+#include 
+#include 
+#include 
+
+#ifndef __ASSEMBLY__
+
+/* Which VCPU is "current" on this PCPU. */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#define currentthis_cpu(curr_vcpu)
+#define set_current(vcpu)  do { current = (vcpu); } while (0)
+#define get_cpu_current(cpu)  per_cpu(curr_vcpu, cpu)
+
+#define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; })
+
 #define switch_stack_and_jump(stack, fn) do {   \
 asm volatile (  \
 "mv sp, %0\n"   \
@@ -10,4 +25,8 @@
 unreachable();  \
 } while ( false )
 
+#define get_per_cpu_offset() __per_cpu_offset[smp_processor_id()]
+
+#endif /* __ASSEMBLY__ */
+
 #endif /* __ASM_CURRENT_H */
-- 
2.43.0

[PATCH v7 14/19] xen/riscv: add minimal stuff to page.h to build full Xen

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5-V7:
 - Nothing changed. Only rebase.
---
Changes in V4:
---
 - Change message -> subject in "Changes in V3"
 - s/BUG/BUG_ON("...")
 - Do proper rebase ( pfn_to_paddr() and paddr_to_pfn() aren't removed ).
---
Changes in V3:
 - update the commit subject
 - add implemetation of PAGE_HYPERVISOR macros
 - add Acked-by: Jan Beulich 
 - drop definition of pfn_to_addr, and paddr_to_pfn in 
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/page.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/riscv/include/asm/page.h 
b/xen/arch/riscv/include/asm/page.h
index 95074e29b3..c831e16417 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -6,6 +6,7 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 #include 
 
 #include 
@@ -32,6 +33,10 @@
 #define PTE_LEAF_DEFAULT(PTE_VALID | PTE_READABLE | PTE_WRITABLE)
 #define PTE_TABLE   (PTE_VALID)
 
+#define PAGE_HYPERVISOR_RW  (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
+
+#define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
+
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))
 
@@ -62,6 +67,20 @@ static inline bool pte_is_valid(pte_t p)
 return p.pte & PTE_VALID;
 }
 
+static inline void invalidate_icache(void)
+{
+BUG_ON("unimplemented");
+}
+
+#define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
+#define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
+
+/* TODO: Flush the dcache for an entire page. */
+static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
+{
+BUG_ON("unimplemented");
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_RISCV_PAGE_H */
-- 
2.43.0

[PATCH v7 18/19] xen/riscv: enable full Xen build

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Jan Beulich 
---
Changes in V5-V7:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is 
compiled now.
 - drop defintion of max_page in stubs.c as common/page_alloc.c is compiled now.
 - drop printk() related changes in riscv/early_printk.c as common version will 
be used.
---
Changes in V3:
 - Reviewed-by: Jan Beulich 
 - unrealted change dropped in tiny64_defconfig
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/Makefile   |  16 +++-
 xen/arch/riscv/arch.mk|   4 -
 xen/arch/riscv/early_printk.c | 168 --
 xen/arch/riscv/stubs.c|  24 -
 4 files changed, 15 insertions(+), 197 deletions(-)

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 60afbc0ad9..81b77b13d6 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -12,10 +12,24 @@ $(TARGET): $(TARGET)-syms
$(OBJCOPY) -O binary -S $< $@
 
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-   $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) -o $@
+   $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
+   $(objtree)/common/symbols-dummy.o -o $(dot-target).0
+   $(NM) -pa --format=sysv $(dot-target).0 \
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+   > $(dot-target).0.S
+   $(MAKE) $(build)=$(@D) $(dot-target).0.o
+   $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
+   $(dot-target).0.o -o $(dot-target).1
+   $(NM) -pa --format=sysv $(dot-target).1 \
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+   > $(dot-target).1.S
+   $(MAKE) $(build)=$(@D) $(dot-target).1.o
+   $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
+   $(dot-target).1.o -o $@
$(NM) -pa --format=sysv $@ \
| $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
> $@.map
+   rm -f $(@D)/.$(@F).[0-9]*
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk
index 24a7461bcc..517bb662e4 100644
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -24,7 +24,3 @@ extensions := $(subst $(space),,$(extensions))
 # -mcmodel=medlow would force Xen into the lower half.
 
 CFLAGS += $(riscv-generic-flags)$(extensions) -mstrict-align -mcmodel=medany
-
-# TODO: Drop override when more of the build is working
-override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
-override ALL_LIBS-y =
diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
index 60742a042d..610c814f54 100644
--- a/xen/arch/riscv/early_printk.c
+++ b/xen/arch/riscv/early_printk.c
@@ -40,171 +40,3 @@ void early_printk(const char *str)
 str++;
 }
 }
-
-/*
- * The following #if 1 ... #endif should be removed after printk
- * and related stuff are ready.
- */
-#if 1
-
-#include 
-#include 
-
-/**
- * strlen - Find the length of a string
- * @s: The string to be sized
- */
-size_t (strlen)(const char * s)
-{
-const char *sc;
-
-for (sc = s; *sc != '\0'; ++sc)
-/* nothing */;
-return sc - s;
-}
-
-/**
- * memcpy - Copy one area of memory to another
- * @dest: Where to copy to
- * @src: Where to copy from
- * @count: The size of the area.
- *
- * You should not use this function to access IO space, use memcpy_toio()
- * or memcpy_fromio() instead.
- */
-void *(memcpy)(void *dest, const void *src, size_t count)
-{
-char *tmp = (char *) dest, *s = (char *) src;
-
-while (count--)
-*tmp++ = *s++;
-
-return dest;
-}
-
-int vsnprintf(char* str, size_t size, const char* format, va_list args)
-{
-size_t i = 0; /* Current position in the output string */
-size_t written = 0; /* Total number of characters written */
-char* dest = str;
-
-while ( format[i] != '\0' && written < size - 1 )
-{
-if ( format[i] == '%' )
-{
-i++;
-
-if ( format[i] == '\0' )
-break;
-
-if ( format[i] == '%' )
-{
-if ( written < size - 1 )
-{
-dest[written] = '%';
-written++;
-}
-i++;
-continue;
-}
-
-/*
- * Handle format specifiers.
- * For simplicity, only %s and %d are implemented here.
- */
-
-if ( format[i] == 's' )
-{
-char* arg = va_arg(args, char*);
-size_t arglen = strlen(arg);
-
-size_t remaining = size - written - 1;
-
-if ( arglen > remaining )
-arglen = remaining;
-
-memcpy(dest + written, arg, arglen);
-
-written += arglen;
-

Re: [PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Jan Beulich]

On 03.04.2024 12:19, Oleksii Kurochko wrote:
> This patch disables unnecessary configs for two cases:
> 1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
> 2. By using tiny64_defconfig for non-randconfig builds.
> 
> Only configs which lead to compilation issues were disabled.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V7:
>  - Disable only configs which cause compilation issues.

Since the description doesn't go into details: While I can see that
PERF_COUNTERS and LIVEPATCH may require (a little / some more) extra
work, are HYPFS, ARGO, and XSM really causing issues?

> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -1,12 +1,11 @@
> -# CONFIG_SCHED_CREDIT is not set
> -# CONFIG_SCHED_RTDS is not set
> -# CONFIG_SCHED_NULL is not set
> -# CONFIG_SCHED_ARINC653 is not set
> -# CONFIG_TRACEBUFFER is not set
>  # CONFIG_HYPFS is not set
>  # CONFIG_GRANT_TABLE is not set
> -# CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
>  # CONFIG_MEM_ACCESS is not set
> +# CONFIG_ARGO is not set
> +# CONFIG_PERF_COUNTERS is not set
> +# CONFIG_COVERAGE is not set
> +# CONFIG_LIVEPATCH is not set
> +# CONFIG_XSM is not set
>  
>  CONFIG_RISCV_64=y
>  CONFIG_DEBUG=y

The description also says nothing about the items being removed.

Jan

[PATCH v7 19/19] xen/README: add compiler and binutils versions for RISC-V64

[Oleksii Kurochko]

This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.

While it is feasible to utilize Clang, it's important to note that,
currently, there is no Xen RISC-V CI job in place to verify the
seamless functioning of the build with Clang.

Signed-off-by: Oleksii Kurochko 
---
Changes in V5-V7:
 - Nothing changed. Only rebase.
---
 Changes in V6:
  - update the message in README.
---
 Changes in V5:
  - update the commit message and README file with additional explanation about 
GCC and
GNU Binutils version. Additionally, it was added information about Clang.
---
 Changes in V4:
  - Update version of GCC (12.2) and GNU Binutils (2.39) to the version
which are in Xen's contrainter for RISC-V
---
 Changes in V3:
  - new patch
---
 README | 4 
 1 file changed, 4 insertions(+)

diff --git a/README b/README
index c8a108449e..30da5ff9c0 100644
--- a/README
+++ b/README
@@ -48,6 +48,10 @@ provided by your OS distributor:
   - For ARM 64-bit:
 - GCC 5.1 or later
 - GNU Binutils 2.24 or later
+  - For RISC-V 64-bit:
+- GCC 12.2 or later
+- GNU Binutils 2.39 or later
+  Older GCC and GNU Binutils would work, but this is not a guarantee.
 * POSIX compatible awk
 * Development install of zlib (e.g., zlib-dev)
 * Development install of Python 2.7 or later (e.g., python-dev)
-- 
2.43.0

[PATCH v7 05/19] xen/bitops: implement fls{l}() in common logic

[Oleksii Kurochko]

Return type was left 'int' because of the following compilation error:

./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks 
a cast [-Werror]
   18 | (void) (&_x == &_y);\
  | ^~
common/page_alloc.c:1843:34: note: in expansion of macro 'min'
 1843 | unsigned int inc_order = min(MAX_ORDER, flsl(e - s) - 1);

generic_fls{l} was used instead of __builtin_clz{l}(x) as if x is 0,
the result in undefined.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - Code style fixes
---
Changes in V6:
 - new patch for the patch series.
---
 xen/arch/arm/include/asm/arm32/bitops.h |  2 +-
 xen/arch/arm/include/asm/arm64/bitops.h |  6 ++
 xen/arch/arm/include/asm/bitops.h   |  7 ++-
 xen/arch/x86/include/asm/bitops.h   |  6 --
 xen/common/bitops.c | 22 ++
 xen/include/xen/bitops.h|  4 ++--
 6 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/bitops.h 
b/xen/arch/arm/include/asm/arm32/bitops.h
index d0309d47c1..5552d4e945 100644
--- a/xen/arch/arm/include/asm/arm32/bitops.h
+++ b/xen/arch/arm/include/asm/arm32/bitops.h
@@ -1,7 +1,7 @@
 #ifndef _ARM_ARM32_BITOPS_H
 #define _ARM_ARM32_BITOPS_H
 
-#define flsl fls
+#define arch_flsl fls
 
 /*
  * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
diff --git a/xen/arch/arm/include/asm/arm64/bitops.h 
b/xen/arch/arm/include/asm/arm64/bitops.h
index 0efde29068..5f5d97faa0 100644
--- a/xen/arch/arm/include/asm/arm64/bitops.h
+++ b/xen/arch/arm/include/asm/arm64/bitops.h
@@ -22,17 +22,15 @@ static /*__*/always_inline unsigned long __ffs(unsigned 
long word)
  */
 #define ffz(x)  __ffs(~(x))
 
-static inline int flsl(unsigned long x)
+static inline int arch_flsl(unsigned long x)
 {
 uint64_t ret;
 
-if (__builtin_constant_p(x))
-   return generic_flsl(x);
-
 asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
 
 return BITS_PER_LONG - ret;
 }
+#define arch_flsl arch_flsl
 
 /* Based on linux/include/asm-generic/bitops/find.h */
 
diff --git a/xen/arch/arm/include/asm/bitops.h 
b/xen/arch/arm/include/asm/bitops.h
index 8e16335e76..860d6d4689 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -78,17 +78,14 @@ bool clear_mask16_timeout(uint16_t mask, volatile void *p,
  * the clz instruction for much better code efficiency.
  */
 
-static inline int fls(unsigned int x)
+static inline int arch_fls(unsigned int x)
 {
 int ret;
 
-if (__builtin_constant_p(x))
-   return generic_fls(x);
-
 asm("clz\t%"__OP32"0, %"__OP32"1" : "=r" (ret) : "r" (x));
 return 32 - ret;
 }
-
+#define arch_fls arch_fls
 
 #define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
 #define arch_ffsl(x) ({ unsigned long __t = (x); flsl(ISOLATE_LSB(__t)); })
diff --git a/xen/arch/x86/include/asm/bitops.h 
b/xen/arch/x86/include/asm/bitops.h
index 81b43da5db..9c4ab52df7 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -428,7 +428,7 @@ static always_inline unsigned int arch_ffsl(unsigned long x)
  *
  * This is defined the same way as ffs.
  */
-static inline int flsl(unsigned long x)
+static always_inline int arch_flsl(unsigned long x)
 {
 long r;
 
@@ -438,8 +438,9 @@ static inline int flsl(unsigned long x)
   "1:" : "=r" (r) : "rm" (x));
 return (int)r+1;
 }
+#define arch_flsl arch_flsl
 
-static inline int fls(unsigned int x)
+static always_inline int arch_fls(unsigned int x)
 {
 int r;
 
@@ -449,6 +450,7 @@ static inline int fls(unsigned int x)
   "1:" : "=r" (r) : "rm" (x));
 return r + 1;
 }
+#define arch_fls arch_fls
 
 /**
  * hweightN - returns the hamming weight of a N-bit word
diff --git a/xen/common/bitops.c b/xen/common/bitops.c
index a8c32f6767..95bc47176b 100644
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -62,9 +62,31 @@ static void test_ffs(void)
 CHECK(ffs64, (uint64_t)0x8000, 64);
 }
 
+static void test_fls(void)
+{
+/* unsigned int ffs(unsigned int) */
+CHECK(fls, 1, 1);
+CHECK(fls, 3, 2);
+CHECK(fls, 3U << 30, 32);
+
+/* unsigned int flsl(unsigned long) */
+CHECK(flsl, 1, 1);
+CHECK(flsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
+#if BITS_PER_LONG > 32
+CHECK(flsl, 3UL << 32, 34);
+#endif
+
+/* unsigned int fls64(uint64_t) */
+CHECK(fls64, 1, 1);
+CHECK(fls64, 0xC000ULL, 32);
+CHECK(fls64, 0x00018000ULL, 33);
+CHECK(fls64, 0xC000ULL, 64);
+}
+
 static int __init cf_check test_bitops(void)
 {
 test_ffs();
+test_fls();
 
 return 0;
 }
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 685c7540cc..bc8ae53997 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -201,7 +201,7 @@ static always_inline __pure int 

[PATCH v7 11/19] xen/riscv: introduce monitor.h

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
---
Changes in V4-V7:
 - Nothing changed. Only rebase.
---
Changes in V3:
 - new patch.
---
 xen/arch/riscv/include/asm/monitor.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/monitor.h

diff --git a/xen/arch/riscv/include/asm/monitor.h 
b/xen/arch/riscv/include/asm/monitor.h
new file mode 100644
index 00..f4fe2c0690
--- /dev/null
+++ b/xen/arch/riscv/include/asm/monitor.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_RISCV_MONITOR_H__
+#define __ASM_RISCV_MONITOR_H__
+
+#include 
+
+#include 
+
+struct domain;
+
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+BUG_ON("unimplemented");
+return 0;
+}
+
+#endif /* __ASM_RISCV_MONITOR_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0

[PATCH v7 12/19] xen/riscv: add definition of __read_mostly

[Oleksii Kurochko]

The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/

The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.

Signed-off-by: Oleksii Kurochko 
---
- [PATCH] move __read_mostly to xen/cache.h  [2]

Right now, the patch series doesn't have a direct dependency on [2] and it
provides __read_mostly in the patch:
[PATCH v3 26/34] xen/riscv: add definition of __read_mostly
However, it will be dropped as soon as [2] is merged or at least when the
final version of the patch [2] is provided.

[2] 
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
---
Changes in V4-V7:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/cache.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/riscv/include/asm/cache.h 
b/xen/arch/riscv/include/asm/cache.h
index 69573eb051..94bd94db53 100644
--- a/xen/arch/riscv/include/asm/cache.h
+++ b/xen/arch/riscv/include/asm/cache.h
@@ -3,4 +3,6 @@
 #ifndef _ASM_RISCV_CACHE_H
 #define _ASM_RISCV_CACHE_H
 
+#define __read_mostly __section(".data.read_mostly")
+
 #endif /* _ASM_RISCV_CACHE_H */
-- 
2.43.0

[PATCH v7 02/19] xen/riscv: disable unnecessary configs

[Oleksii Kurochko]

This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.

Only configs which lead to compilation issues were disabled.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - Disable only configs which cause compilation issues.
 - Update the commit message.
---
Changes in V6:
 - Nothing changed. Only rebase.
---
Changes in V5:
 - Rebase and drop duplicated configs in EXTRA_FIXED_RANDCONFIG list
 - Update the commit message
---
Changes in V4:
 - Nothing changed. Only rebase
---
Changes in V3:
 - Remove EXTRA_FIXED_RANDCONFIG for non-randconfig jobs.
   For non-randconfig jobs, it is sufficient to disable configs by using the 
defconfig.
 - Remove double blank lines in build.yaml file before 
archlinux-current-gcc-riscv64-debug
---
Changes in V2:
 - update the commit message.
 - remove xen/arch/riscv/Kconfig changes.
---
 automation/gitlab-ci/build.yaml |  5 +
 xen/arch/riscv/configs/tiny64_defconfig | 11 +--
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index aac29ee13a..43faeaed9c 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -519,6 +519,11 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
   CONFIG_EXPERT=y
   CONFIG_GRANT_TABLE=n
   CONFIG_MEM_ACCESS=n
+  CONFIG_HYPFS=n
+  CONFIG_ARGO=n
+  CONFIG_PERF_COUNTERS=n
+  CONFIG_LIVEPATCH=n
+  CONFIG_XSM=n
 
 archlinux-current-gcc-riscv64:
   extends: .gcc-riscv64-cross-build
diff --git a/xen/arch/riscv/configs/tiny64_defconfig 
b/xen/arch/riscv/configs/tiny64_defconfig
index 09defe236b..24a807a5f9 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -1,12 +1,11 @@
-# CONFIG_SCHED_CREDIT is not set
-# CONFIG_SCHED_RTDS is not set
-# CONFIG_SCHED_NULL is not set
-# CONFIG_SCHED_ARINC653 is not set
-# CONFIG_TRACEBUFFER is not set
 # CONFIG_HYPFS is not set
 # CONFIG_GRANT_TABLE is not set
-# CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
 # CONFIG_MEM_ACCESS is not set
+# CONFIG_ARGO is not set
+# CONFIG_PERF_COUNTERS is not set
+# CONFIG_COVERAGE is not set
+# CONFIG_LIVEPATCH is not set
+# CONFIG_XSM is not set
 
 CONFIG_RISCV_64=y
 CONFIG_DEBUG=y
-- 
2.43.0

[PATCH v7 08/19] xen/riscv: introduce cmpxchg.h

[Oleksii Kurochko]

The header was taken from Linux kernl 6.4.0-rc1.

Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
  access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
* drop {cmp}xchg{release,relaxed,acquire} as Xen doesn't use them
* drop barries and use instruction suffixices instead ( .aq, .rl, .aqrl )

Implementation of 4- and 8-byte cases were updated according to the spec:
```
  
Linux Construct RVWMO AMO Mapping
...
atomic  amo.{w|d}.aqrl
Linux Construct RVWMO LR/SC Mapping
...
atomic  loop: lr.{w|d}.aq; ; sc.{w|d}.aqrl; bnez loop

Table A.5: Mappings from Linux memory primitives to RISC-V primitives

```

The current implementation is the same with 8e86f0b409a4
("arm64: atomics: fix use of acquire + release for full barrier
semantics") [1].
RISC-V could combine acquire and release into the SC
instructions and it could reduce a fence instruction to gain better
performance. Here is related description from RISC-V ISA 10.2
Load-Reserved/Store-Conditional Instructions:

 - .aq:   The LR/SC sequence can be given acquire semantics by
  setting the aq bit on the LR instruction.
 - .rl:   The LR/SC sequence can be given release semantics by
  setting the rl bit on the SC instruction.
 - .aqrl: Setting the aq bit on the LR instruction, and setting
  both the aq and the rl bit on the SC instruction makes
  the LR/SC sequence sequentially consistent, meaning that
  it cannot be reordered with earlier or later memory
  operations from the same hart.

 Software should not set the rl bit on an LR instruction unless
 the aq bit is also set, nor should software set the aq bit on an
 SC instruction unless the rl bit is also set. LR.rl and SC.aq
 instructions are not guaranteed to provide any stronger ordering
 than those with both bits clear, but may result in lower
 performance.

Also, I way of transforming ".rl + full barrier" to ".aqrl" was approved
by (the author of the RVWMO spec) [2]

[1] 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1391516953-14541-1-git-send-email-will.dea...@arm.com/
[2] 
https://lore.kernel.org/linux-riscv/41e01514-74ca-84f2-f5cc-2645c444f...@nvidia.com/

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - replace __*() -> _*() in cmpxchg.h
 - add () around ptr in _amoswap_generic(), emulate_xchg_1_2()
 - fix typos
 - code style fixes.
 - refactor emulate_xcgh_1_2():
   - add parentheses for new argument.
   - use instead of constant 0x4 -> sizeof(*aligned_ptr).
   - add alignment_mask to save  sizeof(*aligned_ptr) - sizeof(*(ptr));
 - s/CONFIG_32BIT/CONFIG_RISCV_32
 - drop unnecessary parentheses in xchg()
 - drop register in _generic_cmpxchg()
 - refactor and update prototype of _generic_cmpxchg():
   add named operands, return value instead of passing ret as an argument, drop 
%z and J
   constraints for mask operand as it can't be zero
 - refactor and code style fixes in emulate_cmpxchg_1_2():
   - add explanatory comment for emulate_cmpxchg_1_2().
   - add parentheses for old and new arguments.
   - use instead of constant 0x4 -> sizeof(*aligned_ptr).
   - add alignment_mask to save  sizeof(*aligned_ptr) - sizeof(*(ptr));
 - drop unnessary parenthesses in cmpxchg().
 - update the commit message.
 - s/__asm__ __volatile__/asm volatile
---
Changes in V6:
-  update the commit message? ( As before I don't understand this point. Can 
you give an example of what sort of opcode / instruction is missing?)
 - Code style fixes
 - change sizeof(*ptr) -> sizeof(*(ptr))
 - update operands names and some local variables for macros emulate_xchg_1_2() 
and emulate_cmpxchg_1_2()
 - drop {cmp}xchg_{relaxed,acquire,release) versions as they aren't needed for 
Xen
 - update __amoswap_generic() prototype and defintion: drop pre and post 
barries.
 - update emulate_xchg_1_2() prototype and definion: add lr_sfx, drop pre and 
post barries.
 - rename __xchg_generic to __xchg(), make __xchg as static inline function to 
be able to "#ifndef CONFIG_32BIT case 8:... " 
---
Changes in V5:
 - update the commit message.
 - drop ALIGN_DOWN().
 - update the definition of emulate_xchg_1_2(): 
   - lr.d -> lr.w, sc.d -> sc.w.
   - drop ret argument.
   - code style fixes around asm volatile.
   - update prototype.
   - use asm named operands.
   - rename local variables.
   - add comment above the macros
 - update the definition of __xchg_generic:
   - rename to __xchg()
   - transform it to static inline
   - code style fixes around switch()
   - update prototype.
 - redefine cmpxchg()
 - update emulate_cmpxchg_1_2():
   - update prototype
   - update local variables names and usage of them
   - use name asm operands.
   - add comment above the macros
 - drop pre and post, and use .aq,.rl, .aqrl suffixes.
 - drop {cmp}xchg_{relaxed, aquire, release} as they are not used by Xen.
 - drop 

[PATCH v7 10/19] xen/riscv: introduce atomic.h

[Oleksii Kurochko]

Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.

The following changes were done on top of Bobby's changes:
 - atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
   to use__*xchg_generic()
 - drop casts in write_atomic() as they are unnecessary
 - drop introduction of WRITE_ONCE() and READ_ONCE().
   Xen provides ACCESS_ONCE()
 - remove zero-length array access in read_atomic()
 - drop defines similar to pattern:
   #define atomic_add_return_relaxed   atomic_add_return_relaxed
 - move not RISC-V specific functions to asm-generic/atomics-ops.h
 - drop  atomic##prefix##_{cmp}xchg_{release, aquire, release}() as they
   are not used in Xen.
 - update the defintion of  atomic##prefix##_{cmp}xchg according to
   {cmp}xchg() implementation in Xen.

The current implementation is the same with 8e86f0b409a4
("arm64: atomics: fix use of acquire + release for full barrier
semantics") [1].
RISC-V could combine acquire and release into the SC
instructions and it could reduce a fence instruction to gain better
performance. Here is related description from RISC-V ISA 10.2
Load-Reserved/Store-Conditional Instructions:

 - .aq:   The LR/SC sequence can be given acquire semantics by
  setting the aq bit on the LR instruction.
 - .rl:   The LR/SC sequence can be given release semantics by
  setting the rl bit on the SC instruction.
 - .aqrl: Setting the aq bit on the LR instruction, and setting
  both the aq and the rl bit on the SC instruction makes
  the LR/SC sequence sequentially consistent, meaning that
  it cannot be reordered with earlier or later memory
  operations from the same hart.

 Software should not set the rl bit on an LR instruction unless
 the aq bit is also set, nor should software set the aq bit on an
 SC instruction unless the rl bit is also set. LR.rl and SC.aq
 instructions are not guaranteed to provide any stronger ordering
 than those with both bits clear, but may result in lower
 performance.

Also, I way of transforming ".rl + full barrier" to ".aqrl" was approved
by (the author of the RVWMO spec) [2]

[1] 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1391516953-14541-1-git-send-email-will.dea...@arm.com/
[2] 
https://lore.kernel.org/linux-riscv/41e01514-74ca-84f2-f5cc-2645c444f...@nvidia.com/

Signed-off-by: Bobby Eshleman 
Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - drop relaxed version of atomic ops as they are not used.
 - update the commit message
 - code style fixes
 - refactor functions write_atomic(), add_sized() to be able to use #ifdef 
CONFIG_RISCV_32 ... #endif
   for {write,read}q().
 - update ATOMIC_OPS to receive unary operator.
 - update the header on top of atomic-ops.h.
 - some minor movements of function inside atomic-ops.h header.
---
Changes in V6:
 - drop atomic##prefix##_{cmp}xchg_{release, aquire, relaxed} as they aren't 
used
   by Xen
 - code style fixes.
 - %s/__asm__ __volatile__/asm volatile
 - add explanational comments.
 - move inclusion of "#include " further down in 
atomic.h
   header.
---
Changes in V5:
 - fence.h changes were moved to separate patch as patches related to io.h and 
cmpxchg.h,
   which are dependecies for this patch, also needed changes in fence.h
 - remove accessing of zero-length array
 - drops cast in write_atomic()
 - drop introduction of WRITE_ONCE() and READ_ONCE().
 - drop defines similar to pattern #define atomic_add_return_relaxed   
atomic_add_return_relaxed
 - Xen code style fixes
 - move not RISC-V specific functions to asm-generic/atomics-ops.h
---
Changes in V4:
 - do changes related to the updates of [PATCH v3 13/34] xen/riscv: introduce 
cmpxchg.h
 - drop casts in read_atomic_size(), write_atomic(), add_sized()
 - tabs -> spaces
 - drop #ifdef CONFIG_SMP ... #endif in fence.ha as it is simpler to handle 
NR_CPUS=1
   the same as NR_CPUS>1 with accepting less than ideal performance.
---
Changes in V3:
  - update the commit message
  - add SPDX for fence.h
  - code style fixes
  - Remove /* TODO: ... */ for add_sized macros. It looks correct to me.
  - re-order the patch
  - merge to this patch fence.h
---
Changes in V2:
 - Change an author of commit. I got this header from Bobby's old repo.
---
 xen/arch/riscv/include/asm/atomic.h  | 261 +++
 xen/include/asm-generic/atomic-ops.h |  97 ++
 2 files changed, 358 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/atomic.h
 create mode 100644 xen/include/asm-generic/atomic-ops.h

diff --git a/xen/arch/riscv/include/asm/atomic.h 
b/xen/arch/riscv/include/asm/atomic.h
new file mode 100644
index 00..51574e7ce8
--- /dev/null
+++ b/xen/arch/riscv/include/asm/atomic.h
@@ -0,0 +1,261 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken and modified from Linux.
+ *
+ * The following changes were done:
+ * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
+ * to use__*xchg_generic()

[PATCH v7 15/19] xen/riscv: add minimal stuff to mm.h to build full Xen

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V7:
 - update argument type of maddr_to_virt() function: unsigned long -> paddr_t
 - rename argument of PFN_ORDER(): pfn -> pg.
 - add Acked-by: Jan Beulich 
---
Changes in V6:
 - drop __virt_to_maddr() ( transform to macro ) and __maddr_to_virt ( rename 
to maddr_to_virt ).
 - parenthesize va in definition of vmap_to_mfn().
 - Code style fixes. 
---
Changes in V5:
 - update the comment around "struct domain *domain;" : zero -> NULL
 - fix ident. for unsigned long val;
 - put page_to_virt() and virt_to_page() close to each other.
 - drop unnessary leading underscore
 - drop a space before the comment: /* Count of uses of this frame as its 
current type. */
 - drop comment about a page 'not as a shadow'. it is not necessary for RISC-V
---
Changes in V4:
 - update an argument name of PFN_ORDERN macros.
 - drop pad at the end of 'struct page_info'.
 - Change message -> subject in "Changes in V3"
 - delete duplicated macros from riscv/mm.h
 - fix identation in struct page_info
 - align comment for PGC_ macros
 - update definitions of domain_set_alloc_bitsize() and 
domain_clamp_alloc_bitsize()
 - drop unnessary comments.
 - s/BUG/BUG_ON("...")
 - define __virt_to_maddr, __maddr_to_virt as stubs
 - add inclusion of xen/mm-frame.h for mfn_x and others
 - include "xen/mm.h" instead of "asm/mm.h" to fix compilation issues:
 In file included from arch/riscv/setup.c:7:
./arch/riscv/include/asm/mm.h:60:28: error: field 'list' has incomplete 
type
   60 | struct page_list_entry list;
  |^~~~
./arch/riscv/include/asm/mm.h:81:43: error: 'MAX_ORDER' undeclared here 
(not in a function)
   81 | unsigned long first_dirty:MAX_ORDER + 1;
  |   ^
./arch/riscv/include/asm/mm.h:81:31: error: bit-field 'first_dirty' 
width not an integer constant
   81 | unsigned long first_dirty:MAX_ORDER + 1;
 - Define __virt_to_mfn() and __mfn_to_virt() using maddr_to_mfn() and 
mfn_to_maddr().
---
Changes in V3:
 - update the commit title
 - introduce DIRECTMAP_VIRT_START.
 - drop changes related pfn_to_paddr() and paddr_to_pfn as they were remvoe in
   [PATCH v2 32/39] xen/riscv: add minimal stuff to asm/page.h to build full Xen
 - code style fixes.
 - drop get_page_nr  and put_page_nr as they don't need for time being
 - drop CONFIG_STATIC_MEMORY related things
 - code style fixes
---
Changes in V2:
 - define stub for arch_get_dma_bitsize(void)
---
 xen/arch/riscv/include/asm/mm.h | 240 
 xen/arch/riscv/mm.c |   2 +-
 xen/arch/riscv/setup.c  |   2 +-
 3 files changed, 242 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 07c7a0abba..cc4a07a71c 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -3,11 +3,246 @@
 #ifndef _ASM_RISCV_MM_H
 #define _ASM_RISCV_MM_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 
+#define paddr_to_pdx(pa)mfn_to_pdx(maddr_to_mfn(pa))
+#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
+#define gaddr_to_gfn(ga)_gfn(paddr_to_pfn(ga))
+#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
+#define maddr_to_mfn(ma)_mfn(paddr_to_pfn(ma))
+#define vmap_to_mfn(va) maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
+#define vmap_to_page(va)mfn_to_page(vmap_to_mfn(va))
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+BUG_ON("unimplemented");
+return NULL;
+}
+
+#define virt_to_maddr(va) ({ BUG_ON("unimplemented"); 0; })
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define __virt_to_mfn(va)  mfn_x(maddr_to_mfn(virt_to_maddr(va)))
+#define __mfn_to_virt(mfn) maddr_to_virt(mfn_to_maddr(_mfn(mfn)))
+
+/*
+ * We define non-underscored wrappers for above conversion functions.
+ * These are overriden in various source files while underscored version
+ * remain intact.
+ */
+#define virt_to_mfn(va) __virt_to_mfn(va)
+#define mfn_to_virt(mfn)__mfn_to_virt(mfn)
+
+struct page_info
+{
+/* Each frame can be threaded onto a doubly-linked list. */
+struct page_list_entry list;
+
+/* Reference count and various PGC_xxx flags and fields. */
+unsigned long count_info;
+
+/* Context-dependent fields follow... */
+union {
+/* Page is in use: ((count_info & PGC_count_mask) != 0). */
+struct {
+/* Type reference count and various PGT_xxx flags and fields. */
+unsigned long type_info;
+} inuse;
+
+/* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+union {
+struct {
+/*
+ * 

[PATCH v7 09/19] xen/riscv: introduce io.h

[Oleksii Kurochko]

The header taken form Linux 6.4.0-rc1 and is based on
arch/riscv/include/asm/mmio.h with the following changes:
- drop forcing of endianess for read*(), write*() functions as
  no matter what CPU endianness, what endianness a particular device
  (and hence its MMIO region(s)) is using is entirely independent.
  Hence conversion, where necessary, needs to occur at a layer up.
  Another one reason to drop endianess conversion here is:
  
https://patchwork.kernel.org/project/linux-riscv/patch/2019045623.5749-3-...@lst.de/
  One of the answers of the author of the commit:
And we don't know if Linux will be around if that ever changes.
The point is:
 a) the current RISC-V spec is LE only
 b) the current linux port is LE only except for this little bit
There is no point in leaving just this bitrotting code around.  It
just confuses developers, (very very slightly) slows down compiles
and will bitrot.  It also won't be any significant help to a future
developer down the road doing a hypothetical BE RISC-V Linux port.
- drop unused argument of __io_ar() macros.
- drop "#define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}"
  as they are unnecessary.
- Adopt the Xen code style for this header, considering that significant changes
  are not anticipated in the future.
  In the event of any issues, adapting them to Xen style should be easily
  manageable.
- drop unnecessary  __r variables in macros read*_cpu()
- update inline assembler constraints for addr argument for
  __raw_read{b,w,l,q} and __raw_write{b,w,l,q} to tell a compiler that
 *addr will be accessed.
- add stubs for __raw_readq() and __raw_writeq() for RISCV_32

Addionally, to the header was added definions of ioremap_*().

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - update the comment message in riscv/io.h at the top.
 - code style fixes.
 - back const in places where it should be.
---
Changes in V6:
 - drop unnecessary spaces and fix typos in the file comment.
 - s/CONFIG_64BIT/CONFIG_RISCV_32 as .d suffix for instruction doesn't exist 
for RV32.
 - add stubs for __raw_readq() and __raw_writeq() for RISCV_32
 - update inline assembler constraints for addr argument for 
__raw_read{b,w,l,q} and
   __raw_write{b,w,l,q} to tell compiler that *addr will be accessed.
 - s/u8/uint8_t
 - update the commit message
---
Changes in V5:
 - Xen code style related fixes
 - drop #define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q}
 - drop cpu_to_le16()
 - remove unuused argument in _io_ar()
 - update the commit message 
 - drop unnessary __r variables in macros read*_cpu()
 - update the comments at the top of the header.
---
Changes in V4:
 - delete inner parentheses in macros.
 - s/u/uint.
---
Changes in V3:
 - re-sync with linux kernel
 - update the commit message
---
Changes in V2:
 - Nothing changed. Only rebase.
---
 xen/arch/riscv/include/asm/io.h | 168 
 1 file changed, 168 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/io.h

diff --git a/xen/arch/riscv/include/asm/io.h b/xen/arch/riscv/include/asm/io.h
new file mode 100644
index 00..8d9535e973
--- /dev/null
+++ b/xen/arch/riscv/include/asm/io.h
@@ -0,0 +1,168 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *  The header taken form Linux 6.4.0-rc1 and is based on
+ *  arch/riscv/include/asm/mmio.h with the following changes:
+ *   - drop forcing of endianess for read*(), write*() functions as
+ * no matter what CPU endianness, what endianness a particular device
+ * (and hence its MMIO region(s)) is using is entirely independent.
+ * Hence conversion, where necessary, needs to occur at a layer up.
+ * Another one reason to drop endianess conversion is:
+ * 
https://patchwork.kernel.org/project/linux-riscv/patch/2019045623.5749-3-...@lst.de/
+ * One of the answers of the author of the commit:
+ *   And we don't know if Linux will be around if that ever changes.
+ *   The point is:
+ *a) the current RISC-V spec is LE only
+ *b) the current linux port is LE only except for this little bit
+ *   There is no point in leaving just this bitrotting code around.  It
+ *   just confuses developers, (very very slightly) slows down compiles
+ *  and will bitrot.  It also won't be any significant help to a future
+ *   developer down the road doing a hypothetical BE RISC-V Linux port.
+ *   - drop unused argument of __io_ar() macros.
+ *   - drop "#define _raw_{read,write}{b,w,l,q} _raw_{read,write}{b,w,l,q}"
+ * as they are unnecessary.
+ *   - Adopt the Xen code style for this header, considering that significant
+ * changes are not anticipated in the future.
+ * In the event of any issues, adapting them to Xen style should be easily
+ * manageable.
+ *   - drop unnecessary __r variables in macros read*_cpu()
+ *   - update inline assembler constraints for addr argument for
+ * __raw_read{b,w,l,q} and 

[PATCH v7 07/19] xen/riscv: introduce bitops.h

[Oleksii Kurochko]

Taken from Linux-6.4.0-rc1

Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
  * The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
  * The following functions were renamed in the way how they are
used by common code:
* __test_and_set_bit
* __test_and_clear_bit
  * The declaration and implementation of the following functios
were updated to make Xen build happy:
* clear_bit
* set_bit
* __test_and_clear_bit
* __test_and_set_bit
  * linux/include/asm-generic/bitops/generic-non-atomic.h with the
following changes:
 * Only functions that can be reused in Xen were left;
   others were removed.
 * it was updated the message inside #ifndef ... #endif.
 * __always_inline -> always_inline to be align with definition in
   xen/compiler.h.
 * convert identations from tabs to spaces.
 * inside generic__test_and_* use 'bitops_uint_t' instead of 'unsigned long'
to be generic.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - Update the commit message.
 - Drop "__" for __op_bit and __op_bit_ord as they are atomic.
 - add comment above __set_bit and __clear_bit about why they are defined as 
atomic.
 - align bitops_uint_t with __AMO().
 - make changes after  generic non-atomic test_*bit() were changed.
 - s/__asm__ __volatile__/asm volatile
---
Changes in V6:
 - rebase clean ups were done: drop unused asm-generic includes
---
 Changes in V5:
   - new patch
---
 xen/arch/riscv/include/asm/bitops.h | 146 
 1 file changed, 146 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/bitops.h

diff --git a/xen/arch/riscv/include/asm/bitops.h 
b/xen/arch/riscv/include/asm/bitops.h
new file mode 100644
index 00..6f0212e5ac
--- /dev/null
+++ b/xen/arch/riscv/include/asm/bitops.h
@@ -0,0 +1,146 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2012 Regents of the University of California */
+
+#ifndef _ASM_RISCV_BITOPS_H
+#define _ASM_RISCV_BITOPS_H
+
+#include 
+
+#undef BITOP_BITS_PER_WORD
+#undef bitop_uint_t
+
+#define BITOP_BITS_PER_WORD BITS_PER_LONG
+#define bitop_uint_t unsigned long
+
+#if BITS_PER_LONG == 64
+#define __AMO(op)   "amo" #op ".d"
+#elif BITS_PER_LONG == 32
+#define __AMO(op)   "amo" #op ".w"
+#else
+#error "Unexpected BITS_PER_LONG"
+#endif
+
+#define __set_bit(n, p)  set_bit(n, p)
+#define __clear_bit(n, p)clear_bit(n, p)
+
+/* Based on linux/arch/include/asm/bitops.h */
+
+/*
+ * Non-atomic bit manipulation.
+ *
+ * Implemented using atomics to be interrupt safe. Could alternatively
+ * implement with local interrupt masking.
+ */
+#define __set_bit(n, p)  set_bit(n, p)
+#define __clear_bit(n, p)clear_bit(n, p)
+
+/* Based on linux/arch/include/asm/bitops.h */
+
+#define test_and_op_bit_ord(op, mod, nr, addr, ord) \
+({  \
+unsigned long res, mask;\
+mask = BITOP_MASK(nr);  \
+asm volatile (   \
+__AMO(op) #ord " %0, %2, %1"\
+: "=r" (res), "+A" (addr[BITOP_WORD(nr)])   \
+: "r" (mod(mask))   \
+: "memory");\
+((res & mask) != 0);\
+})
+
+#define op_bit_ord(op, mod, nr, addr, ord)  \
+asm volatile (  \
+__AMO(op) #ord " zero, %1, %0"  \
+: "+A" (addr[BITOP_WORD(nr)])   \
+: "r" (mod(BITOP_MASK(nr))) \
+: "memory");
+
+#define test_and_op_bit(op, mod, nr, addr)\
+test_and_op_bit_ord(op, mod, nr, addr, .aqrl)
+#define op_bit(op, mod, nr, addr) \
+op_bit_ord(op, mod, nr, addr, )
+
+/* Bitmask modifiers */
+#define NOP(x)(x)
+#define NOT(x)(~(x))
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ */
+static inline int test_and_set_bit(int nr, volatile void *p)
+{
+volatile bitop_uint_t *addr = p;
+
+return test_and_op_bit(or, NOP, nr, addr);
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ */
+static inline int test_and_clear_bit(int nr, volatile void *p)
+{
+volatile bitop_uint_t *addr = p;
+
+return test_and_op_bit(and, NOT, nr, addr);
+}
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void set_bit(int nr, volatile void *p)
+{
+volatile bitop_uint_t *addr = p;
+
+op_bit(or, NOP, nr, addr);
+}

[PATCH v7 00/19] Enable build of full Xen for RISC-V

[Oleksii Kurochko]

This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.

The patch series is based on the following patch series:
- [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs() [1]
- [PATCH] move __read_mostly to xen/cache.h  [2]
- [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [3]


Right now, the patch series doesn't have a direct dependency on [2] and it
provides __read_mostly in the patch:
[PATCH v3 26/34] xen/riscv: add definition of __read_mostly
However, it will be dropped as soon as [2] is merged or at least when the
final version of the patch [2] is provided.

[1] 
https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.coop...@citrix.com/T/#t
[2] 
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
[3] 
https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.1706259490.git.federico.seraf...@bugseng.com/

---
Changes in V7:
 - Patch was merged to staging:
   [PATCH v6 15/20] xen/riscv: add minimal stuff to processor.h to build full 
Xen.
 - Other changes are specific to specific patches. Please look at changes for
   specific patch.
---
Changes in V6:
 - Update the cover letter message: drop already merged dependecies and add
   a new one.
 - Patches were merged to staging:
   - [PATCH v5 02/23] xen/riscv: use some asm-generic headers ( even v4 was
 merged to staging branch, I just wasn't apply changes on top of the latest 
staging branch )
   - [PATCH v5 03/23] xen/riscv: introduce nospec.h
   - [PATCH v5 10/23] xen/riscv: introduces acrquire, release and full barriers
 - Introduce new patches:
   - xen/riscv: introduce extenstion support check by compiler
   - xen/bitops: put __ffs() and ffz() into linux compatible header
   - xen/bitops: implement fls{l}() in common logic
 - The following patches were dropped:
   - drop some patches related to bitops operations as they were introduced in 
another
 patch series [...]
   - introduce new version for generic __ffs(), ffz() and fls{l}().
 - Merge patch from patch series "[PATCH v9 0/7]  Introduce generic headers" to 
this patch
   series as only one patch left in the generic headers patch series and it is 
more about
   RISC-V.
 - Other changes are specific to specific patches. please look at specific 
patch.
---
Changes in V5:
 - Update the cover letter as one of the dependencies were merged to staging.
 - Was introduced asm-generic for atomic ops and separate patches for 
asm-generic bit ops
 - Moved fence.h to separate patch to deal with some patches dependecies on 
fence.h
 - Patches were dropped as they were merged to staging:
   * [PATCH v4 03/30] xen: add support in public/hvm/save.h for PPC and RISC-V
   * [PATCH v4 04/30] xen/riscv: introduce cpufeature.h
   * [PATCH v4 05/30] xen/riscv: introduce guest_atomics.h
   * [PATCH v4 06/30] xen: avoid generation of empty asm/iommu.h
   * [PATCH v4 08/30] xen/riscv: introduce setup.h
   * [PATCH v4 10/30] xen/riscv: introduce flushtlb.h
   * [PATCH v4 11/30] xen/riscv: introduce smp.h
   * [PATCH v4 15/30] xen/riscv: introduce irq.h
   * [PATCH v4 16/30] xen/riscv: introduce p2m.h
   * [PATCH v4 17/30] xen/riscv: introduce regs.h
   * [PATCH v4 18/30] xen/riscv: introduce time.h
   * [PATCH v4 19/30] xen/riscv: introduce event.h
   * [PATCH v4 22/30] xen/riscv: define an address of frame table
 - Other changes are specific to specific patches. please look at specific patch
---
Changes in V4:
 - Update the cover letter message: new patch series dependencies.
 - Some patches were merged to staging, so they were dropped in this patch 
series:
 [PATCH v3 09/34] xen/riscv: introduce system.h
 [PATCH v3 18/34] xen/riscv: introduce domain.h
 [PATCH v3 19/34] xen/riscv: introduce guest_access.h
 - Was sent out of this patch series:
 [PATCH v3 16/34] xen/lib: introduce generic find next bit operations
 - [PATCH v3 17/34] xen/riscv: add compilation of generic find-next-bit.c was
   droped as CONFIG_GENERIC_FIND_NEXT_BIT was dropped.
 - All other changes are specific to a specific patch.
---
Changes in V3:
 - Update the cover letter message
 - The following patches were dropped as they were merged to staging:
[PATCH v2 03/39] xen/riscv:introduce asm/byteorder.h
[PATCH v2 04/39] xen/riscv: add public arch-riscv.h
[PATCH v2 05/39] xen/riscv: introduce spinlock.h
[PATCH v2 20/39] xen/riscv: define bug frame tables in xen.lds.S
[PATCH v2 34/39] xen: add RISCV support for pmu.h
[PATCH v2 35/39] xen: add necessary headers to common to build full Xen for 
RISC-V
 - Instead of the following patches were introduced new:
[PATCH v2 10/39] xen/riscv: introduce asm/iommu.h
[PATCH v2 11/39] xen/riscv: introduce asm/nospec.h
 - remove "asm/"  for commit messages which start with 

[PATCH v7 04/19] xen: introduce generic non-atomic test_*bit()

[Oleksii Kurochko]

The patch introduces the following generic functions:
* test_bit
* generic__test_and_set_bit
* generic__test_and_clear_bit
* generic__test_and_change_bit

Also, the patch introduces the following generics which are
used by the functions mentioned above:
* BITOP_BITS_PER_WORD
* BITOP_MASK
* BITOP_WORD
* BITOP_TYPE

These functions and macros can be useful for architectures
that don't have corresponding arch-specific instructions.

Because of that x86 has the following check in the macros test_bit(),
__test_and_set_bit(), __test_and_clear_bit(), __test_and_change_bit():
if ( bitop_bad_size(addr) ) __bitop_bad_size();
It was necessary to move the check to generic code and define as 0
for other architectures as they do not require this check.

Signed-off-by: Oleksii Kurochko 
---
 Changes in V7:
  - move everything to xen/bitops.h to follow the same approach for all generic
bit ops.
  - put together BITOP_BITS_PER_WORD and bitops_uint_t.
  - make BITOP_MASK more generic.
  - drop #ifdef ... #endif around BITOP_MASK, BITOP_WORD as they are generic
enough.
  - drop "_" for generic__{test_and_set_bit,...}().
  - drop " != 0" for functions which return bool.
  - add volatile during the cast for generic__{...}().
  - update the commit message.
  - update arch related code to follow the proposed generic approach.
---
 Changes in V6:
  - Nothing changed ( only rebase )
---
 Changes in V5:
   - new patch
---
 xen/arch/arm/arm64/livepatch.c|   1 -
 xen/arch/arm/include/asm/bitops.h |  67 -
 xen/arch/ppc/include/asm/bitops.h |  64 -
 xen/arch/ppc/include/asm/page.h   |   2 +-
 xen/arch/ppc/mm-radix.c   |   2 +-
 xen/arch/x86/include/asm/bitops.h |  28 ++
 xen/include/xen/bitops.h  | 154 ++
 7 files changed, 165 insertions(+), 153 deletions(-)

diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index df2cebedde..4bc8ed9be5 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/include/asm/bitops.h 
b/xen/arch/arm/include/asm/bitops.h
index 5104334e48..8e16335e76 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -22,9 +22,6 @@
 #define __set_bit(n,p)set_bit(n,p)
 #define __clear_bit(n,p)  clear_bit(n,p)
 
-#define BITOP_BITS_PER_WORD 32
-#define BITOP_MASK(nr)  (1UL << ((nr) % BITOP_BITS_PER_WORD))
-#define BITOP_WORD(nr)  ((nr) / BITOP_BITS_PER_WORD)
 #define BITS_PER_BYTE   8
 
 #define ADDR (*(volatile int *) addr)
@@ -76,70 +73,6 @@ bool test_and_change_bit_timeout(int nr, volatile void *p,
 bool clear_mask16_timeout(uint16_t mask, volatile void *p,
   unsigned int max_try);
 
-/**
- * __test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is non-atomic and can be reordered.
- * If two examples of this operation race, one can appear to succeed
- * but actually fail.  You must protect multiple accesses with a lock.
- */
-static inline int __test_and_set_bit(int nr, volatile void *addr)
-{
-unsigned int mask = BITOP_MASK(nr);
-volatile unsigned int *p =
-((volatile unsigned int *)addr) + BITOP_WORD(nr);
-unsigned int old = *p;
-
-*p = old | mask;
-return (old & mask) != 0;
-}
-
-/**
- * __test_and_clear_bit - Clear a bit and return its old value
- * @nr: Bit to clear
- * @addr: Address to count from
- *
- * This operation is non-atomic and can be reordered.
- * If two examples of this operation race, one can appear to succeed
- * but actually fail.  You must protect multiple accesses with a lock.
- */
-static inline int __test_and_clear_bit(int nr, volatile void *addr)
-{
-unsigned int mask = BITOP_MASK(nr);
-volatile unsigned int *p =
-((volatile unsigned int *)addr) + BITOP_WORD(nr);
-unsigned int old = *p;
-
-*p = old & ~mask;
-return (old & mask) != 0;
-}
-
-/* WARNING: non atomic and it can be reordered! */
-static inline int __test_and_change_bit(int nr,
-volatile void *addr)
-{
-unsigned int mask = BITOP_MASK(nr);
-volatile unsigned int *p =
-((volatile unsigned int *)addr) + BITOP_WORD(nr);
-unsigned int old = *p;
-
-*p = old ^ mask;
-return (old & mask) != 0;
-}
-
-/**
- * test_bit - Determine whether a bit is set
- * @nr: bit number to test
- * @addr: Address to start counting from
- */
-static inline int test_bit(int nr, const volatile void *addr)
-{
-const volatile unsigned int *p = (const volatile unsigned int *)addr;
-return 1UL & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_PER_WORD-1)));
-}
-
 /*
  * On ARMv5 and above those functions can be 

[PATCH v7 03/19] xen/riscv: introduce extenstion support check by compiler

[Oleksii Kurochko]

Currently, RISC-V requires two extensions: _zbb and _zihintpause.

This patch introduces a compiler check to check if these extensions
are supported.
Additionally, it introduces the riscv/booting.txt file, which contains
information about the extensions that should be supported by the platform.

In the future, a feature will be introduced to check whether an extension
is supported at runtime.
However, this feature requires functionality for parsing device tree
source (DTS), which is not yet available.

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - add variables for each extension separately.
 - create variable for abi and compilation flags to not repeat the same in 
several
   places.
 - update architectures to use generic implementations
---
Changes in V6:
 - new patch for this patch series
---
 docs/misc/riscv/booting.txt | 16 
 xen/arch/riscv/arch.mk  | 15 +--
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 docs/misc/riscv/booting.txt

diff --git a/docs/misc/riscv/booting.txt b/docs/misc/riscv/booting.txt
new file mode 100644
index 00..cb4d79f12c
--- /dev/null
+++ b/docs/misc/riscv/booting.txt
@@ -0,0 +1,16 @@
+System requirements
+===
+
+The following extensions are expected to be supported by a system on which
+Xen is run:
+- Zbb:
+  RISC-V doesn't have a CLZ instruction in the base ISA.
+  As a consequence, __builtin_ffs() emits a library call to ffs() on GCC,
+  or a de Bruijn sequence on Clang.
+  Zbb extension adds a CLZ instruction, after which __builtin_ffs() emits
+  a very simple sequence.
+  The similar issue occurs with other __builtin_, so it is needed to
+  provide a generic version of bitops in RISC-V bitops.h
+- Zihintpause:
+  On a system that doesn't have this extension, cpu_relax() should be
+  implemented properly.
diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk
index 8403f96b6f..24a7461bcc 100644
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -3,16 +3,27 @@
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS-$(CONFIG_RISCV_64) += -mabi=lp64
+riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
+riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64
 
 riscv-march-$(CONFIG_RISCV_ISA_RV64G) := rv64g
 riscv-march-$(CONFIG_RISCV_ISA_C)   := $(riscv-march-y)c
 
+riscv-generic-flags := $(riscv-abi-y) -march=$(riscv-march-y)
+
+zbb := $(call as-insn,$(CC) $(riscv-generic-flags)_zbb,"",_zbb)
+zihintpause := $(call as-insn,\
+   $(CC) $(riscv-generic-flags)_zihintpause,"pause",_zihintpause)
+
+extensions := $(zbb) $(zihintpause)
+
+extensions := $(subst $(space),,$(extensions))
+
 # Note that -mcmodel=medany is used so that Xen can be mapped
 # into the upper half _or_ the lower half of the address space.
 # -mcmodel=medlow would force Xen into the lower half.
 
-CFLAGS += -march=$(riscv-march-y) -mstrict-align -mcmodel=medany
+CFLAGS += $(riscv-generic-flags)$(extensions) -mstrict-align -mcmodel=medany
 
 # TODO: Drop override when more of the build is working
 override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
-- 
2.43.0

[PATCH v7 06/19] xen/bitops: put __ffs() into linux compatible header

[Oleksii Kurochko]

The mentioned macros exist only because of Linux compatible purpose.

The patch defines __ffs() in terms of Xen bitops and it is safe
to define in this way ( as __ffs() - 1 ) as considering that __ffs()
was defined as __builtin_ctzl(x), which has undefined behavior when x=0,
so it is assumed that such cases are not encountered in the current code.

To not include  to Xen library files __ffs() and __ffz()
were defined locally in find-next-bit.c.

Except __ffs() usage in find-next-bit.c only one usage of __ffs() leave
in smmu-v3.c. It seems that it __ffs can be changed to ffsl(x)-1 in
this file, but to keep smmu-v3.c looks close to linux it was deciced just
to define __ffs() in xen/linux-compat.h and include it in smmu-v3.c

Signed-off-by: Oleksii Kurochko 
---
Changes in V7:
 - introduce ffz(),__ffs() locally in find-next-bit.c
 - drop inclusion of  in find-next-bit.c.
 - update the commit message.
---
Changes in V6:
 - new patch for the patch series.
---
 xen/arch/arm/include/asm/arm64/bitops.h | 21 -
 xen/arch/ppc/include/asm/bitops.h   | 12 
 xen/drivers/passthrough/arm/smmu-v3.c   |  2 ++
 xen/include/xen/linux-compat.h  |  2 ++
 xen/lib/find-next-bit.c |  3 +++
 5 files changed, 7 insertions(+), 33 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/bitops.h 
b/xen/arch/arm/include/asm/arm64/bitops.h
index 5f5d97faa0..2deb134388 100644
--- a/xen/arch/arm/include/asm/arm64/bitops.h
+++ b/xen/arch/arm/include/asm/arm64/bitops.h
@@ -1,27 +1,6 @@
 #ifndef _ARM_ARM64_BITOPS_H
 #define _ARM_ARM64_BITOPS_H
 
-/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static /*__*/always_inline unsigned long __ffs(unsigned long word)
-{
-return __builtin_ctzl(word);
-}
-
-/* Based on linux/include/asm-generic/bitops/ffz.h */
-/*
- * ffz - find first zero in word.
- * @word: The word to search
- *
- * Undefined if no zero exists, so code should check against ~0UL first.
- */
-#define ffz(x)  __ffs(~(x))
-
 static inline int arch_flsl(unsigned long x)
 {
 uint64_t ret;
diff --git a/xen/arch/ppc/include/asm/bitops.h 
b/xen/arch/ppc/include/asm/bitops.h
index a17060c7c2..2237b9f8f4 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -130,16 +130,4 @@ static inline int test_and_set_bit(unsigned int nr, 
volatile void *addr)
 #define hweight16(x) __builtin_popcount((uint16_t)(x))
 #define hweight8(x)  __builtin_popcount((uint8_t)(x))
 
-/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static always_inline unsigned long __ffs(unsigned long word)
-{
-return __builtin_ctzl(word);
-}
-
 #endif /* _ASM_PPC_BITOPS_H */
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index b1c40c2c0a..6904962467 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -72,12 +72,14 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/linux-compat.h b/xen/include/xen/linux-compat.h
index 62ba71485c..10db80df57 100644
--- a/xen/include/xen/linux-compat.h
+++ b/xen/include/xen/linux-compat.h
@@ -19,4 +19,6 @@ typedef int64_t __s64;
 
 typedef paddr_t phys_addr_t;
 
+#define __ffs(x) (ffsl(x) - 1)
+
 #endif /* __XEN_LINUX_COMPAT_H__ */
diff --git a/xen/lib/find-next-bit.c b/xen/lib/find-next-bit.c
index ca6f82277e..761b027398 100644
--- a/xen/lib/find-next-bit.c
+++ b/xen/lib/find-next-bit.c
@@ -12,6 +12,9 @@
 
 #include 
 
+#define __ffs(x) (ffsl(x) - 1)
+#define ffz(x) __ffs(~(x))
+
 #ifndef find_next_bit
 /*
  * Find the next set bit in a memory region.
-- 
2.43.0

[PATCH v7 01/19] automation: introduce fixed randconfig for RISC-V

[Oleksii Kurochko]

This patch introduces the anchor riscv-fixed-randconfig,
which includes all configurations that should be disabled for
randconfig builds.

Suggested-by: Stefano Stabellini 
Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 
Acked-by: Stefano Stabellini 
---
Changes in V7:
 - Nothing changed. Only rebase.
---
Changes in V6:
 - new patch for this patch series
 - Reviewed-by and Acked-by was added. ( in another patch series they were
   recieved. )
---
 automation/gitlab-ci/build.yaml | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 6d2cb18b88..aac29ee13a 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -512,6 +512,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
   CONFIG_BOOT_TIME_CPUPOOLS=y
 
 # RISC-V 64 cross-build
+.riscv-fixed-randconfig:
+  variables: 
+EXTRA_FIXED_RANDCONFIG: |
+  CONFIG_COVERAGE=n
+  CONFIG_EXPERT=y
+  CONFIG_GRANT_TABLE=n
+  CONFIG_MEM_ACCESS=n
+
 archlinux-current-gcc-riscv64:
   extends: .gcc-riscv64-cross-build
   variables:
@@ -532,8 +540,7 @@ archlinux-current-gcc-riscv64-randconfig:
 CONTAINER: archlinux:current-riscv64
 KBUILD_DEFCONFIG: tiny64_defconfig
 RANDCONFIG: y
-EXTRA_FIXED_RANDCONFIG:
-  CONFIG_COVERAGE=n
+<<: *riscv-fixed-randconfig
 
 archlinux-current-gcc-riscv64-debug-randconfig:
   extends: .gcc-riscv64-cross-build-debug
@@ -541,8 +548,7 @@ archlinux-current-gcc-riscv64-debug-randconfig:
 CONTAINER: archlinux:current-riscv64
 KBUILD_DEFCONFIG: tiny64_defconfig
 RANDCONFIG: y
-EXTRA_FIXED_RANDCONFIG:
-  CONFIG_COVERAGE=n
+<<: *riscv-fixed-randconfig
 
 # Power cross-build
 debian-bullseye-gcc-ppc64le:
-- 
2.43.0

Re: [PATCH 1/2] xen/arm: Add i.MX UART early printk support

[Michal Orzel]

Hi Oleksandr,

On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> Tested on i.MX 8M Mini only, but I guess, it should be
> suitable for other i.MX8M* SoCs (those UART device tree nodes
> contain "fsl,imx6q-uart" compatible string).
Please use imperative mood in commit msg. I would mention also that you are 
adding
macros that will be used by the runtime driver.

> 
> Signed-off-by: Oleksandr Tyshchenko 
> ---
> I selected the following configs for enabling early printk:
> 
>  CONFIG_EARLY_UART_CHOICE_IMX_UART=y
>  CONFIG_EARLY_UART_IMX_UART=y
>  CONFIG_EARLY_PRINTK=y
>  CONFIG_EARLY_UART_BASE_ADDRESS=0x3089
>  CONFIG_EARLY_PRINTK_INC="debug-imx-uart.inc"
> ---
> ---
>  xen/arch/arm/Kconfig.debug| 14 +
>  xen/arch/arm/arm64/debug-imx-uart.inc | 38 ++
>  xen/arch/arm/include/asm/imx-uart.h   | 76 +++
>  3 files changed, 128 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
> 
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> index eec860e88e..a15d08f214 100644
> --- a/xen/arch/arm/Kconfig.debug
> +++ b/xen/arch/arm/Kconfig.debug
> @@ -68,6 +68,16 @@ choice
> provide the parameters for the i.MX LPUART rather than
> selecting one of the platform specific options below 
> if
> you know the parameters for the port.
> +   config EARLY_UART_CHOICE_IMX_UART
> +   select EARLY_UART_IMX_UART
> +   depends on ARM_64
> +   bool "Early printk via i.MX UART"
> +   help
> +   Say Y here if you wish the early printk to direct 
> their
Do not take example from surrounding code. help text should be indented by 2 
tabs and 2 spaces here.

> +   output to a i.MX UART. You can use this option to
> +   provide the parameters for the i.MX UART rather than
> +   selecting one of the platform specific options below 
> if
> +   you know the parameters for the port.
> config EARLY_UART_CHOICE_MESON
> select EARLY_UART_MESON
> depends on ARM_64
> @@ -199,6 +209,9 @@ config EARLY_UART_EXYNOS4210
>  config EARLY_UART_IMX_LPUART
> select EARLY_PRINTK
> bool
> +config EARLY_UART_IMX_UART
> +   select EARLY_PRINTK
> +   bool
>  config EARLY_UART_MESON
> select EARLY_PRINTK
> bool
> @@ -304,6 +317,7 @@ config EARLY_PRINTK_INC
> default "debug-cadence.inc" if EARLY_UART_CADENCE
> default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
> default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
> +   default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
> default "debug-meson.inc" if EARLY_UART_MESON
> default "debug-mvebu.inc" if EARLY_UART_MVEBU
> default "debug-pl011.inc" if EARLY_UART_PL011
> diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc 
> b/xen/arch/arm/arm64/debug-imx-uart.inc
> new file mode 100644
> index 00..27a68b1ed5
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-imx-uart.inc
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * xen/arch/arm/arm64/debug-imx-uart.inc
> + *
> + * i.MX8M* specific debug code
> + *
> + * Copyright (C) 2024 EPAM Systems Inc.
> + */
> +
> +#include 
> +
> +/*
> + * Wait UART to be ready to transmit
> + * rb: register which contains the UART base address
> + * rc: scratch register
> + */
> +.macro early_uart_ready xb, c
> +1:
> +ldr   w\c, [\xb, #IMX21_UTS] /* <- Test register */
> +tst   w\c, #UTS_TXFULL   /* Check TxFIFO FULL bit */
> +bne   1b /* Wait for the UART to be ready */
> +.endm
> +
> +/*
> + * UART transmit character
> + * rb: register which contains the UART base address
> + * rt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb, wt
> +str   \wt, [\xb, #URTX0] /* -> Transmitter Register */
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/include/asm/imx-uart.h 
> b/xen/arch/arm/include/asm/imx-uart.h
> new file mode 100644
> index 00..413a81dd44
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/imx-uart.h
> @@ -0,0 +1,76 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * xen/arch/arm/include/asm/imx-uart.h
> + *
> + * Common constant definition between early printk and the UART driver
> + *
> + * Copyright (C) 2024 EPAM Systems Inc.
> + */
> +
> +#ifndef __ASM_ARM_IMX_UART_H__
> +#define __ASM_ARM_IMX_UART_H__
> +
> +/* 32-bit register definition */
> +#define URXD0(0x00) /* Receiver Register */
There is no need to surround these values

> +#define URTX0(0x40) /* Transmitter Register */
> 

[PATCH v3 2/4] xen/arm: Generalize the extended region finding logic

[Henry Wang]

Recently there are needs to find unallocated/used memory regions
for different use cases at boot time, and the logic of finding
extended regions can be reused for some of the new use cases.

This commit therefore generalize the extended region finding logic.
Firstly, extract the extended region finding logic to a dedicated
helper find_unused_regions(). Then add and pass down a `min_region_size`
parameter so that the helpers can take a flexible region size
instead of the hardcoded 64MB for extended region. Finally, adjust
the variable and function names to make them general instead of for
extended region only.

Take the opportunity to update the stale in-code comment of
find_unallocated_memory() and find_memory_holes().

Signed-off-by: Henry Wang 
---
v3:
- New patch
---
 xen/arch/arm/domain_build.c | 107 ++--
 xen/arch/arm/include/asm/domain_build.h |   2 +
 xen/arch/arm/include/asm/setup.h|   5 ++
 3 files changed, 70 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 085d88671e..d2a9c047ea 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -814,19 +814,21 @@ int __init make_memory_node(const struct domain *d,
 return res;
 }
 
-static int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
-  void *data)
+static int __init add_regions(unsigned long s_gfn, unsigned long e_gfn,
+  void *data)
 {
-struct meminfo *ext_regions = data;
+struct mem_unused_info *unused = data;
+struct meminfo *regions = unused->regions;
+paddr_t min_region_size = unused->min_region_size;
 paddr_t start, size;
 paddr_t s = pfn_to_paddr(s_gfn);
 paddr_t e = pfn_to_paddr(e_gfn);
 
-if ( ext_regions->nr_banks >= ARRAY_SIZE(ext_regions->bank) )
+if ( regions->nr_banks >= ARRAY_SIZE(regions->bank) )
 return 0;
 
 /*
- * Both start and size of the extended region should be 2MB aligned to
+ * Both start and size of the region should be 2MB aligned to
  * potentially allow superpage mapping.
  */
 start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
@@ -845,26 +847,27 @@ static int __init add_ext_regions(unsigned long s_gfn, 
unsigned long e_gfn,
  * not quite useful but increase bookkeeping and not too large
  * to skip a large proportion of unused address space.
  */
-if ( size < MB(64) )
+if ( size < min_region_size )
 return 0;
 
-ext_regions->bank[ext_regions->nr_banks].start = start;
-ext_regions->bank[ext_regions->nr_banks].size = size;
-ext_regions->nr_banks++;
+regions->bank[regions->nr_banks].start = start;
+regions->bank[regions->nr_banks].size = size;
+regions->nr_banks++;
 
 return 0;
 }
 
 /*
- * Find unused regions of Host address space which can be exposed to Dom0
- * as extended regions for the special memory mappings. In order to calculate
- * regions we exclude every region assigned to Dom0 from the Host RAM:
+ * Find unused regions of Host address space which can be exposed to
+ * direct-mapped domains as regions for the special memory mappings.
+ * In order to calculate regions we exclude every region assigned to
+ * direct-mapped domains from the Host RAM:
  * - domain RAM
  * - reserved-memory
  * - grant table space
  */
 static int __init find_unallocated_memory(const struct kernel_info *kinfo,
-  struct meminfo *ext_regions)
+  struct mem_unused_info *unused)
 {
 const struct meminfo *assign_mem = >mem;
 struct rangeset *unalloc_mem;
@@ -893,7 +896,7 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 }
 }
 
-/* Remove RAM assigned to Dom0 */
+/* Remove RAM assigned to domain */
 for ( i = 0; i < assign_mem->nr_banks; i++ )
 {
 start = assign_mem->bank[i].start;
@@ -942,10 +945,10 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 start = 0;
 end = (1ULL << p2m_ipa_bits) - 1;
 res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
- add_ext_regions, ext_regions);
+ add_regions, unused);
 if ( res )
-ext_regions->nr_banks = 0;
-else if ( !ext_regions->nr_banks )
+unused->regions->nr_banks = 0;
+else if ( !unused->regions->nr_banks )
 res = -ENOENT;
 
 out:
@@ -982,16 +985,16 @@ static int __init handle_pci_range(const struct 
dt_device_node *dev,
 }
 
 /*
- * Find the holes in the Host DT which can be exposed to Dom0 as extended
- * regions for the special memory mappings. In order to calculate regions
- * we exclude every addressable memory region described by "reg" and "ranges"
+ * Find the holes in the Host DT which can be exposed to direct-mapped domains
+ * as regions for the special memory 

[PATCH v3 0/4] DOMCTL-based guest magic region allocation for 11 domUs

[Henry Wang]

An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```

This is because populate_physmap() automatically assumes gfn == mfn
for direct mapped domains. This cannot be true for the magic pages
that are allocated later for 1:1 Dom0less DomUs from the init-dom0less
helper application executed in Dom0. For domain using statically
allocated memory but not 1:1 direct-mapped, similar error "failed to
retrieve a reserved page" can be seen as the reserved memory list
is empty at that time.

This series tries to fix this issue using a DOMCTL-based approach,
because for 1:1 direct-mapped domUs, we need to avoid the RAM regions
and inform the toolstack about the region found by hypervisor for
mapping the magic pages. Patch 1 introduced a new DOMCTL to get the
guest memory map, currently only used for the magic page regions.
Patch 2 generalized the extended region finding logic so that it can
be reused for other use cases such as finding 1:1 domU magic regions.
Patch 3 uses the same approach as finding the extended regions to find
the guest magic page regions for direct-mapped DomUs. Patch 4 avoids
hardcoding all base addresses of guest magic region in the init-dom0less
application by consuming the newly introduced DOMCTL.

Gitlab pipeline for this series:
https://gitlab.com/xen-project/people/henryw/xen/-/pipelines/1238005196

Henry Wang (4):
  xen/domctl, tools: Introduce a new domctl to get guest memory map
  xen/arm: Generalize the extended region finding logic
  xen/arm: Find unallocated spaces for magic pages of direct-mapped domU
  xen/memory, tools: Avoid hardcoding GUEST_MAGIC_BASE in init-dom0less

 tools/helpers/init-dom0less.c|  36 +--
 tools/include/xenctrl.h  |   4 +
 tools/libs/ctrl/xc_domain.c  |  33 ++
 xen/arch/arm/dom0less-build.c|  11 ++
 xen/arch/arm/domain.c|  15 +++
 xen/arch/arm/domain_build.c  | 131 +++
 xen/arch/arm/domctl.c|  32 +-
 xen/arch/arm/include/asm/domain.h|   8 ++
 xen/arch/arm/include/asm/domain_build.h  |   4 +
 xen/arch/arm/include/asm/setup.h |   5 +
 xen/arch/arm/include/asm/static-memory.h |   7 ++
 xen/arch/arm/static-memory.c |  39 +++
 xen/common/memory.c  |  22 +++-
 xen/include/public/arch-arm.h|  11 ++
 xen/include/public/domctl.h  |  27 +
 xen/include/public/memory.h  |   5 +
 xen/include/xen/mm.h |   7 ++
 17 files changed, 339 insertions(+), 58 deletions(-)

-- 
2.34.1

[PATCH v3 4/4] xen/memory, tools: Avoid hardcoding GUEST_MAGIC_BASE in init-dom0less

[Henry Wang]

Currently the GUEST_MAGIC_BASE in the init-dom0less application is
hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less
DomUs.

Instead of hardcoding the guest magic pages region, use the
XEN_DOMCTL_get_mem_map domctl to get the start address of the guest
magic pages region. Add the (XEN)MEMF_force_heap_alloc memory
flags to force populate_physmap() to allocate page from domheap
instead of using 1:1 or static allocated pages to map the magic pages.

Reported-by: Alec Kwapis 
Signed-off-by: Henry Wang 
---
v3:
- Don't ignore the error from xc_get_domain_mem_map().
- Re-purposing the _MEMF_no_refcount as _MEMF_force_heap_alloc to
  avoid introduction of a new, single-use flag.
- Reject other reservation sub-ops to use the newly added flag.
- Replace all the GUEST_MAGIC_BASE usages.
v2:
- New patch
---
 tools/helpers/init-dom0less.c | 36 +--
 xen/common/memory.c   | 22 +++--
 xen/include/public/memory.h   |  5 +
 xen/include/xen/mm.h  |  7 +++
 4 files changed, 58 insertions(+), 12 deletions(-)

diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
index fee93459c4..8eec4d1f49 100644
--- a/tools/helpers/init-dom0less.c
+++ b/tools/helpers/init-dom0less.c
@@ -19,24 +19,43 @@
 #define XENSTORE_PFN_OFFSET 1
 #define STR_MAX_LENGTH 128
 
+static xen_pfn_t xs_page_base;
+static xen_pfn_t xs_page_p2m;
+
 static int alloc_xs_page(struct xc_interface_core *xch,
  libxl_dominfo *info,
  uint64_t *xenstore_pfn)
 {
-int rc;
-const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT;
-xen_pfn_t p2m = (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET;
+int rc, i;
+uint32_t nr_regions = XEN_MAX_MEM_REGIONS;
+struct xen_mem_region mem_regions[XEN_MAX_MEM_REGIONS] = {0};
+
+rc = xc_get_domain_mem_map(xch, info->domid, mem_regions, _regions);
+if (rc < 0)
+return rc;
+
+for ( i = 0; i < nr_regions; i++ )
+{
+if ( mem_regions[i].type == GUEST_MEM_REGION_MAGIC )
+{
+xs_page_base = mem_regions[i].start >> XC_PAGE_SHIFT;
+xs_page_p2m = (mem_regions[i].start >> XC_PAGE_SHIFT) +
+  XENSTORE_PFN_OFFSET;
+}
+}
 
 rc = xc_domain_setmaxmem(xch, info->domid,
  info->max_memkb + (XC_PAGE_SIZE/1024));
 if (rc < 0)
 return rc;
 
-rc = xc_domain_populate_physmap_exact(xch, info->domid, 1, 0, 0, );
+rc = xc_domain_populate_physmap_exact(xch, info->domid, 1, 0,
+  XENMEMF_force_heap_alloc,
+  _page_p2m);
 if (rc < 0)
 return rc;
 
-*xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+*xenstore_pfn = xs_page_base + XENSTORE_PFN_OFFSET;
 rc = xc_clear_domain_page(xch, info->domid, *xenstore_pfn);
 if (rc < 0)
 return rc;
@@ -145,8 +164,7 @@ static int create_xenstore(struct xs_handle *xsh,
 rc = snprintf(target_memkb_str, STR_MAX_LENGTH, "%"PRIu64, 
info->current_memkb);
 if (rc < 0 || rc >= STR_MAX_LENGTH)
 return rc;
-rc = snprintf(ring_ref_str, STR_MAX_LENGTH, "%lld",
-  (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET);
+rc = snprintf(ring_ref_str, STR_MAX_LENGTH, "%"PRIu_xen_pfn, xs_page_p2m);
 if (rc < 0 || rc >= STR_MAX_LENGTH)
 return rc;
 rc = snprintf(xenstore_port_str, STR_MAX_LENGTH, "%u", xenstore_port);
@@ -282,9 +300,7 @@ static int init_domain(struct xs_handle *xsh,
 if (rc)
 err(1, "writing to xenstore");
 
-rc = xs_introduce_domain(xsh, info->domid,
-(GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET,
-xenstore_evtchn);
+rc = xs_introduce_domain(xsh, info->domid, xs_page_p2m, xenstore_evtchn);
 if (!rc)
 err(1, "xs_introduce_domain");
 return 0;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b3b05c2ec0..4f8c665870 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -219,7 +219,8 @@ static void populate_physmap(struct memop_args *a)
 }
 else
 {
-if ( is_domain_direct_mapped(d) )
+if ( is_domain_direct_mapped(d) &&
+ !(a->memflags & MEMF_force_heap_alloc) )
 {
 mfn = _mfn(gpfn);
 
@@ -246,7 +247,8 @@ static void populate_physmap(struct memop_args *a)
 
 mfn = _mfn(gpfn);
 }
-else if ( is_domain_using_staticmem(d) )
+else if ( is_domain_using_staticmem(d) &&
+  !(a->memflags & MEMF_force_heap_alloc) )
 {
 /*
  * No easy way to guarantee the retrieved pages are contiguous,
@@ -271,6 +273,14 @@ static void populate_physmap(struct memop_args *a)
 }
 else
 {
+/*
+ * 

[PATCH v3 3/4] xen/arm: Find unallocated spaces for magic pages of direct-mapped domU

[Henry Wang]

For 1:1 direct-mapped dom0less DomUs, the magic pages should not clash
with any RAM region. To find a proper region for guest magic pages,
we can reuse the logic of finding domain extended regions.

If the extended region is enabled, since the extended region banks are
at least 64MB, carve out the first 16MB from the first extended region
bank for magic pages of direct-mapped domU. If the extended region is
disabled, call the newly introduced helper find_11_domU_magic_region()
to find a GUEST_MAGIC_SIZE sized unused region.

Reported-by: Alec Kwapis 
Signed-off-by: Henry Wang 
---
v3:
- Extract the logic of finding unallocated spaces for magic pages of
  direct-mapped domU to a dedicated function in static-memory.c
- Properly handle error and free memory in find_11_domU_magic_region()
v2:
- New patch
---
 xen/arch/arm/dom0less-build.c| 11 +++
 xen/arch/arm/domain_build.c  | 24 ++-
 xen/arch/arm/include/asm/domain_build.h  |  2 ++
 xen/arch/arm/include/asm/static-memory.h |  7 +
 xen/arch/arm/static-memory.c | 39 
 5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index fb63ec6fd1..1963f029fe 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -682,6 +682,17 @@ static int __init prepare_dtb_domU(struct domain *d, 
struct kernel_info *kinfo)
 
 if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
 {
+/*
+ * Find the guest magic region for 1:1 dom0less domU when the extended
+ * region is not enabled.
+ */
+if ( !opt_ext_regions || is_32bit_domain(d) )
+{
+ret = find_11_domU_magic_region(d, kinfo);
+if ( ret )
+goto err;
+}
+
 ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
 if ( ret )
 goto err;
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d2a9c047ea..a5d1ca7f73 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -46,7 +46,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
  * If true, the extended regions support is enabled for dom0 and
  * dom0less domUs.
  */
-static bool __initdata opt_ext_regions = true;
+bool __initdata opt_ext_regions = true;
 boolean_param("ext_regions", opt_ext_regions);
 
 static u64 __initdata dom0_mem;
@@ -1196,6 +1196,28 @@ int __init make_hypervisor_node(struct domain *d,
 printk(XENLOG_WARNING "%pd: failed to allocate extended regions\n",
d);
 nr_ext_regions = ext_regions->nr_banks;
+
+/*
+ * If extended region is enabled, carve out the 16MB guest magic page
+ * regions from the first bank of extended region (at least 64MB) for
+ * the 1:1 dom0less DomUs
+ */
+if ( is_domain_direct_mapped(d) && !is_hardware_domain(d) )
+{
+struct mem_map_domain *mem_map = >arch.mem_map;
+
+for ( i = 0; i < mem_map->nr_mem_regions; i++ )
+{
+if ( mem_map->regions[i].type == GUEST_MEM_REGION_MAGIC )
+{
+mem_map->regions[i].start = ext_regions->bank[0].start;
+mem_map->regions[i].size = GUEST_MAGIC_SIZE;
+
+ext_regions->bank[0].start += GUEST_MAGIC_SIZE;
+ext_regions->bank[0].size -= GUEST_MAGIC_SIZE;
+}
+}
+}
 }
 
 reg = xzalloc_array(__be32, (nr_ext_regions + 1) * (addrcells + 
sizecells));
diff --git a/xen/arch/arm/include/asm/domain_build.h 
b/xen/arch/arm/include/asm/domain_build.h
index 74432123fe..063ff727bb 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -4,6 +4,8 @@
 #include 
 #include 
 
+extern bool opt_ext_regions;
+
 typedef __be32 gic_interrupt_t[3];
 
 bool allocate_bank_memory(struct domain *d, struct kernel_info *kinfo,
diff --git a/xen/arch/arm/include/asm/static-memory.h 
b/xen/arch/arm/include/asm/static-memory.h
index 3e3efd70c3..01e51217ca 100644
--- a/xen/arch/arm/include/asm/static-memory.h
+++ b/xen/arch/arm/include/asm/static-memory.h
@@ -12,6 +12,7 @@ void allocate_static_memory(struct domain *d, struct 
kernel_info *kinfo,
 void assign_static_memory_11(struct domain *d, struct kernel_info *kinfo,
  const struct dt_device_node *node);
 void init_staticmem_pages(void);
+int find_11_domU_magic_region(struct domain *d, struct kernel_info *kinfo);
 
 #else /* !CONFIG_STATIC_MEMORY */
 
@@ -31,6 +32,12 @@ static inline void assign_static_memory_11(struct domain *d,
 
 static inline void init_staticmem_pages(void) {};
 
+static inline int find_11_domU_magic_region(struct domain *d,
+struct kernel_info *kinfo)
+{
+return 0;
+}
+
 #endif /* CONFIG_STATIC_MEMORY */
 
 #endif 

[PATCH v3 1/4] xen/domctl, tools: Introduce a new domctl to get guest memory map

[Henry Wang]

There are some use cases where the toolstack needs to know the guest
memory map. For example, the toolstack helper application
"init-dom0less" needs to know the guest magic page regions for 1:1
direct-mapped dom0less DomUs to allocate magic pages.

To address such needs, add XEN_DOMCTL_get_mem_map hypercall and
related data structures to query the hypervisor for the guest memory
map. The guest memory map is recorded in the domain structure and
currently only guest magic page region is recorded in the guest
memory map. The guest magic page region is initialized at the domain
creation time as the layout in the public header, and it is updated
for 1:1 dom0less DomUs (see the following commit) to avoid conflict
with RAM.

Take the opportunity to drop an unnecessary empty line to keep the
coding style consistent in the file.

Reported-by: Alec Kwapis 
Signed-off-by: Henry Wang 
---
RFC: I think the newly introduced "struct xen_domctl_mem_map" is
quite duplicated with "struct xen_memory_map", any comment on reuse
the "struct xen_memory_map" for simplicity?
v3:
- Init the return rc for XEN_DOMCTL_get_mem_map.
- Copy the nr_mem_regions back as it should be both IN & OUT.
- Check if mem_map->nr_mem_regions exceeds the XEN_MAX_MEM_REGIONS
  when adding a new entry.
- Allow XEN_MAX_MEM_REGIONS to be different between different archs.
- Add explicit padding and check to the domctl structures.
v2:
- New patch
---
 tools/include/xenctrl.h   |  4 
 tools/libs/ctrl/xc_domain.c   | 33 +++
 xen/arch/arm/domain.c | 15 ++
 xen/arch/arm/domctl.c | 32 +-
 xen/arch/arm/include/asm/domain.h |  8 
 xen/include/public/arch-arm.h | 11 +++
 xen/include/public/domctl.h   | 27 +
 7 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 2ef8b4e054..b25e9772a2 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1195,6 +1195,10 @@ int xc_domain_setmaxmem(xc_interface *xch,
 uint32_t domid,
 uint64_t max_memkb);
 
+int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid,
+  struct xen_mem_region mem_regions[],
+  uint32_t *nr_regions);
+
 int xc_domain_set_memmap_limit(xc_interface *xch,
uint32_t domid,
unsigned long map_limitkb);
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index f2d9d14b4d..8363657dae 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -697,6 +697,39 @@ int xc_domain_setmaxmem(xc_interface *xch,
 return do_domctl(xch, );
 }
 
+int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid,
+  struct xen_mem_region mem_regions[],
+  uint32_t *nr_regions)
+{
+int rc;
+struct xen_domctl domctl = {
+.cmd = XEN_DOMCTL_get_mem_map,
+.domain  = domid,
+.u.mem_map = {
+.nr_mem_regions = *nr_regions,
+.pad= 0,
+},
+};
+
+DECLARE_HYPERCALL_BOUNCE(mem_regions,
+ sizeof(xen_mem_region_t) * (*nr_regions),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+if ( !mem_regions || xc_hypercall_bounce_pre(xch, mem_regions) ||
+ (*nr_regions) < 1 )
+return -1;
+
+set_xen_guest_handle(domctl.u.mem_map.buffer, mem_regions);
+
+rc = do_domctl(xch, );
+
+xc_hypercall_bounce_post(xch, mem_regions);
+
+*nr_regions = domctl.u.mem_map.nr_mem_regions;
+
+return rc;
+}
+
 #if defined(__i386__) || defined(__x86_64__)
 int xc_domain_set_memory_map(xc_interface *xch,
uint32_t domid,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f38cb5e04c..e77d157626 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -696,6 +696,7 @@ int arch_domain_create(struct domain *d,
 {
 unsigned int count = 0;
 int rc;
+struct mem_map_domain *mem_map = >arch.mem_map;
 
 BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
 
@@ -785,6 +786,20 @@ int arch_domain_create(struct domain *d,
 d->arch.sve_vl = config->arch.sve_vl;
 #endif
 
+if ( mem_map->nr_mem_regions < XEN_MAX_MEM_REGIONS )
+{
+mem_map->regions[mem_map->nr_mem_regions].start = GUEST_MAGIC_BASE;
+mem_map->regions[mem_map->nr_mem_regions].size = GUEST_MAGIC_SIZE;
+mem_map->regions[mem_map->nr_mem_regions].type = 
GUEST_MEM_REGION_MAGIC;
+mem_map->nr_mem_regions++;
+}
+else
+{
+printk("Exceed max number of supported memory map regions\n");
+rc = -ENOSPC;
+goto fail;
+}
+
 return 0;
 
 fail:
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index ad56efb0f5..ede19d80a3 100644
--- 

Re: [PATCH 3/3] arm: platform: qcom: add basic support SA8155P SoC

[Michal Orzel]

Hello,

On 29/03/2024 01:08, Volodymyr Babchuk wrote:
> 
> 
> Qualcomm SA8155P is the automotive variant of SM8150 aka Snapdragon
> 855.
> 
> This patch adds very basic support for the platform. We need to handle
> Qualcomm-specific SMC to workaround quirk in the QCOM SCM driver in
> the Linux kernel. Basically the driver tries multiple different SMCs
> to determine which calling convention is supported by a SoC. If all
> calls fail it decides that the SoC uses "legacy SMC" and tries to
> communicate with SCM by issuing SMC with funcid = 1. Problem is that
> Xen has own understanding on how such SMC should be handled. It
> interprets this SMC as legacy PSCI_cpu_off and happily turns of Linux
> boot CPU.
> 
> To workaround this, we pretend that we support
> QCOM_SCM_INFO_IS_CALL_AVAIL, this will make the driver use the latest
> calling convention. All subsequent calls will fail anyways and the
> driver will terminate self gracefully. This is not a big deal, because
> right now (with Linux 6.8) even on baremetal setup the driver fails
> anyways, because it does not know how to work with this SoC.
Therefore I would consider adding a Kconfig option and placing it under 
experimental

> 
> Signed-off-by: Volodymyr Babchuk 
> ---
>  xen/arch/arm/platforms/Makefile |  1 +
>  xen/arch/arm/platforms/qcom.c   | 77 +
>  2 files changed, 78 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/qcom.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index 8632f4115f..6873735ef0 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
>  obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>  obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>  obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> +obj-$(CONFIG_ALL64_PLAT) += qcom.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
> diff --git a/xen/arch/arm/platforms/qcom.c b/xen/arch/arm/platforms/qcom.c
> new file mode 100644
> index 00..77e9c58649
> --- /dev/null
> +++ b/xen/arch/arm/platforms/qcom.c
> @@ -0,0 +1,77 @@
> +/*
> + * xen/arch/arm/platforms/qcom.c
> + *
> + * Qualcomm SoCs specific code
> + *
> + * Volodymyr Babchuk 
> + *
> + * Copyright (c) 2024 EPAM Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
Please use SPDX identifier instead of license text

> + */
> +
> +#include 
> +#include 
no need for this public header

> +#include 
> +
> +#define SCM_SMC_FNID(s, c) s) & 0xFF) << 8) | ((c) & 0xFF))
spaces instead of tabs

> +#define QCOM_SCM_SVC_INFO  0x06
spaces instead of tabs

> +#define QCOM_SCM_INFO_IS_CALL_AVAIL0x01
> +
> +#define ARM_SMCCC_SIP_QCOM_SCM_IS_CALL_AVAIL\
> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +   ARM_SMCCC_CONV_64,   \
> +   ARM_SMCCC_OWNER_SIP, \
> +   SCM_SMC_FNID(QCOM_SCM_SVC_INFO,  \
> +QCOM_SCM_INFO_IS_CALL_AVAIL))
> +
> +static const char * const sa8155p_dt_compat[] __initconst =
> +{
> +"qcom,sa8155p",
> +NULL
> +};
> +
> +static bool sa8155p_smc(struct cpu_user_regs *regs)
> +{
> +uint32_t funcid = get_user_reg(regs, 0);
> +
> +switch ( funcid ) {
brace should be placed on a new line

~Michal

Re: [XEN PATCH 3/7] xen/sched: address a violation of MISRA C:2012 Rule 16.3

[Nicola Vetrini]

On 2024-04-03 08:33, Jan Beulich wrote:

On 02.04.2024 09:22, Federico Serafini wrote:

Use pseudo-keyword fallthrough to meet the requirements to deviate
MISRA C:2012 Rule 16.3 ("An unconditional `break' statement shall
terminate every switch-clause").

No functional change.

Signed-off-by: Federico Serafini 
---
 xen/common/sched/credit2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index c76330d79d..0962b52415 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3152,8 +3152,8 @@ static int cf_check csched2_sys_cntl(
 printk(XENLOG_INFO "Disabling context switch rate 
limiting\n");

 prv->ratelimit_us = params->ratelimit_us;
 write_unlock_irqrestore(>lock, flags);
+fallthrough;

-/* FALLTHRU */
 case XEN_SYSCTL_SCHEDOP_getinfo:
 params->ratelimit_us = prv->ratelimit_us;
 break;


Hmm, the description doesn't say what's wrong with the comment. 
Furthermore

docs/misra/rules.rst doesn't mention "fallthrough" at all, nor the
alternative of using comments. I notice docs/misra/deviations.rst does, 
and
there the specific comment used here isn't covered. That would want 
saying

in the description.

Stefano (and others) - in this context it becomes noticeable that 
having
stuff scattered across multiple doc files isn't necessarily helpful. 
Other

permissible keywords are mentioned in rules.rst. The pseudo-keyword
"fallthrough" as well as comments are mentioned on deviations.rst. 
Could

you remind me of the reason(s) why things aren't recorded in a single,
central place?

Jan


If I recall correctly, the idea was to avoid rules.rst from getting too 
long and too specific about which patterns were deviated, while also 
having a precise record of the MISRA deviations that didn't live in 
ECLAIR-specific files. Maybe the use of the pseudo-keyword emerged after 
the rule was added to rules.rst, since deviations.rst is updated more 
frequently.


--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [PATCH 2/3] drivers: serial: add Qualcomm GENI-based serial driver

[Michal Orzel]

On 02/04/2024 23:19, Volodymyr Babchuk wrote:
> 
> 
> Hi Michal,
> 
> Michal Orzel  writes:
> 
>> Hello,
>>
>> On 29/03/2024 01:08, Volodymyr Babchuk wrote:
>>>
>>>
>>> Generic Interface (GENI) is a newer interface for low speed interfaces
>>> like UART, I2C or SPI. This patch adds the simple driver for the UART
>>> instance of GENI. Code is based on similar drivers in U-Boot and Linux
>>> kernel.
>> Do you have a link to a manual?
> 
> I wish I had. Qualcomm provides HW manuals only under very strict
> NDAs. At the time of writing I don't have access to the manual at
> all. Those patches are based solely on similar drivers in U-Boot and
> Linux kernel.
> 
>>>
>>> This driver implements only simple synchronous mode, because although
>>> GENI supports FIFO mode, it needs to know number of
>>> characters **before** starting TX transaction. This is a stark
>>> contrast when compared to other UART peripherals, which allow adding
>>> characters to a FIFO while TX operation is running.
>>>
>>> The patch adds both normal UART driver and earlyprintk version.
>>>
>>> Signed-off-by: Volodymyr Babchuk 
>>> ---
>>>  xen/arch/arm/Kconfig.debug   |  19 +-
>>>  xen/arch/arm/arm64/debug-qcom.inc|  76 +++
>> Shouldn't all the files (+ other places) have geni in their names? Could 
>> qcom refer to other type of serial device?
> 
> AFAIK, there is an older type of serial device. Both Linux and U-Boot
> use "msm" instead of "qcom" in drivers names for those devices.
> 
> But I can add "geni" to the names, no big deal.
> 
>>
>>>  xen/arch/arm/include/asm/qcom-uart.h |  48 +
>>>  xen/drivers/char/Kconfig |   8 +
>>>  xen/drivers/char/Makefile|   1 +
>>>  xen/drivers/char/qcom-uart.c | 288 +++
>>>  6 files changed, 439 insertions(+), 1 deletion(-)
>>>  create mode 100644 xen/arch/arm/arm64/debug-qcom.inc
>>>  create mode 100644 xen/arch/arm/include/asm/qcom-uart.h
>>>  create mode 100644 xen/drivers/char/qcom-uart.c
>>>
>>> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
>>> index eec860e88e..f6ab0bb30e 100644
>>> --- a/xen/arch/arm/Kconfig.debug
>>> +++ b/xen/arch/arm/Kconfig.debug
>>> @@ -119,6 +119,19 @@ choice
>>> selecting one of the platform specific options 
>>> below if
>>> you know the parameters for the port.
>>>
>>> +   This option is preferred over the platform specific
>>> +   options; the platform specific options are 
>>> deprecated
>>> +   and will soon be removed.
>>> +   config EARLY_UART_CHOICE_QCOM
>> The list is sorted alphabetically. Please adhere to that.
>>
> 
> Sure
> 
>>> +   select EARLY_UART_QCOM
>>> +   bool "Early printk via Qualcomm debug UART"
>> Shouldn't you add depends on ARM_64? Isn't this device Arm64 specific like 
>> in Linux?
>>
> 
> In linux it depends on ARCH_QCOM which can be enabled both for arm and
> arm64. But for Xen case... I believe it is better to make ARM_64
> dependency.
> 
>>> +   help
>>> +   Say Y here if you wish the early printk to direct 
>>> their
>> help text here should be indented by 2 tabs and 2 spaces (do not take 
>> example from surrounding code)
>>
> 
> Would anyone mind if I'll send patch that aligns surrounding code as well?
> 
>>> +   output to a Qualcomm debug UART. You can use this 
>>> option to
>>> +   provide the parameters for the debug UART rather 
>>> than
>>> +   selecting one of the platform specific options 
>>> below if
>>> +   you know the parameters for the port.
>>> +
>>> This option is preferred over the platform specific
>>> options; the platform specific options are 
>>> deprecated
>>> and will soon be removed.
>>> @@ -211,6 +224,9 @@ config EARLY_UART_PL011
>>>  config EARLY_UART_SCIF
>>> select EARLY_PRINTK
>>> bool
>>> +config EARLY_UART_QCOM
>>> +   select EARLY_PRINTK
>>> +   bool
>> The list is sorted alphabetically. Please adhere to that.
>>
>>>
>>>  config EARLY_PRINTK
>>> bool
>>> @@ -261,7 +277,7 @@ config EARLY_UART_PL011_MMIO32
>>>   will be done using 32-bit only accessors.
>>>
>>>  config EARLY_UART_INIT
>>> -   depends on EARLY_UART_PL011 && EARLY_UART_PL011_BAUD_RATE != 0
>>> +   depends on (EARLY_UART_PL011 && EARLY_UART_PL011_BAUD_RATE != 0) || 
>>> EARLY_UART_QCOM
>>> def_bool y
>>>
>>>  config EARLY_UART_8250_REG_SHIFT
>>> @@ -308,3 +324,4 @@ config EARLY_PRINTK_INC
>>> default "debug-mvebu.inc" if EARLY_UART_MVEBU
>>> default "debug-pl011.inc" if EARLY_UART_PL011
>>> default "debug-scif.inc" if EARLY_UART_SCIF
>>> +   default "debug-qcom.inc" if EARLY_UART_QCOM
>>> diff --git a/xen/arch/arm/arm64/debug-qcom.inc 
>>> 

Re: [XEN PATCH 7/7] vsprintf: address violations of MISRA C:2012 Rule 16.3

[Federico Serafini]

On 03/04/24 09:06, Jan Beulich wrote:

On 02.04.2024 09:22, Federico Serafini wrote:

MISRA C:2012 Rule 16.3 states: "An unconditional `break' statement
shall terminate every switch-clause".

Add break statement to address violations of the rule or add
pseudo-keyword fallthrough to meet the requirements to deviate it.


While the latter half of the sentence properly describes the latter
two of the hunks, the former half doesn't match the former two hunks
at all:


--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -377,7 +377,7 @@ static char *pointer(char *str, const char *end, const char 
**fmt_ptr,
  str = number(str, end, hex_buffer[i], 16, 2, -1, ZEROPAD);
  
  if ( ++i == field_width )

-return str;
+break;


This "break" is inside for(), not switch().


@@ -386,6 +386,8 @@ static char *pointer(char *str, const char *end, const char 
**fmt_ptr,
  ++str;
  }
  }
+
+return str;
  }


And this "return" is what now "delimits" case 'h' of the switch(). The
original situation therefore was that the for() could not be exited by
other than the "return" inside. The supposedly missing "break" in that
arrangement would have been "unreachable code", i.e. violate another
rule. Hence the (undescribed) further re-arrangement.


I'll improve the description.

--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

Re: [XEN PATCH 5/7] xen/sched: address a violation of MISRA C:2012 Rule 16.3

[Federico Serafini]

On 03/04/24 08:55, Jan Beulich wrote:

On 02.04.2024 09:22, Federico Serafini wrote:

Add break statement to address a violation of MISRA C:2012 Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause ").

No functional change.

Signed-off-by: Federico Serafini 


Reviewed-by: Jan Beulich 

However, this is the 2nd patch in this series with exactly the same title.
Going just from titles, one option would be to fold both. The other option
would be to change the title prefix of patch 3 to "xen/credit2:".


I'll go for the first option.

--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

Re: [PATCH v3 2/2] drivers/char: mark extra reserved device memory in memory map

[Jan Beulich]

On 27.03.2024 03:53, Marek Marczykowski-Górecki wrote:
> The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> map. This should be true for addresses coming from the firmware, but
> when extra pages used by Xen itself are included in the mapping, those
> are taken from usable RAM used. Mark those pages as reserved too.
> 
> Not marking the pages as reserved didn't caused issues before due to
> another a bug in IOMMU driver code, that was fixed in 83afa3135830
> ("amd-vi: fix IVMD memory type checks").
> 
> Failing to reserve memory will lead to panic in IOMMU setup code. And
> not including the page in IOMMU mapping will lead to broken console (due
> to IOMMU faults). The pages chosen by the XHCI console driver should
> still be usable by the CPU though, and the console code already can deal
> with too slow console by dropping characters (and console not printing
> anything is a special case of "slow"). When reserving fails print an error
> message showing which pages failed and who requested them. This should
> be enough hint to find why XHCI console doesn't work.
> 
> Fixes: 3a1a7b809ffa "drivers/char: mark DMA buffers as reserved for the XHCI"
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Jan Beulich 

Re: [XEN PATCH 7/7] vsprintf: address violations of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> MISRA C:2012 Rule 16.3 states: "An unconditional `break' statement
> shall terminate every switch-clause".
> 
> Add break statement to address violations of the rule or add
> pseudo-keyword fallthrough to meet the requirements to deviate it.

While the latter half of the sentence properly describes the latter
two of the hunks, the former half doesn't match the former two hunks
at all:

> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -377,7 +377,7 @@ static char *pointer(char *str, const char *end, const 
> char **fmt_ptr,
>  str = number(str, end, hex_buffer[i], 16, 2, -1, ZEROPAD);
>  
>  if ( ++i == field_width )
> -return str;
> +break;

This "break" is inside for(), not switch().

> @@ -386,6 +386,8 @@ static char *pointer(char *str, const char *end, const 
> char **fmt_ptr,
>  ++str;
>  }
>  }
> +
> +return str;
>  }

And this "return" is what now "delimits" case 'h' of the switch(). The
original situation therefore was that the for() could not be exited by
other than the "return" inside. The supposedly missing "break" in that
arrangement would have been "unreachable code", i.e. violate another
rule. Hence the (undescribed) further re-arrangement.

Jan

Re: [XEN PATCH 5/7] xen/sched: address a violation of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause ").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Jan Beulich 

However, this is the 2nd patch in this series with exactly the same title.
Going just from titles, one option would be to fold both. The other option
would be to change the title prefix of patch 3 to "xen/credit2:".

Jan

Re: [XEN PATCH 4/7] xen/evtchn: address a violation of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause ").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Jan Beulich 

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Jan Beulich]

On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> Whether to return information about a xen-owned evtchn is a matter of policy,
>> and it's not acceptable to short circuit the XSM on the matter.
> 
> I can certainly accept this as one possible view point. As in so many cases
> I'm afraid I dislike you putting it as if it was the only possible one.

Further to this: Is there even a way to express the same denial in XSM?
alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
channel, and (yes, it could in principle be open-coded in Flask code)
consumer_is_xen() is private to event_channel.c. I also dare to question
whether in SILO mode status information like this should be available.

Jan

Re: [XEN PATCH 3/7] xen/sched: address a violation of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> Use pseudo-keyword fallthrough to meet the requirements to deviate
> MISRA C:2012 Rule 16.3 ("An unconditional `break' statement shall
> terminate every switch-clause").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 
> ---
>  xen/common/sched/credit2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
> index c76330d79d..0962b52415 100644
> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -3152,8 +3152,8 @@ static int cf_check csched2_sys_cntl(
>  printk(XENLOG_INFO "Disabling context switch rate limiting\n");
>  prv->ratelimit_us = params->ratelimit_us;
>  write_unlock_irqrestore(>lock, flags);
> +fallthrough;
>  
> -/* FALLTHRU */
>  case XEN_SYSCTL_SCHEDOP_getinfo:
>  params->ratelimit_us = prv->ratelimit_us;
>  break;

Hmm, the description doesn't say what's wrong with the comment. Furthermore
docs/misra/rules.rst doesn't mention "fallthrough" at all, nor the
alternative of using comments. I notice docs/misra/deviations.rst does, and
there the specific comment used here isn't covered. That would want saying
in the description.

Stefano (and others) - in this context it becomes noticeable that having
stuff scattered across multiple doc files isn't necessarily helpful. Other
permissible keywords are mentioned in rules.rst. The pseudo-keyword
"fallthrough" as well as comments are mentioned on deviations.rst. Could
you remind me of the reason(s) why things aren't recorded in a single,
central place?

Jan

Re: [XEN PATCH 2/7] console: address a violation of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause ").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Jan Beulich 

Re: [XEN PATCH 1/7] xen/domctl: address a violation of MISRA C:2012 Rule 16.3

[Jan Beulich]

On 02.04.2024 09:22, Federico Serafini wrote:
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause ").
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Jan Beulich 

Re: [PATCH] docs/misra: add 13.6 to rules.rst

[Jan Beulich]

On 03.04.2024 01:21, Stefano Stabellini wrote:
> As agreed during MISRA C meetings, add Rule 13.6 to rules.rst.
> 
> Signed-off-by: Stefano Stabellini 
> ---
> There was a request to expand the scope to also include alignof and
> typeof. Depending on whether the MISRA C scanners support it, and under
> which rules violations will be listed, rules.rst will be updated
> accordingly (either updating the notes section of 13.6 or adding a new
> entry.)

Hmm. Imo ...

> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -445,6 +445,12 @@ maintainers if you want to suggest a change.
>   - Initializer lists shall not contain persistent side effects
>   -
>  
> +   * - `Rule 13.6 
> `_
> + - Required
> + - The operand of the sizeof operator shall not contain any
> +   expression which has potential side-effects
> + -

... a note to this effect should be put here right away. We _want_ to
respect the rule for the other two similar keywords, after all. What we
don't know at this point is whether we can get help towards this from
Eclair.

With such a note added:
Acked-by: Jan Beulich 

Jan

Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Jan Beulich]

On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.

Well, what does "have no business" leave open?

> The claim is false, and the commit broke lsevtchn in dom0.

Or alternatively lsevtchn was doing something that was never meant to work
(from Xen's perspective).

>  It is also quite
> obvious from XSM_TARGET that it has broken device model stubdoms too.

Why would that be "obvious"? What business would a stubdom have to look at
Xen's side of an evtchn?

> Whether to return information about a xen-owned evtchn is a matter of policy,
> and it's not acceptable to short circuit the XSM on the matter.

I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.

In summary: The supposed justification you claim is missing in the original
change is imo also missing here then: What business would any entity in the
system have to look at Xen's side of an event channel? Back at the time, 3
people agreed that it's "none".

Jan

Re: [PATCH v6 7/8] xen/rwlock: raise the number of possible cpus

[Jan Beulich]

On 02.04.2024 17:29, Jürgen Groß wrote:
> On 02.04.24 16:52, Jan Beulich wrote:
>> On 27.03.2024 16:22, Juergen Gross wrote:
>>> @@ -36,14 +36,21 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>>   
>>>   static inline bool _is_write_locked_by_me(unsigned int cnts)
>>>   {
>>> -BUILD_BUG_ON(_QW_CPUMASK < NR_CPUS);
>>> +BUILD_BUG_ON((_QW_CPUMASK + 1) < NR_CPUS);
>>> +BUILD_BUG_ON(NR_CPUS * _QR_BIAS > INT_MAX);
>>>   return (cnts & _QW_WMASK) == _QW_LOCKED &&
>>>  (cnts & _QW_CPUMASK) == smp_processor_id();
>>>   }
>>>   
>>>   static inline bool _can_read_lock(unsigned int cnts)
>>>   {
>>> -return !(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts);
>>> +/*
>>> + * If write locked by the caller, no other readers are possible.
>>> + * Not allowing the lock holder to read_lock() another 32768 times 
>>> ought
>>> + * to be fine.
>>> + */
>>> +return cnts <= INT_MAX &&
>>> +   (!(cnts & _QW_WMASK) || _is_write_locked_by_me(cnts));
>>>   }
>>
>> What is the 32768 in the comment relating to? INT_MAX is quite a bit higher,
>> yet the comparison against it is the only thing you add. Whereas the reader
>> count is, with the sign bit unused, 17 bits, though (bits 14..30). I think
> 
> You missed:
> 
> #define_QR_SHIFT(_QW_SHIFT + 2) /* Reader count shift */

Oops. No I idea how I managed to skip this, when something like this was
exactly what I was expecting to find.

> So the reader's shift is 16, resulting in 15 bits for the reader count.
> 
>> even in such a comment rather than using a literal number the corresponding
>> expression would better be stated.
> 
> Hmm, you mean replacing the 32768 with INT_MAX >> _QR_SHIFT? This would be
> fine with me.

Happy to do so while committing, provided earlier patches get unblocked
first:
Reviewed-by: Jan Beulich 

Jan