[xen-4.17-testing test] 185711: tolerable FAIL - PUSHED

[osstest service owner]

flight 185711 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185711/

Failures :-/ but no regressions.

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

Last test of basis   185284  2024-04-09 12:07:06 Z8 days
Failing since185300  2024-04-10 16:35:42 Z7 days8 attempts
Testing same since   185400  2024-04-12 22:46:40 Z5 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Marek Marczykowski-Górecki 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 

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

[xen-4.16-testing test] 185710: tolerable FAIL - PUSHED

[osstest service owner]

flight 185710 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185710/

Failures :-/ but no regressions.

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

Last test of basis   185283  2024-04-09 12:06:57 Z8 days
Failing since185297  2024-04-10 10:03:29 Z7 days7 attempts
Testing same since   185710  2024-04-17 07:07:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Marek Marczykowski-Górecki 
  Roger Pau Monne 
  Roger Pau Monné 

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

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

[Julien Grall]

Hi,

On 02/04/2024 22: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.
If you don't provide the early printk for arm32, then you need to add 
DEPENDS ON otherwise randconfig will fail on arm32.


[...]


You see, this code is working inside-out. early printk code in Xen is
written with assumption that early_uart_transmit don't need a scratch
register. But this is not true for GENI... To send one character we
must write two registers beforehand: TX_TRANS_LEN and CMD0. Only after
that we can write something to FIFO. But early_uart_transmit has no
scratch register to prepare values for TX_TRANS_LEN and CMD0. So we
write what we do here

1. Reset the state machine with ABORT command
2. Write 1 to TX_TRANS_LEN
3. Write START_TX to CMD0

Now early_uart_transmit can write "wt" to the FIFO and after that it can
use "wt" as a scratch register to repeat steps 2 and 3.


AFAIU, this means we would potentially do one too many iteration. Does 
this have any implication to the runtime UART driver?


But why do we need to repeat step 2/3? Is this because both registers 
will be reset after the character is written?




Probably I need this as a comment to into the .inc file...


+mov   w\c, #M_GENI_CMD_ABORT
+str   w\c, [\xb, #SE_GENI_M_CMD_CTRL_REG]
+1:
+ldr   w\c, [\xb, #SE_GENI_M_IRQ_STATUS]   /* Load IRQ status */
+tst   w\c, #M_CMD_ABORT_EN /* Check TX_FIFI_WATERMARK_EN bit */

The comment does not correspond to the code. Shouldn't this be the same as in 
early_uart_ready?



We need to reset the state machine with ABORT command just in case.


Would you mind to explain what you mean with "just in case"? A pointer
to the corresponding Linux/U-boot code would be helpful.

[...]


+
+#endif /* __ASM_ARM_QCOM_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e18ec3788c..52c3934d06 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -68,6 +68,14 @@ config HAS_SCIF
   This selects the SuperH SCI(F) UART. If you have a SuperH based 
board,
   or Renesas 

[ovmf test] 185726: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0afb8743493853e30171f6000de51242e22a1eb8
baseline version:
 ovmf 6ced1e91eff13dae1bfba95734e2b34a73601db2

Last test of basis   185725  2024-04-17 18:43:01 Z0 days
Testing same since   185726  2024-04-17 21:14:35 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Ray Ni 
  Tom Lendacky 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   6ced1e91ef..0afb874349  0afb8743493853e30171f6000de51242e22a1eb8 -> 
xen-tested-master

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

[Julien Grall]

Hi,

On 29/03/2024 00: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.


If this is based on Linux/U-boot, then I assume you read the code and 
possibly copy/paste some of it. Therefore...




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 +++
  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
+   select EARLY_UART_QCOM
+   bool "Early printk via Qualcomm debug UART"
+   help
+   Say Y here if you wish the early printk to direct their
+   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
  
  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 
b/xen/arch/arm/arm64/debug-qcom.inc
new file mode 100644
index 00..130d08d6e9
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-qcom.inc
@@ -0,0 +1,76 @@
+/*
+ * xen/arch/arm/arm64/debug-qcom.inc
+ *
+ * Qualcomm debug UART specific debug 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.


... I don't think you can use GPLv2+ license here. It has to be the same 
as Linux/U-boot.


Also, as there is no public manual, can you provide some pointer to the 
code from both repo (including version)? This would help the reviewer to 
confirm you code.


Cheers,

--
Julien Grall

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

[Julien Grall]

Hi Volodymyr,

On 29/03/2024 00: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.


Is there any patches that are not yet merged and/or on a Qualcomm 
specific tree? I just want to make sure that we have a code that will 
still work in the near future.




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.


Did you intend to license the code as GPLv2+? See [1], for some context.


+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+
+#define SCM_SMC_FNID(s, c) s) & 0xFF) << 8) | ((c) & 0xFF))
+#define QCOM_SCM_SVC_INFO  0x06
+#define QCOM_SCM_INFO_IS_CALL_AVAIL0x01
+
+#define ARM_SMCCC_SIP_QCOM_SCM_IS_CALL_AVAIL\


I find this name a little bit too long. Can we remove ARM_SMCCC as I 
don't think it adds any value?



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


The function will also called for guests. But only the hardware 
domain/dom0 is using the machine qcom,sa8155p, so I think you want to 
check the domain.



+switch ( funcid ) {
+case ARM_SMCCC_SIP_QCOM_SCM_IS_CALL_AVAIL:
+/*
+ * We need to implement this specific call only to make Linux
+ * counterpart happy: QCOM SCM driver in Linux tries to
+ * determine calling convention by issuing this particular
+ * SMC. If it receives an error it assumes that platform uses
+ * legacy calling convention and tries to issue SMC with
+ * funcid = 1. Xen interprets this as PSCI_cpu_off and turns
+ * off Linux boot vCPU.
+ */
+set_user_reg(regs, 0, ARM_SMCCC_SUCCESS);
+set_user_reg(regs, 1, 1);
+return true;
+default:
+return false;
+}
+}
+
+PLATFORM_START(sa8155p, "Qualcomm SA8155P")
+.compatible = sa8155p_dt_compat,
+.smc = sa8155p_smc
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ 

Re: [PATCH 1/3] arm: smmu: allow SMMU to have more IRQs than context banks

[Julien Grall]

Hi,

On 02/04/2024 08:28, Michal Orzel wrote:

Hello,

On 29/03/2024 01:08, Volodymyr Babchuk wrote:



I encountered platform, namely Qualcomm SA8155P where SMMU-compatible

NIT: a commit msg should be written in imperative mood


IO-MMU advertises more context IQRs than there are context banks. This
should not be an issue, we need to relax the check in the SMMU driver
to allow such configuration.

Signed-off-by: Volodymyr Babchuk 
---
  xen/drivers/passthrough/arm/smmu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 32e2ff279b..2dd3688f3b 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2550,7 +2550,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
 parse_driver_options(smmu);

 if (smmu->version > ARM_SMMU_V1 &&
-   smmu->num_context_banks != smmu->num_context_irqs) {
+   smmu->num_context_banks > smmu->num_context_irqs) {

This was done in Linux by commit:
d1e20222d537 ("iommu/arm-smmu: Error out only if not enough context interrupts")

However, they also ignore superfluous interrupts. Shouldn't we do the same?


+1. It would be better to avoid allocating stating for IRQs that are 
never used.


Cheers,

--
Julien Grall

Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Stefano Stabellini]

+Bugseng

On Wed, 17 Apr 2024, Julien Grall wrote:
> Hi Stefano,
> 
> On 17/04/2024 20:10, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2024, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 16/04/2024 20:27, Stefano Stabellini wrote:
> > > > Also add two specific project-wide deviations for R21.6 and R21.15.
> > > 
> > > In general, I am fine with add the two rules. However...
> > > 
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > 
> > > > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > > > index 32b02905d1..9123c8edb5 100644
> > > > --- a/docs/misra/deviations.rst
> > > > +++ b/docs/misra/deviations.rst
> > > > @@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules:
> > > >   of the Rule due to uses of this macro.
> > > > - Tagged as `deliberate` for ECLAIR.
> > > >+   * - R21.6
> > > > + - The use of snprintf() and vsnprintf() is justifiable as, despite
> > > > +   the fact that such functions have the same names of the
> > > > +   corresponding standard library functions, each configuration of
> > > > +   Xen has a unique implementation for them; the code implementing
> > > > +   such functions is subject to the analysis, so that any undefined
> > > > +   or unspecified behavior associated to them falls under the
> > > > +   responsibility of other MISRA guidelines
> > > > + - Tagged as `safe` for ECLAIR.
> > > 
> > > ... this implies that ECLAIR should be modified. But this is not happening
> > > in
> > > this patch. Looking at history, we tend to keep deviations.rst in sync
> > > with
> > > ECLAIR, so I think it should be updated here too.
> > 
> > That is true but I am not very familiar with Eclair config language so
> > it is better if that is done by the Bugseng team. I can merge their
> > patch into this one or vice versa or they could be committed separately
> > (keep in mind that the rule is not enabled in the ECLAIR scan so from a
> > Gitlab-CI point of view we don't require the change to the ECLAIR config
> > although it makes sense). I am happy either way.
> 
> My comment was not about Gitlab CI. It was more about consistency between the
> file and ECLAIR. I think they should be kept in sync because it explain how
> the tool doing the scanning behave.
> 
> My preference is to either split and only commit the rules now or wait for the
> ECLAIR change to happen.

Understood. Maybe the Bugseng team can provide the corresponding
ECLAIR/deviations.ecl changes

Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Julien Grall]

Hi Stefano,

On 17/04/2024 20:10, Stefano Stabellini wrote:

On Wed, 17 Apr 2024, Julien Grall wrote:

Hi Stefano,

On 16/04/2024 20:27, Stefano Stabellini wrote:

Also add two specific project-wide deviations for R21.6 and R21.15.


In general, I am fine with add the two rules. However...



Signed-off-by: Stefano Stabellini 

diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 32b02905d1..9123c8edb5 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules:
  of the Rule due to uses of this macro.
- Tagged as `deliberate` for ECLAIR.
   +   * - R21.6
+ - The use of snprintf() and vsnprintf() is justifiable as, despite
+   the fact that such functions have the same names of the
+   corresponding standard library functions, each configuration of
+   Xen has a unique implementation for them; the code implementing
+   such functions is subject to the analysis, so that any undefined
+   or unspecified behavior associated to them falls under the
+   responsibility of other MISRA guidelines
+ - Tagged as `safe` for ECLAIR.


... this implies that ECLAIR should be modified. But this is not happening in
this patch. Looking at history, we tend to keep deviations.rst in sync with
ECLAIR, so I think it should be updated here too.


That is true but I am not very familiar with Eclair config language so
it is better if that is done by the Bugseng team. I can merge their
patch into this one or vice versa or they could be committed separately
(keep in mind that the rule is not enabled in the ECLAIR scan so from a
Gitlab-CI point of view we don't require the change to the ECLAIR config
although it makes sense). I am happy either way.


My comment was not about Gitlab CI. It was more about consistency 
between the file and ECLAIR. I think they should be kept in sync because 
it explain how the tool doing the scanning behave.


My preference is to either split and only commit the rules now or wait 
for the ECLAIR change to happen.


Cheers,

--
Julien Grall

[ovmf test] 185725: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6ced1e91eff13dae1bfba95734e2b34a73601db2
baseline version:
 ovmf 61185f1d501512f35621d0fdc5f17503c77bf449

Last test of basis   185701  2024-04-17 03:13:46 Z0 days
Testing same since   185725  2024-04-17 18:43:01 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Ray Ni 
  Tom Lendacky 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   61185f1d50..6ced1e91ef  6ced1e91eff13dae1bfba95734e2b34a73601db2 -> 
xen-tested-master

[XEN PATCH v3 2/2] eclair_analysis: deviate x86 emulator for Rule 16.2

[Nicola Vetrini]

MISRA C Rule 16.2 states:
"A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement".

Since complying with this rule of the x86 emulator would lead to
a lot of code duplication, it is deemed better to exempt those
files for this guideline.

No functional change.

Signed-off-by: Nicola Vetrini 
Acked-by: Stefano Stabellini 
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++
 docs/misra/deviations.rst| 6 ++
 2 files changed, 13 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 0230b41c6d1c..190f6a2fd4e0 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -358,6 +358,13 @@ therefore have the same behavior of a boolean"
 # Series 16.
 #
 
+-doc_begin="Complying with the Rule would entail a lot of code duplication in 
the implementation of the x86 emulator,
+therefore it is deemed better to leave such files as is."
+-file_tag+={x86_emulate,"^xen/arch/x86/x86_emulate/.*$"}
+-file_tag+={x86_svm_emulate,"^xen/arch/x86/hvm/svm/emulate\\.c$"}
+-config=MC3R1.R16.2,reports+={deliberate, 
"any_area(any_loc(file(x86_emulate||x86_svm_emulate)))"}
+-doc_end
+
 -doc_begin="Switch clauses ending with continue, goto, return statements are
 safe."
 -config=MC3R1.R16.3,terminals+={safe, 
"node(continue_stmt||goto_stmt||return_stmt)"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 32b02905d19a..ed0c1e8ed0bf 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -296,6 +296,12 @@ Deviations related to MISRA C:2012 Rules:
therefore have the same behavior of a boolean.
  - Project-wide deviation; tagged as `deliberate` for ECLAIR.
 
+   * - R16.2
+ - Complying with the Rule would entail a lot of code duplication in the
+   implementation of the x86 emulator, therefore it is deemed better to
+   leave such files as is.
+ - Tagged as `deliberate` for ECLAIR.
+
* - R16.3
  - Switch clauses ending with continue, goto, return statements are safe.
  - Tagged as `safe` for ECLAIR.
-- 
2.34.1

[XEN PATCH v3 0/2] address violations of MISRA C Rule 16.2

[Nicola Vetrini]

A respin of the last two patches from the previous series.
No changes other than the different SAF comment id because SAF-4-safe was
already taken.

Nicola Vetrini (2):
  xen/domctl: address violations of MISRA C Rule 16.2
  eclair_analysis: deviate x86 emulator for Rule 16.2

 automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++
 docs/misra/deviations.rst| 6 ++
 docs/misra/safe.json | 8 
 xen/common/domain.c  | 1 +
 4 files changed, 22 insertions(+)

-- 
2.34.1

[XEN PATCH v3 1/2] xen/domctl: address violations of MISRA C Rule 16.2

[Nicola Vetrini]

Refactor the first clauses so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
Note that the switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule 16.3.

Convert fallthrough comments in other clauses to the pseudo-keyword
while at it.

No functional change.

Signed-off-by: Nicola Vetrini 
Acked-by: Jan Beulich 
---
 docs/misra/safe.json | 8 
 xen/common/domain.c  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index fe2bc185097d..9b13bcf71706 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -44,6 +44,14 @@
 },
 {
 "id": "SAF-5-safe",
+"analyser": {
+"eclair": "MC3R1.R16.2"
+},
+"name": "MC3R1.R16.2: using a case label when the most 
closely-enclosing compound statement is not a switch statement",
+"text": "A switch label enclosed by some compound statement that 
is not the body of a switch is permitted within local helper macros that are 
unlikely to be misused or misunderstood."
+},
+{
+"id": "SAF-6-safe",
 "analyser": {},
 "name": "Sentinel",
 "text": "Next ID to be used"
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 282c3ab62308..1e555d658c97 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -457,6 +457,7 @@ static int domain_teardown(struct domain *d)
 
 for_each_vcpu ( d, v )
 {
+/* SAF-5-safe MISRA C Rule 16.2: switch label enclosed by for 
loop*/
 PROGRESS_VCPU(teardown);
 
 rc = vcpu_teardown(v);
-- 
2.34.1

[xen-4.15-testing test] 185709: tolerable FAIL - PUSHED

[osstest service owner]

flight 185709 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185709/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0a1c1a01a8028a929d460a966c8f8e7384f5b3a6
baseline version:
 xen  65eb8f32b6b82e0268a9d66b49da354bc6698e87

Last test of basis   185282  2024-04-09 12:06:43 Z8 days
Failing since185296  2024-04-10 06:02:43 Z7 days9 attempts
Testing same since   185709  2024-04-17 07:07:02 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Marek Marczykowski-Górecki 
  Roger Pau Monne 
  Roger Pau Monné 

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

Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Stefano Stabellini]

On Wed, 17 Apr 2024, Julien Grall wrote:
> Hi Stefano,
> 
> On 16/04/2024 20:27, Stefano Stabellini wrote:
> > Also add two specific project-wide deviations for R21.6 and R21.15.
> 
> In general, I am fine with add the two rules. However...
> 
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > index 32b02905d1..9123c8edb5 100644
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules:
> >  of the Rule due to uses of this macro.
> >- Tagged as `deliberate` for ECLAIR.
> >   +   * - R21.6
> > + - The use of snprintf() and vsnprintf() is justifiable as, despite
> > +   the fact that such functions have the same names of the
> > +   corresponding standard library functions, each configuration of
> > +   Xen has a unique implementation for them; the code implementing
> > +   such functions is subject to the analysis, so that any undefined
> > +   or unspecified behavior associated to them falls under the
> > +   responsibility of other MISRA guidelines
> > + - Tagged as `safe` for ECLAIR.
> 
> ... this implies that ECLAIR should be modified. But this is not happening in
> this patch. Looking at history, we tend to keep deviations.rst in sync with
> ECLAIR, so I think it should be updated here too.

That is true but I am not very familiar with Eclair config language so
it is better if that is done by the Bugseng team. I can merge their
patch into this one or vice versa or they could be committed separately
(keep in mind that the rule is not enabled in the ECLAIR scan so from a
Gitlab-CI point of view we don't require the change to the ECLAIR config
although it makes sense). I am happy either way. 

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Stefano Stabellini]

On Wed, 17 Apr 2024, Julien Grall wrote:
> Hi Michal,
> 
> On 17/04/2024 13:14, Michal Orzel wrote:
> > Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> > in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> > for it. This results in a build failure. Example on Arm:
> > 
> > ./include/public/arch-arm.h:205:41: error: unknown type name
> > ‘__guest_handle_64_int32_t’
> >205 | #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
> >| ^~
> > ./include/public/arch-arm.h:206:41: note: in expansion of macro
> > ‘__XEN_GUEST_HANDLE’
> >206 | #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
> >| ^~
> > ./include/public/memory.h:277:5: note: in expansion of macro
> > ‘XEN_GUEST_HANDLE’
> >277 | XEN_GUEST_HANDLE(int32_t) errs;
> > 
> > Fix it. Also, drop guest handle definition for int given no further use.
> > 
> > Fixes: afab29d0882f ("public: s/int/int32_t")
> > Signed-off-by: Michal Orzel 

Reviewed-by: Stefano Stabellini 


> So it turned out that I committed v1 from Stefano. I was meant to commit the
> patch at all, but I think I started with a dirty staging :(. Sorry for that.
> 
> I have reverted Stefano's commit for now so we can take the correct patch.
> 
> Now, from my understanding, Andrew suggested on Matrix that this solution may
> actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
> Maybe this can be folded in Stefano's patch?

v1 together with Michal's fix is correct. Also v2 alone is correct, or
v2 with Michal's fix is also correct.

My preference is v2 with Michal's fix, they can be committed as separate
patches. Also the others options are fine.

Re: [PATCH v2 4/6] gzip: refactor state tracking

[Andrew Cooper]

On 17/04/2024 3:37 pm, Daniel P. Smith wrote:
> diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
> index 1b448d6e3655..8178a05a0190 100644
> --- a/xen/common/gzip/gunzip.c
> +++ b/xen/common/gzip/gunzip.c
> @@ -4,18 +4,25 @@
>  #include 
>  #include 
>  
> -static unsigned char *__initdata window;
> -
>  #define WSIZE   0x8000U
>  
> -static unsigned char *__initdata inbuf;
> -static unsigned int __initdata insize;
> +struct gzip_state {
> +unsigned char *window;
> +
> +unsigned char *inbuf;
> +unsigned int insize;
> +
> +/* Index of next byte to be processed in inbuf: */
> +unsigned int inptr;

perform_gunzip() passes in an unsigned long size, which means it's
truncated in this state.

Please at least make these size_t.  Life is too short to deal with the
fallout of this going wrong.

>  
> -/* Index of next byte to be processed in inbuf: */
> -static unsigned int __initdata inptr;
> +/* Bytes in output buffer: */
> +unsigned int outcnt;

See later, but I think the comment for outcnt is wrong.

>  
> -/* Bytes in output buffer: */
> -static unsigned int __initdata outcnt;
> +long bytes_out;

See later, but I don't think this can be signed.  It's only used to
cross-check the header-reported length, which is done as an unsigned long.

> +
> +unsigned long bb;  /* bit buffer */
> +unsigned bk;   /* bits in bit buffer */

As this is effectively new code, "unsigned int" please.

> @@ -27,7 +34,7 @@ typedef unsigned char   uch;
>  typedef unsigned short  ush;
>  typedef unsigned long   ulg;
>  
> -#define get_byte()  (inptr < insize ? inbuf[inptr++] : fill_inbuf())
> +#define get_byte() (s->inptr < s->insize ? s->inbuf[s->inptr++] : 
> fill_inbuf())

This is a bit weird:
> $ git grep -w get_byte common/gzip
> common/gzip/gunzip.c:40:#define get_byte() (s->inptr < s->insize ?
> s->inbuf[s->inptr++] : fill_inbuf())
> common/gzip/inflate.c:224:#define NEXTBYTE(s)  ({ int v = get_byte();
> if (v < 0) goto underrun; (uch)v; })
> common/gzip/inflate.c:1131:    flags  = (uch)get_byte();

NEXTBYTE() gets an s parameter, but doesn't pass it to get_byte() and
instead relies on state always having the name 's' in scope.

I'd suggest turning get_byte() into a proper static function.  It will
be more readable that throwing extra ()'s around s in the existing macro.

Except...  fill_inbuf() is a fatal error anyway, so that can be folded
together to simplify the result.


> @@ -72,16 +78,16 @@ static __init void flush_window(void)
>  unsigned int n;
>  unsigned char *in, ch;
>  
> -in = window;
> -for ( n = 0; n < outcnt; n++ )
> +in = s->window;
> +for ( n = 0; n < s->outcnt; n++ )
>  {
>  ch = *in++;
>  c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
>  }
>  crc = c;
>  
> -bytes_out += (unsigned long)outcnt;
> -outcnt = 0;
> +s->bytes_out += (unsigned long)s->outcnt;

I can't figure out why this was written this way, even originally.

AFAICT, outcnt doesn't even match it's comment.

/* Bytes in output buffer: */

It looks like it's the number of bytes in window.  This also matches the
"wp" define which I guess is "window position".

Anyway, irrespective of naming, the cast is useless so lets drop it
while modifying the line.

> diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
> index 512d9bf0ee2e..5735bbcf7eb4 100644
> --- a/xen/common/gzip/inflate.c
> +++ b/xen/common/gzip/inflate.c
> @@ -119,7 +119,7 @@ static char rcsid[] = "#Id: inflate.c,v 0.14 1993/06/10 
> 13:27:04 jloup Exp #";
>  
>  #endif /* !__XEN__ */
>  
> -#define slide window
> +#define slide s->window

Given only 8 uses, I'd expand this in place and drop the macro.

But, there's an entire comment block discussing "slide" which I think is
wrong for Xen's implementation.  That wants to go too, I think.

>  
>  /*
>   * Huffman code lookup table entry--this entry is four bytes for machines
> @@ -143,12 +143,12 @@ struct huft {
>  static int huft_build OF((unsigned *, unsigned, unsigned,
>const ush *, const ush *, struct huft **, int *));
>  static int huft_free OF((struct huft *));
> -static int inflate_codes OF((struct huft *, struct huft *, int, int));
> -static int inflate_stored OF((void));
> -static int inflate_fixed OF((void));
> -static int inflate_dynamic OF((void));
> -static int inflate_block OF((int *));
> -static int inflate OF((void));
> +static int inflate_codes OF((struct gzip_state *, struct huft *, struct huft 
> *, int, int));
> +static int inflate_stored OF((struct gzip_state *));
> +static int inflate_fixed OF((struct gzip_state *));
> +static int inflate_dynamic OF((struct gzip_state *));
> +static int inflate_block OF((struct gzip_state *, int *));
> +static int inflate OF((struct gzip_state *));

These are the only users of OF, and it turns out it's a no-op macro. 
This code would be far-less WTF-worthy if it was expanded as part of

Re: [PATCH v3 6/9] xen/common: Move Arm's bootfdt.c to common

[Julien Grall]

Hi Shawn,

On 12/04/2024 03:53, Shawn Anastasio wrote:

Hi Julien,

On 3/21/24 12:50 PM, Julien Grall wrote:

Hi Shawn,

On 14/03/2024 22:15, Shawn Anastasio wrote:

Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.

Suggested-by: Julien Grall 
Signed-off-by: Shawn Anastasio 
Acked-by: Julien Grall 
---
Changes in v2:
- Drop #if defined(CONFIG_ARM_EFI) now that efi_enabled is stubbed

   MAINTAINERS| 1 +
   xen/arch/arm/Makefile  | 1 -
   xen/common/device-tree/Makefile| 1 +
   xen/{arch/arm => common/device-tree}/bootfdt.c | 0
   4 files changed, 2 insertions(+), 1 deletion(-)
   rename xen/{arch/arm => common/device-tree}/bootfdt.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index e85fbe6737..20fdec9ffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -251,6 +251,7 @@ S:Supported
   L:xen-devel@lists.xenproject.org
   F:docs/misc/arm/
   F:xen/arch/arm/
+F:xen/common/device-tree/bootfdt.c
   F:xen/drivers/char/arm-uart.c
   F:xen/drivers/char/cadence-uart.c
   F:xen/drivers/char/exynos4210-uart.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7b1350e2ef..9e1548378c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_TEE) += tee/
   obj-$(CONFIG_HAS_VPCI) += vpci.o

   obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
-obj-y += bootfdt.init.o
   obj-y += cpuerrata.o
   obj-y += cpufeature.o
   obj-y += decode.o
diff --git a/xen/common/device-tree/Makefile
b/xen/common/device-tree/Makefile
index c97b2bd88c..fa5beafd65 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1 +1,2 @@
+obj-y += bootfdt.init.o
   obj-y += bootinfo.o


Looking at the names, it is not entirely clear what would be the
differences between bootfdt and bootinfo. Should they just be one file?



With the current split I've chosen, all functions pertaining to managing
the `struct bootinfo` data structure are contained within bootinfo.c and
all functions responsible for parsing the FDT on boot are in bootfdt.c.

This separation exists currently in the ARM tree, but the bootinfo
functions are contained in setup.c rather than a separate self-contained
bootinfo.c.

If you feel strongly that we would be better off with everything in a
single file, I'm not necessarily opposed to that, but I do think that
this split at least makes sense.


I am fine with the split. It wasn't originally clear how this was done 
because the first comment in bootinfo contains:


 Early device tree parsing and bookkeeping routines.

But from what you wrote, it seems this is only meant to cover the latter 
part. Did I understand it correctly?


Cheers,

--
Julien Grall

Re: [PATCH v2 5/6] gzip: move crc state into consilidated gzip state

[Andrew Cooper]

On 17/04/2024 3:37 pm, Daniel P. Smith wrote:
> Signed-off-by: Daniel P. Smith 

The change in type is fine, but does need discussing.  Furthermore, ...

> diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
> index 8178a05a0190..bef324d3d166 100644
> --- a/xen/common/gzip/gunzip.c
> +++ b/xen/common/gzip/gunzip.c
> @@ -74,7 +77,7 @@ static __init void flush_window(struct gzip_state *s)
>   * The window is equal to the output buffer therefore only need to
>   * compute the crc.
>   */
> -unsigned long c = crc;
> +unsigned long c = s->crc;

... this wants to be unsigned int I think.

> diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
> index 5735bbcf7eb4..c18ce20210b0 100644
> --- a/xen/common/gzip/inflate.c
> +++ b/xen/common/gzip/inflate.c
> @@ -1063,16 +1063,14 @@ static int __init inflate(struct gzip_state *s)
>   *
>   **/
>  
> -static ulg __initdata crc_32_tab[256];
> -static ulg __initdata crc;  /* initialized in makecrc() so it'll reside in 
> bss */
> -#define CRC_VALUE (crc ^ 0xUL)
> +#define CRC_VALUE (s->crc ^ 0xUL)

$ git grep CRC_VALUE
common/gzip/inflate.c:1052:#define CRC_VALUE (s->crc ^ 0xUL)
common/gzip/inflate.c:1207:    if (orig_crc != CRC_VALUE) {

I'd expand this in it's single user, but like ...

>  
>  /*
>   * Code to compute the CRC-32 table. Borrowed from
>   * gzip-1.0.3/makecrc.c.
>   */
>  
> -static void __init makecrc(void)
> +static void __init makecrc(struct gzip_state *s)
>  {
>  /* Not copyrighted 1990 Mark Adler */
>  
> @@ -1089,7 +1087,7 @@ static void __init makecrc(void)
>  for (i = 0; i < sizeof(p)/sizeof(int); i++)
>  e |= 1L << (31 - p[i]);
>  
> -crc_32_tab[0] = 0;
> +s->crc_32_tab[0] = 0;
>  
>  for (i = 1; i < 256; i++)
>  {
> @@ -1100,11 +1098,11 @@ static void __init makecrc(void)
>  if (k & 1)
>  c ^= e;
>  }
> -crc_32_tab[i] = c;
> +s->crc_32_tab[i] = c;
>  }
>  
>  /* this is initialized here so this code could reside in ROM */
> -crc = (ulg)0xUL; /* shift register contents */
> +s->crc = (ulg)0xUL; /* shift register contents */

... this, the constant should become -1u or ~0u because of the type change.

I'm not sure what to make of the ROM comment, but I suspect it means the
XOR can be dropped with a bit of care too.

~Andrew

Re: [PATCH v2 3/6] gzip: remove custom memory allocator

[Andrew Cooper]

On 17/04/2024 3:37 pm, Daniel P. Smith wrote:
> All the other decompression routines use xmalloc_bytes(), thus there is no
> reason for gzip to be handling its own allocation of memory. In fact, there is
> a bug somewhere in the allocator as decompression started to break when adding
> additional allocations. Instead of troubleshooting the allocator, replace it
> with xmalloc_bytes().
>
> Signed-off-by: Daniel P. Smith 
> ---
>  xen/common/gzip/gunzip.c  | 17 ++
>  xen/common/gzip/inflate.c | 47 ---
>  2 files changed, 2 insertions(+), 62 deletions(-)

Good riddance.

Reviewed-by: Andrew Cooper 

Re: [PATCH v2 6/6] gzip: drop huffman code table tracking

[Andrew Cooper]

On 17/04/2024 3:37 pm, Daniel P. Smith wrote:
> The "tracking" bits does not appear to be used, so dropping from the code.
>
> Signed-off-by: Daniel P. Smith 
> ---
>  xen/common/gzip/inflate.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
> index c18ce20210b0..15bc187c2bbe 100644
> --- a/xen/common/gzip/inflate.c
> +++ b/xen/common/gzip/inflate.c
> @@ -264,8 +264,6 @@ static const int dbits = 6;  /* bits in base 
> distance lookup table */
>  #define BMAX 16 /* maximum bit length of any code (16 for explode) */
>  #define N_MAX 288   /* maximum number of codes in any set */
>  
> -static unsigned __initdata hufts;  /* track memory usage */
> -
>  /*
>   * Given a list of code lengths and a maximum table size, make a set of
>   * tables to decode that set of codes.  Return zero on success, one if
> @@ -445,7 +443,6 @@ static int __init huft_build(
>  goto out;
>  }
>  DEBG1("4 ");
> -hufts += z + 1; /* track memory usage */
>  *t = q + 1; /* link to list for huft_free() */
>  *(t = &(q->v.t)) = (struct huft *)NULL;
>  u[h] = ++q; /* table starts after link */
> @@ -1028,15 +1025,12 @@ static int __init inflate(struct gzip_state *s)
>  /* decompress until the last block */
>  h = 0;
>  do {
> -hufts = 0;
>  #ifdef ARCH_HAS_DECOMP_WDOG
>  arch_decomp_wdog();
>  #endif
>  r = inflate_block(s, );
>  if (r)
>  return r;
> -if (hufts > h)
> -h = hufts;
>  } while (!e);

With 'hufts' removed, the local variable 'h' is now dead too.  It gets
read inside an #ifdef DEBUG, but as it's rendering a unqualified number
to stderr, it can also be deleted.

Specifically, I recommend this additional delta:

diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index 15bc187c2bbe..13015bb45f4a 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1015,7 +1015,6 @@ static int __init inflate(struct gzip_state *s)
 {
 int e;    /* last block flag */
 int r;    /* result code */
-    unsigned h;   /* maximum struct huft's malloc'ed */
 
 /* initialize window, bit buffer */
 wp = 0;
@@ -1023,7 +1022,6 @@ static int __init inflate(struct gzip_state *s)
 s->bb = 0;
 
 /* decompress until the last block */
-    h = 0;
 do {
 #ifdef ARCH_HAS_DECOMP_WDOG
 arch_decomp_wdog();
@@ -1045,9 +1043,6 @@ static int __init inflate(struct gzip_state *s)
 flush_output(s, wp);
 
 /* return success */
-#ifdef DEBUG
-    fprintf(stderr, "<%u> ", h);
-#endif /* DEBUG */
 return 0;
 }
 

which I'm happy to fold on commit.

~Andrew

Re: [PATCH v2 1/6] gzip: drop unused define checks

[Andrew Cooper]

On 17/04/2024 3:37 pm, Daniel P. Smith wrote:
> Dropping the define checks for PKZIP_BUG_WORKAROUND and NOMEMCPY define as 
> they
> never are set.
>
> Signed-off-by: Daniel P. Smith 

It looks like ARCH_HAS_DECOMP_WDOG is another one that can go.

There's only a single instance, in inflate(), which I'm happy to fold on
commit.

~Andrew

Re: [PATCH v2 1/2] x86: Add support for building a multiboot2 PE binary

[Jan Beulich]

On 17.04.2024 17:05, Ross Lagerwall wrote:
> On Wed, Apr 17, 2024 at 3:15 PM Jan Beulich  wrote:
>>
>> On 10.04.2024 11:41, Ross Lagerwall wrote:
>>> On Mon, Apr 8, 2024 at 11:25 AM Jan Beulich  wrote:
 On 28.03.2024 16:11, Ross Lagerwall wrote:
> * The image base address is set to 0 since it must necessarily be below
>   4 GiB and the loader will relocate it anyway.

 While technically okay, what is the reason for this adjustment?
>>>
>>> The multiboot2 spec generally uses 32 bit addresses for everything and
>>> says:
>>>
>>> "The bootloader must not load any part of the kernel, the modules, the
>>> Multiboot2 information structure, etc. higher than 4 GiB - 1."
>>>
>>> An image base address above 4 GiB causes trouble because multiboot2
>>> wasn't designed for this.
>>
>> Yet mb2 doesn't care about that PE header field at all, does it? In which
>> case my question remains: What purpose does this particular modification
>> of the image have?
>>
> 
> With the currently published version of mb2, it doesn't look at the PE
> header field since it has no knowledge about PE binaries.
> 
> With the proposal on the grub-devel list [1], mb2 would use the PE
> header to load the new xen-mbi binary in which case, the image base
> address is indeed relevant.

But then how can you strip .reloc? If the image base field is to be used,
and if the image can't be placed there, relocation needs to happen. (As
an aside, [1] looks to be talking of the entry point only, not the image
base?)

Jan

> [1] https://lists.gnu.org/archive/html/grub-devel/2024-03/msg00081.html

Re: [PATCH v2] libxl: Enable stubdom cdrom changing

[Anthony PERARD]

On Sun, Apr 07, 2024 at 10:36:33AM -0400, Jason Andryuk wrote:
> diff --git a/tools/libs/light/libxl_disk.c b/tools/libs/light/libxl_disk.c
> index fa7856f28c..819d34933b 100644
> --- a/tools/libs/light/libxl_disk.c
> +++ b/tools/libs/light/libxl_disk.c
> @@ -829,21 +829,122 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t 
> domid,
>  return rc;
>  }
>  
> +/*
> + * Search through the query-fdsets JSON looking for a matching devid.
> + *
> + * If found, return the fdset-id integer (>=0).
> + *
> + * If not found, return ERROR_NOTFOUND.
> + *
> + * On error, return libxl ERROR_*.
> + */
> +static int query_fdsets_find_fdset(libxl__gc *gc,
> +   const libxl__json_object *response,
> +   int devid)
> +{
> +const libxl__json_object *fdset;
> +const char *needle = GCSPRINTF("stub-devid:%d", devid);
> +int i, j, rc;
> +
> +/* query-fdsets returns:
> + * [
> + *   { "fds": [
> + *   { "fd": 30,
> + * "opaque": "stub-devid:2080"
> + *   }
> + * ],
> + * "fdset-id": 1
> + *   }
> + * ]
> + */
> +for (i = 0; (fdset = libxl__json_array_get(response, i)); i++) {
> +const libxl__json_object *fdset_id;
> +const libxl__json_object *fds;
> +const libxl__json_object *fd;
> +
> +fdset_id = libxl__json_map_get("fdset-id", fdset, JSON_INTEGER);
> +if (!fdset_id) {
> +rc = ERROR_QEMU_API;
> +goto out;
> +}
> +LOG(DEBUG, "fdset-id=%lld", 
> libxl__json_object_get_integer(fdset_id));

This feels like we are going to have a log of logging about information
that isn't going to be used by libxl. Also, an fdset-id is also logged
by the caller of this function. (But even there, it might not be
useful).

When debugging, it might be more helpful to run `query-fdset` by hand
than having libxl listing every possible fdset.

> +fds = libxl__json_map_get("fds", fdset, JSON_ARRAY);
> +if (!fds) {
> +rc = ERROR_QEMU_API;
> +goto out;
> +}
> +for (j = 0; (fd = libxl__json_array_get(fds, j)); j++) {
> +const libxl__json_object *fd_num;
> +const libxl__json_object *opaque;
> +const char *opaque_str;
> +
> +fd_num = libxl__json_map_get("fd", fd, JSON_INTEGER);
> +if (!fd_num) {
> +rc = ERROR_QEMU_API;
> +goto out;
> +}
> +opaque = libxl__json_map_get("opaque", fd, JSON_STRING);
> +if (!opaque) {
> +continue;
> +}
> +
> +opaque_str = libxl__json_object_get_string(opaque);
> +LOG(DEBUG, "fd=%lld opaque='%s'",
> +libxl__json_object_get_integer(fd_num), opaque_str);

This logging is also probably too verbose. First, libxl never care about
which fd QEMU is using, second, if the opaque doesn't match, it is
probably not the one we want, and the needed one is just missing.

By the way, there's a big hammer that can pottentiolly be used when
debuging QMP interaction, rebuild libxl with -DDEBUG_QMP_CLIENT, this will
log every QMP command sent and received.

> +if (strcmp(opaque_str, needle) == 0) {
> +return libxl__json_object_get_integer(fdset_id);
> +}
> +}
> +}
> +rc = ERROR_NOTFOUND;
> +
> + out:
> +return rc;
> +}
> +
>  typedef struct {
>  libxl__ao *ao;
> +libxl__ao_device aodev;
>  libxl_domid domid;
> +libxl_domid disk_domid;
>  libxl_device_disk *disk;
>  libxl_device_disk disk_saved;
>  libxl__ev_slowlock qmp_lock;
>  int dm_ver;
>  libxl__ev_time time;
> +libxl__ev_time timeout_retry;

`timeout_retry` sounds to me that we are adding a timeout for a retry,
but it is used the opposite way, as a timer to wait until we retry. How
about naming this filed "retry_timer" instead?

Ah, I see you've added a similar field named "timeout_retries" in
libxl_pci.c in the past, but I did introduce a "retry_timer" field in
that same file before. So either is fine even if I've got a preference.

>  libxl__ev_qmp qmp;
> +int retries;
> +int stubdom_fdset;
>  } libxl__cdrom_insert_state;
>  
>  static void cdrom_insert_lock_acquired(libxl__egc *, libxl__ev_slowlock *,
> int rc);
>  static void cdrom_insert_qmp_connected(libxl__egc *, libxl__ev_qmp *,
> const libxl__json_object *, int rc);
> +static void cdrom_insert_stubdom_query_fdset_rm(libxl__egc *egc,
> +libxl__ev_qmp *qmp,
> +const libxl__json_object 
> *resp,
> +int rc);
> +static void cdrom_insert_stubdom_parse_fdset_rm(libxl__egc *egc,
> +

Re: [XEN PATCH] automation/eclair_analysis: substitute deprecated service

[Julien Grall]

On 17/04/2024 16:05, Nicola Vetrini wrote:

On 2024-04-17 16:57, Julien Grall wrote:

Hi Nicola,

On 17/04/2024 15:51, Nicola Vetrini wrote:

The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.


I am guessing this is not a new feature and the current ECLAIR version 
is supporting it?


Cheers,



Yes, it was just an oversight to leave the old emptrcd there. It will 
eventually be phased out in the next release.


Thanks for confirming!

I don't have a way to test ECLAIR or any knowledge. But if you need an ack:

Acked-by: Julien Grall 

Cheers,






No functional change.

Signed-off-by: Nicola Vetrini 
---
  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
b/automation/eclair_analysis/ECLAIR/toolchain.ecl

index 71a1e2cce029..86e9a79b5231 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
  -doc_end
    -doc_begin="See Section \"6.19 Structures with No Members\" of 
"GCC_MANUAL"."

--config=STD.emptrecd,behavior+={c99,GCC_ARM64,specified}
--config=STD.emptrecd,behavior+={c99,GCC_X86_64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_ARM64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_X86_64,specified}
  -doc_end
    -doc_begin="See Section \"6.18 Arrays of Length Zero\" of 
"GCC_MANUAL"."




--
Julien Grall

[xen-4.18-testing test] 185705: regressions - FAIL

[osstest service owner]

flight 185705 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185705/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build   fail in 185695 REGR. vs. 185285

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-raw 21 guest-start/debian.repeat fail in 185695 pass in 
185705
 test-amd64-amd64-qemuu-freebsd12-amd64 19 guest-localmigrate/x10 fail pass in 
185695

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

Re: [PATCH v2 1/2] x86: Add support for building a multiboot2 PE binary

[Ross Lagerwall]

On Wed, Apr 17, 2024 at 3:15 PM Jan Beulich  wrote:
>
> On 10.04.2024 11:41, Ross Lagerwall wrote:
> > On Mon, Apr 8, 2024 at 11:25 AM Jan Beulich  wrote:
> >> On 28.03.2024 16:11, Ross Lagerwall wrote:
> >>> * The image base address is set to 0 since it must necessarily be below
> >>>   4 GiB and the loader will relocate it anyway.
> >>
> >> While technically okay, what is the reason for this adjustment?
> >
> > The multiboot2 spec generally uses 32 bit addresses for everything and
> > says:
> >
> > "The bootloader must not load any part of the kernel, the modules, the
> > Multiboot2 information structure, etc. higher than 4 GiB - 1."
> >
> > An image base address above 4 GiB causes trouble because multiboot2
> > wasn't designed for this.
>
> Yet mb2 doesn't care about that PE header field at all, does it? In which
> case my question remains: What purpose does this particular modification
> of the image have?
>

With the currently published version of mb2, it doesn't look at the PE
header field since it has no knowledge about PE binaries.

With the proposal on the grub-devel list [1], mb2 would use the PE
header to load the new xen-mbi binary in which case, the image base
address is indeed relevant.

Ross

[1] https://lists.gnu.org/archive/html/grub-devel/2024-03/msg00081.html

Re: [XEN PATCH] automation/eclair_analysis: substitute deprecated service

[Nicola Vetrini]

On 2024-04-17 16:57, Julien Grall wrote:

Hi Nicola,

On 17/04/2024 15:51, Nicola Vetrini wrote:

The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.


I am guessing this is not a new feature and the current ECLAIR version 
is supporting it?


Cheers,



Yes, it was just an oversight to leave the old emptrcd there. It will 
eventually be phased out in the next release.




No functional change.

Signed-off-by: Nicola Vetrini 
---
  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
b/automation/eclair_analysis/ECLAIR/toolchain.ecl

index 71a1e2cce029..86e9a79b5231 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
  -doc_end
-doc_begin="See Section \"6.19 Structures with No Members\" of 
"GCC_MANUAL"."

--config=STD.emptrecd,behavior+={c99,GCC_ARM64,specified}
--config=STD.emptrecd,behavior+={c99,GCC_X86_64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_ARM64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_X86_64,specified}
  -doc_end
-doc_begin="See Section \"6.18 Arrays of Length Zero\" of 
"GCC_MANUAL"."


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

Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Julien Grall]

Hi Stefano,

On 16/04/2024 20:27, Stefano Stabellini wrote:

Also add two specific project-wide deviations for R21.6 and R21.15.


In general, I am fine with add the two rules. However...



Signed-off-by: Stefano Stabellini 

diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 32b02905d1..9123c8edb5 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules:
 of the Rule due to uses of this macro.
   - Tagged as `deliberate` for ECLAIR.
  
+   * - R21.6

+ - The use of snprintf() and vsnprintf() is justifiable as, despite
+   the fact that such functions have the same names of the
+   corresponding standard library functions, each configuration of
+   Xen has a unique implementation for them; the code implementing
+   such functions is subject to the analysis, so that any undefined
+   or unspecified behavior associated to them falls under the
+   responsibility of other MISRA guidelines
+ - Tagged as `safe` for ECLAIR.


... this implies that ECLAIR should be modified. But this is not 
happening in this patch. Looking at history, we tend to keep 
deviations.rst in sync with ECLAIR, so I think it should be updated here 
too.


Cheers,

--
Julien Grall

Re: [XEN PATCH V1] x86/ucode: optional amd/intel ucode build & load

[Jan Beulich]

On 09.04.2024 23:49, Stefano Stabellini wrote:
> On Tue, 9 Apr 2024, Sergiy Kibrik wrote:
>> 05.04.24 13:57, Andrew Cooper:
>>> On 05/04/2024 11:30 am, Sergiy Kibrik wrote:
 Introduce configuration variables to make it possible to selectively turn
 on/off CPU microcode management code in the build for AMD and Intel CPUs.

 This is to allow build configuration for a specific CPU, not compile and
 load what will not be used anyway.

 Signed-off-by: Sergiy Kibrik 
>>>
>>> Hmm... Stefano didn't check up with me first.
>>>
>>> _https://lore.kernel.org/xen-devel/20231027191926.3283871-1-andrew.coop...@citrix.com/
>>>
>>> I've already got a series out for this, although its blocked on naming
>>> and IMO, particularly unhelpful replies.  I've not had time to apply the
>>> community-resolution vote on naming issues.  (Also, you should be CC-ing
>>> Roger on x86 patches).

I can't remain silent here. Roger has now changed his mind, so formally
things are correct. Yet judging from the earlier example where Roger
was agreeing with you, shouldn't it have been this time the other way
around: A majority was of different opinion than you, and you should
have accepted that? Instead you've waited for a time when I was away,
got Stefano to agree and Roger to change his mind, and once again you
got what you want. It feels increasingly like not everyone among the
REST maintainers and not everyone among the x86 ones are equal.

Jan

>> + Stefano & Roger
>>
>> should we revisit this series then?
> 
> Yes, I replied. I think there are three naming options:
> 
> Option-1)
> CONFIG_{AMD,INTEL}
> nothing else
> 
> Option-2)
> CONFIG_{AMD,INTEL}_IOMMU
> CONFIG_{AMD,INTEL} selects CONFIG_{AMD,INTEL}_IOMMU
> 
> Option-3)
> CONFIG_{AMD,INTEL}_IOMMU
> CONFIG_{AMD,INTEL}_CPU
> CONFIG_{AMD,INTEL} selects both CPU and IOMMU options
> 
> 
> My preference is Option-1 (best), Option-3, Option-2 (worse)
> 
> I am fine with anything but please let move this forward.

Re: [XEN PATCH] automation/eclair_analysis: substitute deprecated service

[Julien Grall]

Hi Nicola,

On 17/04/2024 15:51, Nicola Vetrini wrote:

The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.


I am guessing this is not a new feature and the current ECLAIR version 
is supporting it?


Cheers,



No functional change.

Signed-off-by: Nicola Vetrini 
---
  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 71a1e2cce029..86e9a79b5231 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
  -doc_end
  
  -doc_begin="See Section \"6.19 Structures with No Members\" of "GCC_MANUAL"."

--config=STD.emptrecd,behavior+={c99,GCC_ARM64,specified}
--config=STD.emptrecd,behavior+={c99,GCC_X86_64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_ARM64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_X86_64,specified}
  -doc_end
  
  -doc_begin="See Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL"."


--
Julien Grall

[XEN PATCH] automation/eclair_analysis: substitute deprecated service

[Nicola Vetrini]

The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.

No functional change.

Signed-off-by: Nicola Vetrini 
---
 automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 71a1e2cce029..86e9a79b5231 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
 -doc_end
 
 -doc_begin="See Section \"6.19 Structures with No Members\" of "GCC_MANUAL"."
--config=STD.emptrecd,behavior+={c99,GCC_ARM64,specified}
--config=STD.emptrecd,behavior+={c99,GCC_X86_64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_ARM64,specified}
+-config=STD.anonstct,behavior+={c99,GCC_X86_64,specified}
 -doc_end
 
 -doc_begin="See Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL"."
-- 
2.34.1

Re: [XEN PATCH v1 00/15] x86: make cpu virtualization support configurable

[Jan Beulich]

On 16.04.2024 08:18, Sergiy Kibrik wrote:
> This series aims to continue what Xenia started a year ago:
> 
> https://lore.kernel.org/xen-devel/20230213145751.1047236-1-burzalod...@gmail.com/
> 
> Here's an attempt to provide a means to render the cpu virtualization
> technology support in Xen configurable.
> Currently, irrespectively of the target platform, both AMD-V and Intel VT-x
> drivers are built.
> The series adds two new Kconfig controls, SVM and VMX, that can be
> used to switch to a finer-grained configuration for a given platform, and
> reduce dead code.
> 
> The code separation is done using the new config guards.
> 
> Since the initial RFC series felt rather welcomed, I took a courage naming
> it v1 and continuing from there. New changes are:
> 
> v1:
>  * changed Kconfig options naming
>  * use IS_ENABLED() instead of #ifdef where possible
>  * move altp2m code apart from p2m & hide under VMX option
>  * introduce helper in cpu_has_vmx_* macros
>  * and address other comments from Jan
> 
> Sergiy Kibrik (6):
>   x86/monitor: guard altp2m usage
>   x86/p2m: guard altp2m init/teardown
>   x86/p2m: move altp2m-related code to separate file
>   x86/p2m: guard altp2m code with CONFIG_VMX option
>   x86/vpmu: separate amd/intel vPMU code
>   x86/vmx: introduce helper function for vmcs macro
> 
> Xenia Ragiadakou (9):
>   x86: introduce AMD-V and Intel VT-x Kconfig options
>   x86/hvm: guard AMD-V and Intel VT-x hvm_function_table initializers
>   x86/p2m: guard vmx specific ept functions with CONFIG_VMX
>   x86/traps: guard vmx specific functions with CONFIG_VMX
>   x86/domain: guard svm specific functions with CONFIG_SVM
>   x86/oprofile: guard svm specific symbols with CONFIG_SVM
>   x86: wire cpu_has_{svm/vmx}_* to false when svm/vmx not enabled
>   x86/ioreq: guard VIO_realmode_completion with CONFIG_VMX
>   x86/hvm: make AMD-V and Intel VT-x support configurable

Going forward, can you please make sure you send patch series as threads
(i.e. individual patches with Reply-to: referencing the cover letter)?

Jan

[PATCH v2 5/6] gzip: move crc state into consilidated gzip state

[Daniel P. Smith]

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/gunzip.c  | 11 +++
 xen/common/gzip/inflate.c | 12 +---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 8178a05a0190..bef324d3d166 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -22,6 +22,9 @@ struct gzip_state {
 
 unsigned long bb;  /* bit buffer */
 unsigned bk;   /* bits in bit buffer */
+
+uint32_t crc_32_tab[256];
+uint32_t crc;
 };
 
 #define OF(args)args
@@ -74,7 +77,7 @@ static __init void flush_window(struct gzip_state *s)
  * The window is equal to the output buffer therefore only need to
  * compute the crc.
  */
-unsigned long c = crc;
+unsigned long c = s->crc;
 unsigned int n;
 unsigned char *in, ch;
 
@@ -82,9 +85,9 @@ static __init void flush_window(struct gzip_state *s)
 for ( n = 0; n < s->outcnt; n++ )
 {
 ch = *in++;
-c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
+c = s->crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
 }
-crc = c;
+s->crc = c;
 
 s->bytes_out += (unsigned long)s->outcnt;
 s->outcnt = 0;
@@ -121,7 +124,7 @@ __init int perform_gunzip(char *output, char *image, 
unsigned long image_len)
 s->inptr = 0;
 s->bytes_out = 0;
 
-makecrc();
+makecrc(s);
 
 if ( gunzip(s) < 0 )
 {
diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index 5735bbcf7eb4..c18ce20210b0 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1063,16 +1063,14 @@ static int __init inflate(struct gzip_state *s)
  *
  **/
 
-static ulg __initdata crc_32_tab[256];
-static ulg __initdata crc;  /* initialized in makecrc() so it'll reside in bss 
*/
-#define CRC_VALUE (crc ^ 0xUL)
+#define CRC_VALUE (s->crc ^ 0xUL)
 
 /*
  * Code to compute the CRC-32 table. Borrowed from
  * gzip-1.0.3/makecrc.c.
  */
 
-static void __init makecrc(void)
+static void __init makecrc(struct gzip_state *s)
 {
 /* Not copyrighted 1990 Mark Adler */
 
@@ -1089,7 +1087,7 @@ static void __init makecrc(void)
 for (i = 0; i < sizeof(p)/sizeof(int); i++)
 e |= 1L << (31 - p[i]);
 
-crc_32_tab[0] = 0;
+s->crc_32_tab[0] = 0;
 
 for (i = 1; i < 256; i++)
 {
@@ -1100,11 +1098,11 @@ static void __init makecrc(void)
 if (k & 1)
 c ^= e;
 }
-crc_32_tab[i] = c;
+s->crc_32_tab[i] = c;
 }
 
 /* this is initialized here so this code could reside in ROM */
-crc = (ulg)0xUL; /* shift register contents */
+s->crc = (ulg)0xUL; /* shift register contents */
 }
 
 /* gzip flag byte */
-- 
2.30.2

[PATCH v2 6/6] gzip: drop huffman code table tracking

[Daniel P. Smith]

The "tracking" bits does not appear to be used, so dropping from the code.

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/inflate.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index c18ce20210b0..15bc187c2bbe 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -264,8 +264,6 @@ static const int dbits = 6;  /* bits in base 
distance lookup table */
 #define BMAX 16 /* maximum bit length of any code (16 for explode) */
 #define N_MAX 288   /* maximum number of codes in any set */
 
-static unsigned __initdata hufts;  /* track memory usage */
-
 /*
  * Given a list of code lengths and a maximum table size, make a set of
  * tables to decode that set of codes.  Return zero on success, one if
@@ -445,7 +443,6 @@ static int __init huft_build(
 goto out;
 }
 DEBG1("4 ");
-hufts += z + 1; /* track memory usage */
 *t = q + 1; /* link to list for huft_free() */
 *(t = &(q->v.t)) = (struct huft *)NULL;
 u[h] = ++q; /* table starts after link */
@@ -1028,15 +1025,12 @@ static int __init inflate(struct gzip_state *s)
 /* decompress until the last block */
 h = 0;
 do {
-hufts = 0;
 #ifdef ARCH_HAS_DECOMP_WDOG
 arch_decomp_wdog();
 #endif
 r = inflate_block(s, );
 if (r)
 return r;
-if (hufts > h)
-h = hufts;
 } while (!e);
 
 /* Undo too much lookahead. The next read will be byte aligned so we
-- 
2.30.2

[PATCH v2 4/6] gzip: refactor state tracking

[Daniel P. Smith]

Move the core state into struct gzip_data to allow a per decompression
instance.

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/gunzip.c  |  55 +++-
 xen/common/gzip/inflate.c | 174 +++---
 2 files changed, 120 insertions(+), 109 deletions(-)

diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 1b448d6e3655..8178a05a0190 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -4,18 +4,25 @@
 #include 
 #include 
 
-static unsigned char *__initdata window;
-
 #define WSIZE   0x8000U
 
-static unsigned char *__initdata inbuf;
-static unsigned int __initdata insize;
+struct gzip_state {
+unsigned char *window;
+
+unsigned char *inbuf;
+unsigned int insize;
+
+/* Index of next byte to be processed in inbuf: */
+unsigned int inptr;
 
-/* Index of next byte to be processed in inbuf: */
-static unsigned int __initdata inptr;
+/* Bytes in output buffer: */
+unsigned int outcnt;
 
-/* Bytes in output buffer: */
-static unsigned int __initdata outcnt;
+long bytes_out;
+
+unsigned long bb;  /* bit buffer */
+unsigned bk;   /* bits in bit buffer */
+};
 
 #define OF(args)args
 
@@ -27,7 +34,7 @@ typedef unsigned char   uch;
 typedef unsigned short  ush;
 typedef unsigned long   ulg;
 
-#define get_byte()  (inptr < insize ? inbuf[inptr++] : fill_inbuf())
+#define get_byte() (s->inptr < s->insize ? s->inbuf[s->inptr++] : 
fill_inbuf())
 
 /* Diagnostic functions */
 #ifdef DEBUG
@@ -46,8 +53,7 @@ typedef unsigned long   ulg;
 #  define Tracecv(c, x)
 #endif
 
-static long __initdata bytes_out;
-static void flush_window(void);
+static void flush_window(struct gzip_state *s);
 
 static __init void error(const char *x)
 {
@@ -62,7 +68,7 @@ static __init int fill_inbuf(void)
 
 #include "inflate.c"
 
-static __init void flush_window(void)
+static __init void flush_window(struct gzip_state *s)
 {
 /*
  * The window is equal to the output buffer therefore only need to
@@ -72,16 +78,16 @@ static __init void flush_window(void)
 unsigned int n;
 unsigned char *in, ch;
 
-in = window;
-for ( n = 0; n < outcnt; n++ )
+in = s->window;
+for ( n = 0; n < s->outcnt; n++ )
 {
 ch = *in++;
 c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
 }
 crc = c;
 
-bytes_out += (unsigned long)outcnt;
-outcnt = 0;
+s->bytes_out += (unsigned long)s->outcnt;
+s->outcnt = 0;
 }
 
 __init int gzip_check(char *image, unsigned long image_len)
@@ -99,20 +105,25 @@ __init int gzip_check(char *image, unsigned long image_len)
 
 __init int perform_gunzip(char *output, char *image, unsigned long image_len)
 {
+struct gzip_state *s;
 int rc;
 
 if ( !gzip_check(image, image_len) )
 return 1;
 
-window = (unsigned char *)output;
-inbuf = (unsigned char *)image;
-insize = image_len;
-inptr = 0;
-bytes_out = 0;
+s = (struct gzip_state *)malloc(sizeof(struct gzip_state));
+if ( !s )
+return -ENOMEM;
+
+s->window = (unsigned char *)output;
+s->inbuf = (unsigned char *)image;
+s->insize = image_len;
+s->inptr = 0;
+s->bytes_out = 0;
 
 makecrc();
 
-if ( gunzip() < 0 )
+if ( gunzip(s) < 0 )
 {
 rc = -EINVAL;
 }
diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index 512d9bf0ee2e..5735bbcf7eb4 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -119,7 +119,7 @@ static char rcsid[] = "#Id: inflate.c,v 0.14 1993/06/10 
13:27:04 jloup Exp #";
 
 #endif /* !__XEN__ */
 
-#define slide window
+#define slide s->window
 
 /*
  * Huffman code lookup table entry--this entry is four bytes for machines
@@ -143,12 +143,12 @@ struct huft {
 static int huft_build OF((unsigned *, unsigned, unsigned,
   const ush *, const ush *, struct huft **, int *));
 static int huft_free OF((struct huft *));
-static int inflate_codes OF((struct huft *, struct huft *, int, int));
-static int inflate_stored OF((void));
-static int inflate_fixed OF((void));
-static int inflate_dynamic OF((void));
-static int inflate_block OF((int *));
-static int inflate OF((void));
+static int inflate_codes OF((struct gzip_state *, struct huft *, struct huft 
*, int, int));
+static int inflate_stored OF((struct gzip_state *));
+static int inflate_fixed OF((struct gzip_state *));
+static int inflate_dynamic OF((struct gzip_state *));
+static int inflate_block OF((struct gzip_state *, int *));
+static int inflate OF((struct gzip_state *));
 
 /*
  * The inflate algorithm uses a sliding 32 K byte window on the uncompressed
@@ -162,8 +162,8 @@ static int inflate OF((void));
  * must be in unzip.h, included above.
  */
 /* unsigned wp; current position in slide */
-#define wp outcnt
-#define flush_output(w) (wp=(w),flush_window())
+#define wp s->outcnt
+#define flush_output(s, w) (wp=(w),flush_window(s))
 
 

[PATCH v2 3/6] gzip: remove custom memory allocator

[Daniel P. Smith]

All the other decompression routines use xmalloc_bytes(), thus there is no
reason for gzip to be handling its own allocation of memory. In fact, there is
a bug somewhere in the allocator as decompression started to break when adding
additional allocations. Instead of troubleshooting the allocator, replace it
with xmalloc_bytes().

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/gunzip.c  | 17 ++
 xen/common/gzip/inflate.c | 47 ---
 2 files changed, 2 insertions(+), 62 deletions(-)

diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 1bcb007395ba..1b448d6e3655 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -4,12 +4,7 @@
 #include 
 #include 
 
-#define HEAPORDER 3
-
 static unsigned char *__initdata window;
-#define memptr long
-static memptr __initdata free_mem_ptr;
-static memptr __initdata free_mem_end_ptr;
 
 #define WSIZE   0x8000U
 
@@ -24,6 +19,8 @@ static unsigned int __initdata outcnt;
 
 #define OF(args)args
 
+#define malloc(a)   xmalloc_bytes(a)
+#define free(a) xfree(a)
 #define memzero(s, n)   memset((s), 0, (n))
 
 typedef unsigned char   uch;
@@ -108,14 +105,6 @@ __init int perform_gunzip(char *output, char *image, 
unsigned long image_len)
 return 1;
 
 window = (unsigned char *)output;
-
-free_mem_ptr = (unsigned long)alloc_xenheap_pages(HEAPORDER, 0);
-if ( !free_mem_ptr )
-return -ENOMEM;
-
-free_mem_end_ptr = free_mem_ptr + (PAGE_SIZE << HEAPORDER);
-init_allocator();
-
 inbuf = (unsigned char *)image;
 insize = image_len;
 inptr = 0;
@@ -132,8 +121,6 @@ __init int perform_gunzip(char *output, char *image, 
unsigned long image_len)
 rc = 0;
 }
 
-free_xenheap_pages((void *)free_mem_ptr, HEAPORDER);
-
 return rc;
 }
 
diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index 73ccfc2bdc6c..512d9bf0ee2e 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -228,53 +228,6 @@ static const ush mask_bits[] = {
 #define NEEDBITS(n) {while(k<(n)){b|=((ulg)NEXTBYTE())<>=(n);k-=(n);}
 
-#ifndef NO_INFLATE_MALLOC
-/*
- * A trivial malloc implementation, adapted from
- *  malloc by Hannu Savolainen 1993 and Matthias Urlichs 1994
- */
-
-static unsigned long __initdata malloc_ptr;
-static int __initdata malloc_count;
-
-static void __init init_allocator(void)
-{
-malloc_ptr = free_mem_ptr;
-malloc_count = 0;
-}
-
-static void *__init malloc(int size)
-{
-void *p;
-
-if (size < 0)
-error("Malloc error");
-if (!malloc_ptr)
-malloc_ptr = free_mem_ptr;
-
-malloc_ptr = (malloc_ptr + 3) & ~3; /* Align */
-
-p = (void *)malloc_ptr;
-malloc_ptr += size;
-
-if (free_mem_end_ptr && malloc_ptr >= free_mem_end_ptr)
-error("Out of memory");
-
-malloc_count++;
-return p;
-}
-
-static void __init free(void *where)
-{
-malloc_count--;
-if (!malloc_count)
-malloc_ptr = free_mem_ptr;
-}
-#else
-#define malloc(a) kmalloc(a, GFP_KERNEL)
-#define free(a) kfree(a)
-#endif
-
 /*
  * Huffman code decoding is performed using a multi-level table lookup.
  * The fastest way to decode is to simply build a lookup table whose
-- 
2.30.2

[PATCH v2 2/6] gzip: clean up comments and fix code alignment

[Daniel P. Smith]

This commit cleans up the comments and fixes the code alignment using Xen
coding style. This is done to make the code more legible before refactoring.

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/gunzip.c  |  10 +-
 xen/common/gzip/inflate.c | 790 +++---
 2 files changed, 405 insertions(+), 395 deletions(-)

diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 2c6eae167d54..1bcb007395ba 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -63,7 +63,6 @@ static __init int fill_inbuf(void)
 return 0;
 }
 
-
 #include "inflate.c"
 
 static __init void flush_window(void)
@@ -137,3 +136,12 @@ __init int perform_gunzip(char *output, char *image, 
unsigned long image_len)
 
 return rc;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index e95db2de4d9b..73ccfc2bdc6c 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1,11 +1,13 @@
 #define DEBG(x)
 #define DEBG1(x)
-/* inflate.c -- Not copyrighted 1992 by Mark Adler
-   version c10p1, 10 January 1993 */
+/*
+ * inflate.c -- Not copyrighted 1992 by Mark Adler
+ * version c10p1, 10 January 1993
+ */
 
-/* 
+/*
  * Adapted for booting Linux by Hannu Savolainen 1993
- * based on gzip-1.0.3 
+ * based on gzip-1.0.3
  *
  * Nicolas Pitre , 1999/04/14 :
  *   Little mods for all variable to reside either into rodata or bss segments
@@ -15,92 +17,91 @@
  */
 
 /*
-   Inflate deflated (PKZIP's method 8 compressed) data.  The compression
-   method searches for as much of the current string of bytes (up to a
-   length of 258) in the previous 32 K bytes.  If it doesn't find any
-   matches (of at least length 3), it codes the next byte.  Otherwise, it
-   codes the length of the matched string and its distance backwards from
-   the current position.  There is a single Huffman code that codes both
-   single bytes (called "literals") and match lengths.  A second Huffman
-   code codes the distance information, which follows a length code.  Each
-   length or distance code actually represents a base value and a number
-   of "extra" (sometimes zero) bits to get to add to the base value.  At
-   the end of each deflated block is a special end-of-block (EOB) literal/
-   length code.  The decoding process is basically: get a literal/length
-   code; if EOB then done; if a literal, emit the decoded byte; if a
-   length then get the distance and emit the referred-to bytes from the
-   sliding window of previously emitted data.
-
-   There are (currently) three kinds of inflate blocks: stored, fixed, and
-   dynamic.  The compressor deals with some chunk of data at a time, and
-   decides which method to use on a chunk-by-chunk basis.  A chunk might
-   typically be 32 K or 64 K.  If the chunk is incompressible, then the
-   "stored" method is used.  In this case, the bytes are simply stored as
-   is, eight bits per byte, with none of the above coding.  The bytes are
-   preceded by a count, since there is no longer an EOB code.
-
-   If the data is compressible, then either the fixed or dynamic methods
-   are used.  In the dynamic method, the compressed data is preceded by
-   an encoding of the literal/length and distance Huffman codes that are
-   to be used to decode this block.  The representation is itself Huffman
-   coded, and so is preceded by a description of that code.  These code
-   descriptions take up a little space, and so for small blocks, there is
-   a predefined set of codes, called the fixed codes.  The fixed method is
-   used if the block codes up smaller that way (usually for quite small
-   chunks), otherwise the dynamic method is used.  In the latter case, the
-   codes are customized to the probabilities in the current block, and so
-   can code it much better than the pre-determined fixed codes.
- 
-   The Huffman codes themselves are decoded using a multi-level table
-   lookup, in order to maximize the speed of decoding plus the speed of
-   building the decoding tables.  See the comments below that precede the
-   lbits and dbits tuning parameters.
+ * Inflate deflated (PKZIP's method 8 compressed) data.  The compression
+ * method searches for as much of the current string of bytes (up to a
+ * length of 258) in the previous 32 K bytes.  If it doesn't find any
+ * matches (of at least length 3), it codes the next byte.  Otherwise, it
+ * codes the length of the matched string and its distance backwards from
+ * the current position.  There is a single Huffman code that codes both
+ * single bytes (called "literals") and match lengths.  A second Huffman
+ * code codes the distance information, which follows a length code.  Each
+ * length or distance code actually represents a base value and a number
+ * of "extra" (sometimes zero) bits to get to add to the base value.  At
+ * the end of 

[PATCH v2 1/6] gzip: drop unused define checks

[Daniel P. Smith]

Dropping the define checks for PKZIP_BUG_WORKAROUND and NOMEMCPY define as they
never are set.

Signed-off-by: Daniel P. Smith 
---
 xen/common/gzip/inflate.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index 58f263d9e852..e95db2de4d9b 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -661,7 +661,6 @@ static int __init inflate_codes(
 /* do the copy */
 do {
 n -= (e = (e = WSIZE - ((d &= WSIZE-1) > w ? d : w)) > n ? 
n : e);
-#if !defined(NOMEMCPY) && !defined(DEBUG)
 if (w - d >= e) /* (this test assumes unsigned 
comparison) */
 {
 memcpy(slide + w, slide + d, e);
@@ -669,7 +668,6 @@ static int __init inflate_codes(
 d += e;
 }
 else  /* do it slow to avoid memcpy() 
overlap */
-#endif /* !NOMEMCPY */
 do {
 slide[w++] = slide[d++];
 Tracevv((stderr, "%c", slide[w-1]));
@@ -845,11 +843,7 @@ static int noinline __init inflate_dynamic(void)
 
 DEBG(" 288 || nd > 32)
-#else
 if (nl > 286 || nd > 30)
-#endif
 {
 ret = 1; /* bad lengths */
 goto out;
@@ -989,16 +979,11 @@ static int noinline __init inflate_dynamic(void)
 DEBG("dyn5d ");
 if (i == 1) {
 error("incomplete distance tree");
-#ifdef PKZIP_BUG_WORKAROUND
-i = 0;
-}
-#else
 huft_free(td);
 }
 huft_free(tl);
 ret = i;   /* incomplete code set */
 goto out;
-#endif
 }
 
 DEBG("dyn6 ");
-- 
2.30.2

[PATCH v2 0/6] Clean up of gzip decompressor

[Daniel P. Smith]

An issue ran into by hyperlaunch was the need to use the gzip decompressor
multiple times. The current implementation fails when reused due to tainting of
decompressor state from a previous usage. This series seeks to colocate the
gzip unit files under a single directory similar to the other decompression
algorithms.  To enable the refactoring of the state tracking, the code is then
cleaned up in line with Xen coding style.

Changes in v2:
- patch "xen/gzip: Colocate gunzip code files" was merged
- dropped ifdef chunks that are never enabled
- addressed formatting changes missed in v1
- replaced custom memory allocator with xalloc_bytes()
- renamed gzip_data to gzip_state
- moved gzip_state to being dynamically allocated
- changed crc table to the explicit size of uint32_t 
- instead of moving huffman tracking into state, dropped altogether

Daniel P. Smith (6):
  gzip: drop unused define checks
  gzip: clean up comments and fix code alignment
  gzip: remove custom memory allocator
  gzip: refactor state tracking
  gzip: move crc state into consilidated gzip state
  gzip: drop huffman code table tracking

 xen/common/gzip/gunzip.c  |  87 ++--
 xen/common/gzip/inflate.c | 974 ++
 2 files changed, 501 insertions(+), 560 deletions(-)

-- 
2.30.2

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

[Marek Marczykowski-Górecki]

On Wed, Apr 17, 2024 at 04:17:48PM +0200, Jan Beulich wrote:
> On 14.04.2024 02:32, Marek Marczykowski-Górecki wrote:
> > On Wed, Apr 03, 2024 at 09:10:40AM +0200, Jan Beulich wrote:
> >> 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 
> > 
> > Is any ack missing here, or has it just fallen through the cracks?
> 
> ??? (commit dd5101a6169f89b9e3f3b72f0b0fcdb38db2fb35)

Oh, sorry, somehow I missed it. All good then, thanks.

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


signature.asc
Description: PGP signature

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

[Jan Beulich]

On 14.04.2024 02:32, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 03, 2024 at 09:10:40AM +0200, Jan Beulich wrote:
>> 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 
> 
> Is any ack missing here, or has it just fallen through the cracks?

??? (commit dd5101a6169f89b9e3f3b72f0b0fcdb38db2fb35)

Jan

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Julien Grall]

Hi Michal,

On 17/04/2024 13:14, Michal Orzel wrote:

Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
for it. This results in a build failure. Example on Arm:

./include/public/arch-arm.h:205:41: error: unknown type name 
‘__guest_handle_64_int32_t’
   205 | #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
   | ^~
./include/public/arch-arm.h:206:41: note: in expansion of macro 
‘__XEN_GUEST_HANDLE’
   206 | #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
   | ^~
./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
   277 | XEN_GUEST_HANDLE(int32_t) errs;

Fix it. Also, drop guest handle definition for int given no further use.

Fixes: afab29d0882f ("public: s/int/int32_t")
Signed-off-by: Michal Orzel 


So it turned out that I committed v1 from Stefano. I was meant to commit 
the patch at all, but I think I started with a dirty staging :(. Sorry 
for that.


I have reverted Stefano's commit for now so we can take the correct patch.

Now, from my understanding, Andrew suggested on Matrix that this 
solution may actually be a good way to handle GUEST_HANLDEs (they were 
removed in v2). Maybe this can be folded in Stefano's patch?


Cheers,

--
Julien Grall

Re: [PATCH v2 1/2] x86: Add support for building a multiboot2 PE binary

[Jan Beulich]

On 10.04.2024 11:41, Ross Lagerwall wrote:
> On Mon, Apr 8, 2024 at 11:25 AM Jan Beulich  wrote:
>> On 28.03.2024 16:11, Ross Lagerwall wrote:
>>> * The image base address is set to 0 since it must necessarily be below
>>>   4 GiB and the loader will relocate it anyway.
>>
>> While technically okay, what is the reason for this adjustment?
> 
> The multiboot2 spec generally uses 32 bit addresses for everything and
> says:
> 
> "The bootloader must not load any part of the kernel, the modules, the
> Multiboot2 information structure, etc. higher than 4 GiB - 1."
> 
> An image base address above 4 GiB causes trouble because multiboot2
> wasn't designed for this.

Yet mb2 doesn't care about that PE header field at all, does it? In which
case my question remains: What purpose does this particular modification
of the image have?

Jan

[PATCH] x86/cpuid-policy: Add AMD SVM CPUID leaf to featureset

[George Dunlap]

Currently, the CPUID leaf for SVM features (extd 0xa.edx) is manually
twiddled:

 - hvm_max_policy takes host_policy and clamps it to supported
   features (with some features unilaterally enabled because they're
   always emulated

 - hvm_default_policy is copied from there

 - When recalculate_policy() is called for a guest, if SVM is clear,
   then the entire leaf is zeroed out.

Move to a mode where the extended features are off by default, and
enabled when nested_virt is enabled.

In cpufeatureset.h, define a new featureset word for the AMD SVM
features, and declare all of the bits defined in
x86/include/asm/hvm/svm/svm.h.  Mark the ones we currently pass
through to the "max policy" as HAP-only and optional.

In cpu-policy.h, define FEATURESET_ead, and convert the un-named space
in struct_cpu_policy into the appropriate union.  FIXME: Do this in a
prerequisite patch, and change all references to p->extd.raw[0xa].

Update x86_cpu_X_to_Y and Y_to_X to copy this into and out of the
appropriate leaf.

Populate this during boot in generic_identify().

Add the new featureset definition into libxl_cpuid.c.

Update the code in calculate_hvm_max_policy() to do nothing with the
"normal" CPUID bits, and use the feature bit to unconditionally enable
VMCBCLEAN. FIXME Move this to a follow-up patch.

In recalculate_cpuid_policy(), enable max_fs when nested_hvm() is
true.

Signed-off-by: George Dunlap 
---
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Roger Pau Monne 
---
 tools/libs/light/libxl_cpuid.c  |  1 +
 xen/arch/x86/cpu-policy.c   | 19 +--
 xen/arch/x86/cpu/common.c   |  2 ++
 xen/include/public/arch-x86/cpufeatureset.h | 16 
 xen/include/xen/lib/x86/cpu-policy.h| 10 +-
 xen/lib/x86/cpuid.c |  4 +++-
 6 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index ce4f3c7095..2c5749c3a0 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -342,6 +342,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*policy, const char* str)
 CPUID_ENTRY(0x0007,  1, CPUID_REG_EDX),
 MSR_ENTRY(0x10a, CPUID_REG_EAX),
 MSR_ENTRY(0x10a, CPUID_REG_EDX),
+CPUID_ENTRY(0x800a, NA, CPUID_REG_EDX),
 #undef MSR_ENTRY
 #undef CPUID_ENTRY
 };
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 4b6d962763..4a5d1b916b 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -754,14 +754,8 @@ static void __init calculate_hvm_max_policy(void)
  */
 if ( p->extd.svm )
 {
-/* Clamp to implemented features which require hardware support. */
-p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
-   (1u << SVM_FEATURE_LBRV) |
-   (1u << SVM_FEATURE_NRIPS) |
-   (1u << SVM_FEATURE_PAUSEFILTER) |
-   (1u << SVM_FEATURE_DECODEASSISTS));
 /* Enable features which are always emulated. */
-p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN);
+__set_bit(X86_FEATURE_VMCBCLEAN, fs);
 }
 
 guest_common_max_feature_adjustments(fs);
@@ -909,6 +903,14 @@ void recalculate_cpuid_policy(struct domain *d)
 __clear_bit(X86_FEATURE_VMX, max_fs);
 __clear_bit(X86_FEATURE_SVM, max_fs);
 }
+else
+{
+/* 
+ * Enable SVM features.  This will be empty on VMX
+ * hosts. 
+ */
+fs[FEATURESET_ead] = max_fs[FEATURESET_ead];
+}
 }
 
 /*
@@ -975,9 +977,6 @@ void recalculate_cpuid_policy(struct domain *d)
  ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
 p->basic.raw[0xa] = EMPTY_LEAF;
 
-if ( !p->extd.svm )
-p->extd.raw[0xa] = EMPTY_LEAF;
-
 if ( !p->extd.page1gb )
 p->extd.raw[0x19] = EMPTY_LEAF;
 }
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 28d7f34c4d..5093379a43 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -477,6 +477,8 @@ static void generic_identify(struct cpuinfo_x86 *c)
c->x86_capability[FEATURESET_e7d] = cpuid_edx(0x8007);
if (c->extended_cpuid_level >= 0x8008)
c->x86_capability[FEATURESET_e8b] = cpuid_ebx(0x8008);
+   if (c->extended_cpuid_level >= 0x800a)
+   c->x86_capability[FEATURESET_ead] = cpuid_edx(0x800a);
if (c->extended_cpuid_level >= 0x8021)
c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x8021);
 
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 53f13dec31..c5c712cca3 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -357,6 +357,22 

Re: [XEN PATCH v2 1/9] x86/vlapic: tidy switch statement and address MISRA violation

[Jan Beulich]

On 11.04.2024 14:03, Andrew Cooper wrote:
> On 09/04/2024 8:45 pm, Nicola Vetrini wrote:
>> On 2024-04-08 09:32, Jan Beulich wrote:
>>> On 05.04.2024 11:14, Nicola Vetrini wrote:
 Remove unneded blank lines between switch clauses.
>>>
>>> "Unneeded" based on what? We're carefully trying to improve
>>> readability of
>>> large switch() statements by adding such blank lines (at least)
>>> between non-
>>> fall-through case blocks, and you go and remove them?
>>>
>>> Jan
>>
>> I wrote that based on this earlier suggestion [1]. If I misunderstood
>> the suggestion, then I apologize and feel free to strip them if you want.
>>
>> [1]
>> https://lore.kernel.org/xen-devel/e40579ba-acae-4c11-bea1-a5b83208d...@suse.com/
> 
> I'm afraid I also can't figure out what that suggestion was supposed to
> be,

The main point of missing clarity there is that we still need to settle on
whether blank lines should also be between blocks where the earlier falls
through to the latter. Iirc you'd like to have blank lines in such cases
nevertheless, while I'd prefer to make the falling-through visually easy
to recognize by not putting blanks lines between the "fallthrough;" /
fall-through comment and the successive "case ...":.

Jan

> but we definitely do want to keep blank lines.  They're specifically
> for improved legibility.

Re: [PATCH v7 2/2] x86/PVH: Support relocatable dom0 kernels

[Jan Beulich]

On 08.04.2024 18:56, Jason Andryuk wrote:
> On 2024-04-08 03:00, Jan Beulich wrote:
>> On 04.04.2024 23:25, Jason Andryuk wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -537,6 +537,111 @@ static paddr_t __init find_memory(
>>>   return INVALID_PADDR;
>>>   }
>>>   
>>> +static bool __init check_load_address(
>>> +const struct domain *d, const struct elf_binary *elf)
>>> +{
>>> +paddr_t kernel_start = (uintptr_t)elf->dest_base;
>>> +paddr_t kernel_end = kernel_start + elf->dest_size;
>>> +unsigned int i;
>>
>> While properly typed here, ...
>>
>>> +static paddr_t __init find_kernel_memory(
>>> +const struct domain *d, struct elf_binary *elf,
>>> +const struct elf_dom_parms *parms)
>>> +{
>>> +paddr_t kernel_size = elf->dest_size;
>>> +unsigned int align;
>>> +int i;
>>
>> ... I must have missed when this was changed to plain int. It should have
>> been unsigned int here, too, ...
>>
>>> +if ( parms->phys_align != UNSET_ADDR32 )
>>> +align = parms->phys_align;
>>> +else if ( elf->palign >= PAGE_SIZE )
>>> +align = elf->palign;
>>> +else
>>> +align = MB(2);
>>> +
>>> +/* Search backwards to find the highest address. */
>>> +for ( i = d->arch.nr_e820 - 1; i >= 0 ; i-- )
>>
>> ... with this suitably adjusted. However, I'm not going to change this while
>> committing, to avoid screwing up.
> 
> I intentionally changed this.  Looping downwards, a signed int allows 
> writing the check naturally with i >= 0.  I think it's clearer when 
> written this way.

Just to clarify: Is

for ( i = d->arch.nr_e820; i--; )

any less clear? (While replying I also notice there's a stray blank
in the for() you have, ahead of the 2nd semicolon.)

Jan

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

[Jan Beulich]

On 11.04.2024 16:39, Oleksii wrote:
> On Wed, 2024-04-03 at 13:53 +0200, Jan Beulich wrote:
>> 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.
> It seems to me that p2m.h comes for Arm from argo.c -> xen/domain.h ->
> asm/domain.h and for x86 from argo.c -> xen/guest_access.h -> #include
>  -> asm/p2m.h.
> 
> So I can include asm/p2m.h to asm/domain.h as p2m will be used anyway
> in asm/domain.h header and drop disablement of ARGO config from
> *_defconfig and build.yaml for CI. Does it make sense?

Looks okay to ma, at a glance.

Jan

Re: [PATCH v3 9/9] xen/ppc: mm-radix: Allocate all paging structures at runtime

[Jan Beulich]

On 12.04.2024 05:19, Shawn Anastasio wrote:
> On 3/25/24 10:39 AM, Jan Beulich wrote:
>> On 14.03.2024 23:15, Shawn Anastasio wrote:
>>> -static __init struct lvl2_pd *lvl2_pd_pool_alloc(void)
>>> -{
>>> -if ( initial_lvl2_lvl3_pd_pool_used >= INITIAL_LVL2_LVL3_PD_COUNT )
>>> -{
>>> -early_printk("Ran out of space for LVL2/3 PD!\n");
>>> -die();
>>> -}
>>> +min_alloc_mfn = _mfn(min(mfn_x(min_alloc_mfn), mfn_x(mfn_first)));
>>> +max_alloc_mfn = _mfn(max(mfn_x(max_alloc_mfn), mfn_x(mfn_last)));
>>
>> Together with the comment ahead of the function - is there some kind of
>> assumption here that this range won't span almost all of system memory?
>> E.g. expecting allocations to be almost contiguous? If so, I wonder how
>> reliable this is, and whether using a rangeset wouldn't be better here.
> 
> You're right that this is only sane (i.e. not mapping almost all of
> system memory) when the assumption that alloc_boot_pages returns
> mostly-contiguous regions holds. I'm not super happy with this either,
> but I struggled to come up with a better solution that doesn't involve
> re-inventing a rangeset-like data structure.
> 
> Looking into your suggestion of using xen/common's rangeset, it looks
> like that won't work since it relies on xmalloc which is not yet set up.
> I suspect there is a chicken-and-egg problem here that would preclude
> xmalloc from sanely working this early on in the boot, but I might be
> wrong about that.
> 
> I could reinvent a basic statically-allocated rangeset data structure
> for this purpose if you think that's the best path forward.

Question is whether anything statically will actually be suitable.

Rather than re-inventing anything, I think it might be okay to keep
the logic as you have it, but with commentary added making explicit
what assumptions there are (and why, and why in the common case it is
acceptable to make such assumptions, and maybe even what to do when
any of the assumptions turns out wrong).

Jan

Re: [PATCH v3 3/9] xen/ppc: Introduce stub asm/static-shmem.h

[Jan Beulich]

On 10.04.2024 01:35, Shawn Anastasio wrote:
> On 3/25/24 10:24 AM, Jan Beulich wrote:
>> On 14.03.2024 23:15, Shawn Anastasio wrote:
>>> Required for bootfdt.c to build.
>>>
>>> Signed-off-by: Shawn Anastasio 
>>
>> As a temporary workaround this may be okay, but was the alternative
>> considered to properly provide stubs in a single central place for
>> anything !CONFIG_STATIC_SHM?
>>
> 
> I can't think of an existing place where this would cleanly fit, but if
> you have any suggestions I'm open to it.

Just like was done for ACPI and before that for NUMA, there ought to be
a respective header in include/xen/, I'd say.

Jan

[xen-unstable-smoke test] 185718: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  83e081b29e52b0ea946e30677e9caf86e9bcbc65
baseline version:
 xen  ad363fb17d720f1ad047775e1d7b70158f546c46

Last test of basis   185684  2024-04-16 20:00:22 Z0 days
Testing same since   185715  2024-04-17 10:02:13 Z0 days2 attempts


People who touched revisions under test:
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 83e081b29e52b0ea946e30677e9caf86e9bcbc65
Author: Michal Orzel 
Date:   Fri Apr 12 08:16:24 2024 +0200

docs: arm: Update where Xen should be loaded in memory

Since commit 6cd046c501bc ("xen/arm: Enlarge identity map space to 10TB")
Xen can be loaded below 10 TiB. Update docs accordingly.

Take the opportunity to update stale links to Linux docs.

Signed-off-by: Michal Orzel 
Reviewed-by: Luca Fancellu 

commit afab29d0882f1d6889c73302fdf04632a492c529
Author: Stefano Stabellini 
Date:   Tue Apr 9 16:19:21 2024 -0700

public: s/int/int32_t

Straightforward int -> int32_t and unsigned int -> uint32_t replacements
in public headers. No ABI or semantic changes intended.

Signed-off-by: Stefano Stabellini 
(qemu changes not included)

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Luca Fancellu]

Hi Michal,

> On 17 Apr 2024, at 13:14, Michal Orzel  wrote:
> 
> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> for it. This results in a build failure. Example on Arm:
> 
> ./include/public/arch-arm.h:205:41: error: unknown type name 
> ‘__guest_handle_64_int32_t’
>  205 | #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
>  | ^~
> ./include/public/arch-arm.h:206:41: note: in expansion of macro 
> ‘__XEN_GUEST_HANDLE’
>  206 | #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
>  | ^~
> ./include/public/memory.h:277:5: note: in expansion of macro 
> ‘XEN_GUEST_HANDLE’
>  277 | XEN_GUEST_HANDLE(int32_t) errs;
> 
> Fix it. Also, drop guest handle definition for int given no further use.
> 
> Fixes: afab29d0882f ("public: s/int/int32_t")
> Signed-off-by: Michal Orzel 
> ---

I’ve build it for arm64, arm32 and x86

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

Re: Serious AMD-Vi(?) issue

[Jan Beulich]

On 11.04.2024 04:41, Elliott Mitchell wrote:
> On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
>> On 27.03.2024 18:27, Elliott Mitchell wrote:
>>> On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
 On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
>
> In fact when running into trouble, the usual course of action would be to
> increase verbosity in both hypervisor and kernel, just to make sure no
> potentially relevant message is missed.

 More/better information might have been obtained if I'd been engaged
 earlier.
>>>
>>> This is still true, things are in full mitigation mode and I'll be
>>> quite unhappy to go back with experiments at this point.
>>
>> Well, it very likely won't work without further experimenting by someone
>> able to observe the bad behavior. Recall we're on xen-devel here; it is
>> kind of expected that without clear (and practical) repro instructions
>> experimenting as well as info collection will remain with the reporter.
> 
> After looking at the situation and considering the issues, I /may/ be
> able to setup for doing more testing.  I guess I should confirm, which of
> those criteria do you think currently provided information fails at?
> 
> AMD-IOMMU + Linux MD RAID1 + dual Samsung SATA (or various NVMe) +
> dbench; seems a pretty specific setup.

Indeed. If that's the only way to observe the issue, it suggests to me
that it'll need to be mainly you to do further testing, and perhaps even
debugging. Which isn't to say we're not available to help, but from all
I have gathered so far we're pretty much in the dark even as to which
component(s) may be to blame. As can still be seen at the top in reply
context, some suggestions were given as to obtaining possible further
information (or confirming the absence thereof).

I'd also like to come back to the vague theory you did voice, in that
you're suspecting flushes to take too long. I continue to have trouble
with this, and I would therefore like to ask that you put this down in
more technical terms, making connections to actual actions taken by
software / hardware.

Jan

> I could see this being criticised as impractical if /new/ devices were
> required, but the confirmed flash devices are several generations old.
> Difficulty is cheaper candidate devices are being recycled for their
> precious metal content, rather than resold as used.
> 
> 

Re: [ImageBuilder 5/5] uboot-script-gen: Add ability to specify "nr_spis"

[Michal Orzel]

On 17/04/2024 14:07, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> This is needed to have a possibility of assigning a specified number
> of shared peripheral interrupts (SPIs) to domain.
> 
> Signed-off-by: Oleksandr Tyshchenko 
> Signed-off-by: Stefano Stabellini 
Reviewed-by: Michal Orzel 

~Michal

Re: [ImageBuilder 4/5] uboot-script-gen: Add ability to unselect "vpl011"

[Michal Orzel]

On 17/04/2024 14:07, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> Introduce new option DOMU_VPL011[nr] that can be set to 0
> or 1 (default).
> 
> Also align "console=ttyAMA0" Linux cmd arg setting with "vpl011" presense.
> 
> Suggested-by: Michal Orzel 
> Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Michal Orzel 

That said, I noticed ...

> ---
>  README.md| 7 ++-
>  scripts/uboot-script-gen | 7 +--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/README.md b/README.md
> index b2459fd..63c4708 100644
> --- a/README.md
> +++ b/README.md
> @@ -151,7 +151,8 @@ Where:
>  - DOMU_KERNEL[number] specifies the DomU kernel to use.
> 
>  - DOMU_CMD[number] specifies the command line arguments for DomU's Linux
> -  kernel. If not set, then "console=ttyAMA0" is used.
> +  kernel. If not set and DOMU_VPL011[number] is not set to 0, then
> +  "console=ttyAMA0" is used.
> 
>  - DOMU_RAMDISK[number] specifies the DomU ramdisk to use.
> 
> @@ -232,6 +233,10 @@ Where:
>  - DOMU_MAPTRACK_FRAMES[number] is optional but specifies the maximum number
>of grant maptrack frames (the default value used by Xen on Arm64 is 1024)
> 
> +- DOMU_VPL011[number] is optional but used to enable (1)/disable (0) a 
> virtual
> +  PL011 UART for domain. The default is 1. If explicitly set to 0, then
> +  "console=ttyAMA0" is not used as a default DOMU_CMD[number].
> +
>  - DOMU_CPUPOOL[number] specifies the id of the cpupool (created using
>CPUPOOL[number] option, where number == id) that will be assigned to domU.
> 
> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> index adec6f9..fd37e18 100755
> --- a/scripts/uboot-script-gen
> +++ b/scripts/uboot-script-gen
> @@ -344,7 +344,10 @@ function xen_device_tree_editing()
>  add_device_tree_static_mem "/chosen/domU$i" 
> "${DOMU_STATIC_MEM[$i]}"
>  dt_set "/chosen/domU$i" "direct-map" "bool" 
> "${DOMU_DIRECT_MAP[$i]}"
>  fi
> -dt_set "/chosen/domU$i" "vpl011" "hex" "0x1"
> +if test -z "${DOMU_VPL011[$i]}" || test "${DOMU_VPL011[$i]}" -eq "1"
> +then
> +dt_set "/chosen/domU$i" "vpl011" "hex" "0x1"
... that the property type is incorrect. According to Xen docs, this should be 
a bool property.
@Stefano, can you fix it on commit?

~Michal

Re: [ImageBuilder 3/5] uboot-script-gen: Add ability to specify grant table params

[Michal Orzel]

On 17/04/2024 14:07, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> Use DOMU_GRANT_VER to set "max_grant_version" dt property.
> Use DOMU_GRANT_FRAMES to set "max_grant_frames" dt property.
> Use DOMU_MAPTRACK_FRAMES to set "max_maptrack_frames" dt property.
> 
> Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Michal Orzel 

~Michal

Re: [ImageBuilder 2/5] uboot-script-gen: Extend DOMU_ENHANCED to specify "no-xenstore"

[Michal Orzel]

On 17/04/2024 14:07, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> We need some Xen services to be available within single dom0less DomU.
> Just using "enabled" will lead to Xen panic because of no Dom0.
> 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) At the moment, Xenstore support requires dom0 to be present
> (XEN) 
> 
> Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Michal Orzel 

~Michal

Re: [ImageBuilder 1/5] uboot-script-gen: Update to deal with uImage which is not executable

[Michal Orzel]

On 17/04/2024 14:07, Oleksandr Tyshchenko wrote:
> 
> 
> From: Oleksandr Tyshchenko 
> 
> uImage is the Image that has a U-Boot wrapper, it doesn't contain
> "executable" string which subsequent "file" command is looking for
> when inspecting it.
> 
> Below the proof:
> 
> otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage.gz
> binaries/uImage.gz: u-boot legacy uImage, Linux Kernel Image, Linux/ARM 
> 64-bit,
> OS Kernel Image (gzip), 9822180 bytes, Fri Sep 29 15:39:42 2023, Load 
> Address: 0X4000,
> Entry Point: 0X4000, Header CRC: 0XE1EF21BF, Data CRC: 0XC418025
> 
> otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage
> binaries/uImage: u-boot legacy uImage, Linux Kernel Image, Linux/ARM 64-bit,
> OS Kernel Image (Not compressed), 23269888 bytes, Fri Sep 29 15:40:19 2023,
> Load Address: 0X4000, Entry Point: 0X4000, Header CRC: 0XA0B7D051,
> Data CRC: 0X42083F51
> 
> Suggested-by: Stefano Stabellini 
> Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Michal Orzel 

~Michal

[PATCH] public: xen: Define missing guest handle for int32_t

[Michal Orzel]

Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
for it. This results in a build failure. Example on Arm:

./include/public/arch-arm.h:205:41: error: unknown type name 
‘__guest_handle_64_int32_t’
  205 | #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
  | ^~
./include/public/arch-arm.h:206:41: note: in expansion of macro 
‘__XEN_GUEST_HANDLE’
  206 | #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
  | ^~
./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
  277 | XEN_GUEST_HANDLE(int32_t) errs;

Fix it. Also, drop guest handle definition for int given no further use.

Fixes: afab29d0882f ("public: s/int/int32_t")
Signed-off-by: Michal Orzel 
---
 xen/include/public/xen.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b47d48d0e2d6..8fd0cec880d5 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -28,7 +28,6 @@
 /* Guest handles for primitive C types. */
 DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
-DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
 #if __XEN_INTERFACE_VERSION__ < 0x00040300
 DEFINE_XEN_GUEST_HANDLE(long);
@@ -36,6 +35,7 @@ __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 #endif
 DEFINE_XEN_GUEST_HANDLE(void);
 
+DEFINE_XEN_GUEST_HANDLE(int32_t);
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
-- 
2.25.1

Re: [PATCH] xen/arm: imx8qm: Re-license file to GPL-2.0-only

[Julien Grall]

Hi John,

Thanks for the patch!

On 17/04/2024 01:47, Stefano Stabellini wrote:

On Tue, 16 Apr 2024, Peng Fan wrote:

Subject: [PATCH] xen/arm: imx8qm: Re-license file to GPL-2.0-only

New contributions are recommended to be under GPL-2.0-only [1], since this
code piece originally came from the NXP tree the original license was retained.

However, as discussed both Peng [2] and I [3] are ok with GPL-2.0.-only as a
license. Change the license.

Cc: Peng Fan 
Signed-off-by: John Ernberg 


Acked-by: Peng Fan 


Acked-by: Stefano Stabellini 


Acked-by: Julien Grall 

I will commit it once OSSTest has been unblocked.

Cheers,

--
Julien Grall

[ImageBuilder 5/5] uboot-script-gen: Add ability to specify "nr_spis"

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This is needed to have a possibility of assigning a specified number
of shared peripheral interrupts (SPIs) to domain.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Stefano Stabellini 
---
 README.md| 5 +
 scripts/uboot-script-gen | 4 
 2 files changed, 9 insertions(+)

diff --git a/README.md b/README.md
index 63c4708..7683492 100644
--- a/README.md
+++ b/README.md
@@ -237,6 +237,11 @@ Where:
   PL011 UART for domain. The default is 1. If explicitly set to 0, then
   "console=ttyAMA0" is not used as a default DOMU_CMD[number].
 
+- DOMU_NR_SPIS[number] is optional. It specifies a number of shared peripheral
+  interrupts (SPIs) to be assigned to domain (depending on the underlying
+  hardware platform). The minimum possible value is 0, if DOMU_VPL011[number]
+  is also explicitly set to 0. Otherwise the minimum value is 1.
+
 - DOMU_CPUPOOL[number] specifies the id of the cpupool (created using
   CPUPOOL[number] option, where number == id) that will be assigned to domU.
 
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index fd37e18..50b6a59 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -348,6 +348,10 @@ function xen_device_tree_editing()
 then
 dt_set "/chosen/domU$i" "vpl011" "hex" "0x1"
 fi
+if test -n "${DOMU_NR_SPIS[$i]}"
+then
+dt_set "/chosen/domU$i" "nr_spis" "int" "${DOMU_NR_SPIS[$i]}"
+fi
 if [[ "${DOMU_ENHANCED[$i]}" == 1 || ("$DOM0_KERNEL" && 
"${DOMU_ENHANCED[$i]}" != 0) ]]
 then
 dt_set "/chosen/domU$i" "xen,enhanced" "str" "enabled"
-- 
2.34.1

[ImageBuilder 1/5] uboot-script-gen: Update to deal with uImage which is not executable

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

uImage is the Image that has a U-Boot wrapper, it doesn't contain
"executable" string which subsequent "file" command is looking for
when inspecting it.

Below the proof:

otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage.gz
binaries/uImage.gz: u-boot legacy uImage, Linux Kernel Image, Linux/ARM 64-bit,
OS Kernel Image (gzip), 9822180 bytes, Fri Sep 29 15:39:42 2023, Load Address: 
0X4000,
Entry Point: 0X4000, Header CRC: 0XE1EF21BF, Data CRC: 0XC418025

otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage
binaries/uImage: u-boot legacy uImage, Linux Kernel Image, Linux/ARM 64-bit,
OS Kernel Image (Not compressed), 23269888 bytes, Fri Sep 29 15:40:19 2023,
Load Address: 0X4000, Entry Point: 0X4000, Header CRC: 0XA0B7D051,
Data CRC: 0X42083F51

Suggested-by: Stefano Stabellini 
Signed-off-by: Oleksandr Tyshchenko 
---
 scripts/uboot-script-gen | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 3cc6b47..7cb8c6d 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -505,9 +505,9 @@ function check_file_type()
 
 # if file doesn't know what it is, it outputs data, so include that
 # since some executables aren't recongnized
-if [ "$type" = "executable" ]
+if [[ "$type" = "executable"* ]]
 then
-type="executable\|data\|ARM OpenFirmware"
+type="$type\|data\|ARM OpenFirmware"
 # file in older distros (ex: RHEL 7.4) just output data for device
 # tree blobs
 elif [ "$type" = "Device Tree Blob" ]
@@ -712,7 +712,7 @@ xen_file_loading()
 {
 if test "$DOM0_KERNEL"
 then
-check_compressed_file_type $DOM0_KERNEL "executable"
+check_compressed_file_type $DOM0_KERNEL "executable\|uImage"
 dom0_kernel_addr=$memaddr
 load_file $DOM0_KERNEL "dom0_linux"
 dom0_kernel_size=$filesize
@@ -747,7 +747,7 @@ xen_file_loading()
 cleanup_and_return_err
 fi
 
-check_compressed_file_type ${DOMU_KERNEL[$i]} "executable"
+check_compressed_file_type ${DOMU_KERNEL[$i]} "executable\|uImage"
 domU_kernel_addr[$i]=$memaddr
 load_file ${DOMU_KERNEL[$i]} "domU${i}_kernel"
 domU_kernel_size[$i]=$filesize
-- 
2.34.1

[ImageBuilder 3/5] uboot-script-gen: Add ability to specify grant table params

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Use DOMU_GRANT_VER to set "max_grant_version" dt property.
Use DOMU_GRANT_FRAMES to set "max_grant_frames" dt property.
Use DOMU_MAPTRACK_FRAMES to set "max_maptrack_frames" dt property.

Signed-off-by: Oleksandr Tyshchenko 
---
 README.md| 10 ++
 scripts/uboot-script-gen | 13 +
 2 files changed, 23 insertions(+)

diff --git a/README.md b/README.md
index 97db7aa..b2459fd 100644
--- a/README.md
+++ b/README.md
@@ -222,6 +222,16 @@ Where:
   kernels might break. If set to 2, "no-xenstore" is specified, see Xen
   documentation about dom0less "no-xenstore" option.
 
+- DOMU_GRANT_VER[number] is optional but specifies the maximum version
+  of grant table shared structure (the maximum security supported version
+  by Xen on Arm64 is 1)
+
+- DOMU_GRANT_FRAMES[number] is optional but specifies the maximum number
+  of grant table frames (the default value used by Xen on Arm64 is 64)
+
+- DOMU_MAPTRACK_FRAMES[number] is optional but specifies the maximum number
+  of grant maptrack frames (the default value used by Xen on Arm64 is 1024)
+
 - DOMU_CPUPOOL[number] specifies the id of the cpupool (created using
   CPUPOOL[number] option, where number == id) that will be assigned to domU.
 
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 98a64d6..adec6f9 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -353,6 +353,19 @@ function xen_device_tree_editing()
 dt_set "/chosen/domU$i" "xen,enhanced" "str" "no-xenstore"
 fi
 
+if test -n "${DOMU_GRANT_VER[i]}"
+then
+dt_set "/chosen/domU$i" "max_grant_version" "int" 
"${DOMU_GRANT_VER[i]}"
+fi
+if test -n "${DOMU_GRANT_FRAMES[i]}"
+then
+dt_set "/chosen/domU$i" "max_grant_frames" "int" 
"${DOMU_GRANT_FRAMES[i]}"
+fi
+if test -n "${DOMU_MAPTRACK_FRAMES[i]}"
+then
+dt_set "/chosen/domU$i" "max_maptrack_frames" "int" 
"${DOMU_MAPTRACK_FRAMES[i]}"
+fi
+
 if test -n "${DOMU_SHARED_MEM[i]}"
 then
 add_device_tree_static_shared_mem "/chosen/domU${i}" 
"${DOMU_SHARED_MEM[i]}"
-- 
2.34.1

[ImageBuilder 4/5] uboot-script-gen: Add ability to unselect "vpl011"

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Introduce new option DOMU_VPL011[nr] that can be set to 0
or 1 (default).

Also align "console=ttyAMA0" Linux cmd arg setting with "vpl011" presense.

Suggested-by: Michal Orzel 
Signed-off-by: Oleksandr Tyshchenko 
---
 README.md| 7 ++-
 scripts/uboot-script-gen | 7 +--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index b2459fd..63c4708 100644
--- a/README.md
+++ b/README.md
@@ -151,7 +151,8 @@ Where:
 - DOMU_KERNEL[number] specifies the DomU kernel to use.
 
 - DOMU_CMD[number] specifies the command line arguments for DomU's Linux
-  kernel. If not set, then "console=ttyAMA0" is used.
+  kernel. If not set and DOMU_VPL011[number] is not set to 0, then
+  "console=ttyAMA0" is used.
 
 - DOMU_RAMDISK[number] specifies the DomU ramdisk to use.
 
@@ -232,6 +233,10 @@ Where:
 - DOMU_MAPTRACK_FRAMES[number] is optional but specifies the maximum number
   of grant maptrack frames (the default value used by Xen on Arm64 is 1024)
 
+- DOMU_VPL011[number] is optional but used to enable (1)/disable (0) a virtual
+  PL011 UART for domain. The default is 1. If explicitly set to 0, then
+  "console=ttyAMA0" is not used as a default DOMU_CMD[number].
+
 - DOMU_CPUPOOL[number] specifies the id of the cpupool (created using
   CPUPOOL[number] option, where number == id) that will be assigned to domU.
 
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index adec6f9..fd37e18 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -344,7 +344,10 @@ function xen_device_tree_editing()
 add_device_tree_static_mem "/chosen/domU$i" 
"${DOMU_STATIC_MEM[$i]}"
 dt_set "/chosen/domU$i" "direct-map" "bool" 
"${DOMU_DIRECT_MAP[$i]}"
 fi
-dt_set "/chosen/domU$i" "vpl011" "hex" "0x1"
+if test -z "${DOMU_VPL011[$i]}" || test "${DOMU_VPL011[$i]}" -eq "1"
+then
+dt_set "/chosen/domU$i" "vpl011" "hex" "0x1"
+fi
 if [[ "${DOMU_ENHANCED[$i]}" == 1 || ("$DOM0_KERNEL" && 
"${DOMU_ENHANCED[$i]}" != 0) ]]
 then
 dt_set "/chosen/domU$i" "xen,enhanced" "str" "enabled"
@@ -677,7 +680,7 @@ function xen_config()
 then
 DOMU_VCPUS[$i]=1
 fi
-if test -z "${DOMU_CMD[$i]}"
+if test -z "${DOMU_CMD[$i]}" && (test -z "${DOMU_VPL011[$i]}" || test 
"${DOMU_VPL011[$i]}" -eq "1")
 then
 DOMU_CMD[$i]="console=ttyAMA0"
 fi
-- 
2.34.1

[ImageBuilder 0/5] Misc updates for the dom0less support

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Hello all,

this is a collection of patches (#2-5) for improving the dom0less support
and a patch (#1) for dealing with uImage.  

Oleksandr Tyshchenko (5):
  uboot-script-gen: Update to deal with uImage which is not executable
  uboot-script-gen: Extend DOMU_ENHANCED to specify "no-xenstore"
  uboot-script-gen: Add ability to specify grant table params
  uboot-script-gen: Add ability to unselect "vpl011"
  uboot-script-gen: Add ability to specify "nr_spis"

 README.md| 29 +
 scripts/uboot-script-gen | 35 +--
 2 files changed, 54 insertions(+), 10 deletions(-)

-- 
2.34.1

[ImageBuilder 2/5] uboot-script-gen: Extend DOMU_ENHANCED to specify "no-xenstore"

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

We need some Xen services to be available within single dom0less DomU.
Just using "enabled" will lead to Xen panic because of no Dom0.

(XEN) 
(XEN) Panic on CPU 0:
(XEN) At the moment, Xenstore support requires dom0 to be present
(XEN) 

Signed-off-by: Oleksandr Tyshchenko 
---
 README.md| 7 ---
 scripts/uboot-script-gen | 3 +++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 3b4b16f..97db7aa 100644
--- a/README.md
+++ b/README.md
@@ -217,9 +217,10 @@ Where:
   If set to 1, the VM is direct mapped. The default is 1.
   This is only applicable when DOMU_STATIC_MEM is specified.
 
-- DOMU_ENHANCED[number] can be set to 1 or 0, default is 1 when Dom0 is
-  present. If set to 1, the VM can use PV drivers. Older Linux kernels
-  might break.
+- DOMU_ENHANCED[number] can be set to 0, 1, or 2. Default is 1 when Dom0
+  is present. If set to 1, the VM can use PV drivers. Older Linux
+  kernels might break. If set to 2, "no-xenstore" is specified, see Xen
+  documentation about dom0less "no-xenstore" option.
 
 - DOMU_CPUPOOL[number] specifies the id of the cpupool (created using
   CPUPOOL[number] option, where number == id) that will be assigned to domU.
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 7cb8c6d..98a64d6 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -348,6 +348,9 @@ function xen_device_tree_editing()
 if [[ "${DOMU_ENHANCED[$i]}" == 1 || ("$DOM0_KERNEL" && 
"${DOMU_ENHANCED[$i]}" != 0) ]]
 then
 dt_set "/chosen/domU$i" "xen,enhanced" "str" "enabled"
+elif [ "${DOMU_ENHANCED[$i]}" == 2 ]
+then
+dt_set "/chosen/domU$i" "xen,enhanced" "str" "no-xenstore"
 fi
 
 if test -n "${DOMU_SHARED_MEM[i]}"
-- 
2.34.1

[xen-unstable-smoke test] 185715: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  83e081b29e52b0ea946e30677e9caf86e9bcbc65
baseline version:
 xen  ad363fb17d720f1ad047775e1d7b70158f546c46

Last test of basis   185684  2024-04-16 20:00:22 Z0 days
Testing same since   185715  2024-04-17 10:02:13 Z0 days1 attempts


People who touched revisions under test:
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 83e081b29e52b0ea946e30677e9caf86e9bcbc65
Author: Michal Orzel 
Date:   Fri Apr 12 08:16:24 2024 +0200

docs: arm: Update where Xen should be loaded in memory

Since commit 6cd046c501bc ("xen/arm: Enlarge identity map space to 10TB")
Xen can be loaded below 10 TiB. Update docs accordingly.

Take the opportunity to update stale links to Linux docs.

Signed-off-by: Michal Orzel 
Reviewed-by: Luca Fancellu 

commit afab29d0882f1d6889c73302fdf04632a492c529
Author: Stefano Stabellini 
Date:   Tue Apr 9 16:19:21 2024 -0700

public: s/int/int32_t

Straightforward int -> int32_t and unsigned int -> uint32_t replacements
in public headers. No ABI or semantic changes intended.

Signed-off-by: Stefano Stabellini 
(qemu changes not included)

[PATCH v8 17/17] 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-V8:
 - 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.44.0

[PATCH v8 03/17] 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 
---
 The patch is almost independent from Andrew's patch series
 ( 
https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.coop...@citrix.com/T/#t)
 except test_fls() function which IMO can be merged as a separate patch after 
Andrew's patch
 will be fully ready.
---
Changes in V8:
 - do proper rebase: back definition of fls{l} to the current patch.
 - drop the changes which removed ffz() in PPC. it should be done not
   in this patch.
 - add a message after Signed-off.
---
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/ppc/include/asm/bitops.h   |  3 ---
 xen/arch/x86/include/asm/bitops.h   |  6 --
 xen/common/bitops.c | 22 ++
 xen/include/xen/bitops.h| 24 
 7 files changed, 55 insertions(+), 15 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/ppc/include/asm/bitops.h 
b/xen/arch/ppc/include/asm/bitops.h
index e2b6473c8c..ca308fd62b 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -119,9 +119,6 @@ static inline int test_and_set_bit(unsigned int nr, 
volatile void *addr)
 (volatile unsigned int *)addr + BITOP_WORD(nr)) != 0;
 }
 
-#define flsl(x) generic_flsl(x)
-#define fls(x) generic_fls(x)
-
 /* Based on linux/include/asm-generic/bitops/ffz.h */
 /*
  * ffz - find first zero in word.
diff --git a/xen/arch/x86/include/asm/bitops.h 
b/xen/arch/x86/include/asm/bitops.h
index 2b2d9219ef..5d5b9445c5 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -430,7 +430,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;
 
@@ -440,8 +440,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;
 
@@ -451,6 +452,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 

[PATCH v8 16/17] xen/riscv: enable full Xen build

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Jan Beulich 
---
Changes in V5-V8:
 - 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 9f3ed4ff06..53f3575e7d 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;
-

[PATCH v8 12/17] 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-V8:
 - 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.44.0

[PATCH v8 06/17] 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 V8:
 - use __bad_{xchg,cmpxch}(ptr,size) insetead of STATIC_ASSERT_UNREACHABLE() to
   make this patch be independent from the macros that haven't been committed 
yet
   and may never be.
---
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
   

[PATCH v8 14/17] xen/riscv: introduce vm_event_*() functions

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
---
Changes in V5-V8:
 - 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.44.0

[PATCH v8 09/17] xen/riscv: introduce monitor.h

[Oleksii Kurochko]

Signed-off-by: Oleksii Kurochko 
---
Changes in V4-V8:
 - 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.44.0

[PATCH v8 00/17] 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]

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.
As an option, it can be considered to merge arch-specific patch and then just
rebase [2] and drop arch-specific changes.

[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/

---
Changes in V7:
 - Patch was merged to staging:
- [PATCH v7 01/19] automation: introduce fixed randconfig for RISC-V
- [PATCH v7 03/19] xen/riscv: introduce extenstion support check by compiler
 - Other changes are specific to specific patches. Please look at changes for
   specific patch.
 - Update the commit message:
 - drop the dependency from STATIC_ASSERT_UNREACHABLE() implementation.
 - Add suggestion to merge arch-specific changes related to __read_mostly.
---
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] 

[PATCH v8 10/17] 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.

Considering that there is still no still final decision regarding patch [2] my 
suggestion
is to merge RISC-V specific patch and just drop the changes in patch [2].

[2] 
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
---
Change in V8:
 - update the footer after Signed-off.
---
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.44.0

[PATCH v8 15/17] 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 */

[PATCH v8 13/17] 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 V8:
 - Nothing changed only rebase.
---
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 {
+

[PATCH v8 04/17] 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 
Acked-by: Shawn Anastasio 
---
Changes in V8:
 - drop ffz() for PPC as there is no any usage of it and it seems to me that it 
was
   introduced only because Arm has it, and Arm uses it only in find-next-bit.c 
where
   ffz() was moved to.
 - add Acked-by: Shawn Anastasio  for PPC 
part.
---
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   | 21 -
 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(+), 42 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 ca308fd62b..2237b9f8f4 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -119,15 +119,6 @@ static inline int test_and_set_bit(unsigned int nr, 
volatile void *addr)
 (volatile unsigned int *)addr + BITOP_WORD(nr)) != 0;
 }
 
-/* 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))
-
 /**
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
@@ -139,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.44.0

[PATCH v8 07/17] 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 
Acked-by: Jan Beulich 
---
Changes in V8:
 - Add Acked-by: Jan Beulich .
---
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 

[PATCH v8 11/17] 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-V8:
 - 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.44.0

[PATCH v8 08/17] 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.
 - some ATOMIC_OP() macros were updated:
   - drop size argument for ATOMIC_OP which defines atomic##prefix##_xchg()
 and atomic##prefix##_cmpxchg().
   - drop c_op argument for ATOMIC_OPS which defines ATOMIC_OPS(and, and),
 ATOMIC_OPS( or,  or), ATOMIC_OPS(xor, xor), ATOMIC_OPS(add, add, +),
 ATOMIC_OPS(sub, add, -) as c_op is always "+" for them.
   - drop "" from definition of __atomic_{acquire/release"}_fence.

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 V8:
 - drop "" in __atomic_{acquire, release}_fence().
 - code style fixes in atomic##prefix##_##op##_return(): indentation.
 - drop an unary_op argument ("+") for ATOMIC_OPS(and, and), ATOMIC_OPS( or,  
or), ATOMIC_OPS(xor, xor)
   and use "+" directly inside definition of ATOMIC_OPS().
 - drop c_op for ATOMIC_OPS(add, add, +) and ATOMIC_OPS(sub, add, -) as it is 
always "+" for now.
   Just use "+" inside definition of ATOMIC_OPS().
 - drop size argument for ATOMIC_OP() defintions of 
atomic##prefix##_{xchg,cmpxchg}()
 - update the commit message.
---
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 

[PATCH v8 05/17] 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

Signed-off-by: Oleksii Kurochko 
---
Changes in V8:
 - define bitop_uint_t in  after the changes in patch related to 
introduction of
   "introduce generic non-atomic test_*bit()".
 - drop duplicated __set_bit() and __clear_bit().
 - drop duplicated comment: /* Based on linux/arch/include/asm/bitops.h */.
 - update type of res and mask in test_and_op_bit_ord(): unsigned long -> 
bitop_uint_t.
 - drop 1 padding blank in test_and_op_bit_ord().
 - update definition of 
test_and_set_bit(),test_and_clear_bit(),test_and_change_bit:
   change return type to bool.
 - change addr argument type of test_and_change_bit(): unsigned long * -> void 
*.
 - move test_and_change_bit() closer to other test_and-s function.
 - Code style fixes: tabs -> space.
 - s/#undef __op_bit/#undef op_bit.
 - update the commit message: delete information about generic-non-atomic.h 
changes as now
   it is a separate patch.
---
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 | 137 
 xen/arch/riscv/include/asm/types.h  |   4 +
 2 files changed, 141 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..21db8d1600
--- /dev/null
+++ b/xen/arch/riscv/include/asm/bitops.h
@@ -0,0 +1,137 @@
+/* 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 
+
+#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
+
+/* 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)
+
+#define test_and_op_bit_ord(op, mod, nr, addr, ord) \
+({  \
+bitop_uint_t 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 bool 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 bool test_and_clear_bit(int nr, volatile void *p)
+{
+volatile bitop_uint_t *addr = p;
+
+return test_and_op_bit(and, NOT, nr, addr);
+}
+
+/**
+ * test_and_change_bit - Toggle (change) a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory 

[PATCH v8 02/17] xen: introduce generic non-atomic test_*bit()

[Oleksii Kurochko]

The following generic functions were introduced:
* 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 make bitop bad size check generic too, so
arch_check_bitop_size() was introduced and defined as empty for other
architectures except x86.

Signed-off-by: Oleksii Kurochko 
---
   The context ("* Find First Set bit.  Bits are labelled from 1." in 
xen/bitops.h )
   suggests there's a dependency on an uncommitted patch. It happens becuase 
the current patch
   series is based on Andrew's patch series ( 
https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.coop...@citrix.com/T/#t
 ),
   but if everything is okay with the current one patch it can be merged 
without Andrew's patch series being merged.
---
 Changes in V8:
  - drop __pure for function which uses volatile.
  - drop unnessary () in generic__test_and_change_bit() for addr casting.
  - update prototype of generic_test_bit() and test_bit(): now it returns bool
instead of int.
  - update generic_test_bit() to use BITOP_MASK().
  - Deal with fls{l} changes: it should be in the patch with introduced generic 
fls{l}.
  - add a footer with explanation of dependency on an uncommitted patch after 
Signed-off.
  - abstract bitop_size().
  - move BITOP_TYPE define to .
---
 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 |  52 
 xen/arch/ppc/include/asm/page.h   |   2 +-
 xen/arch/ppc/mm-radix.c   |   2 +-
 xen/arch/x86/include/asm/bitops.h |  30 +++
 xen/include/xen/bitops.h  | 127 ++
 xen/include/xen/types.h   |   5 ++
 8 files changed, 145 insertions(+), 141 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 = 

[PATCH v8 01/17] xen/riscv: disable unnecessary configs

[Oleksii Kurochko]

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.

Remove lines related to disablement of configs which aren't affected
compilation:
 -# 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_SPECULATIVE_HARDEN_ARRAY is not set

To allow CONFIG_ARGO build happy it was included  to 
as ARGO requires p2m_type_t ( p2m_ram_rw ) and declaration of
check_get_page_from_gfn() from xen/p2m-common.h.

Also, it was included  to asm/p2m.h as after the latter was
included to  the compilation error that EINVAL, EOPNOTSUPP
aren't declared started to occur.

CONFIG_XSM=n as it requires an introduction of:
* boot_module_find_by_kind()
* BOOTMOD_XSM
* struct bootmodule
* copy_from_paddr()
The mentioned things aren't introduced now.

CPU_BOOT_TIME_CPUPOOLS requires an introduction of cpu_physical_id() and
acpi_disabled, so it is disabled for now.

Signed-off-by: Oleksii Kurochko 
---
Changes in V8:
 - disabled CPU_BOOT_TIME_CPUPOOLS as it requires an introduction of 
cpu_physical_id() and acpi_disabled.
 - leave XSM disabled, add explanation in the commit message.
 - drop HYPFS as the patch was provided to resolve compilation issue when this 
condif is enabled for RISC-V.
 - include asm/p2m.h to asm/domain.h, and xen/errno.h to asm/p2m.h to drop ARGO 
config from
   tiny64_defconfing and build.yaml.
 - update the commit message.
---
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 |  4 
 xen/arch/riscv/configs/tiny64_defconfig | 12 +---
 xen/arch/riscv/include/asm/domain.h |  2 ++
 xen/arch/riscv/include/asm/p2m.h|  2 ++
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index aac29ee13a..a1dce6cefd 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -515,10 +515,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
 .riscv-fixed-randconfig:
   variables: 
 EXTRA_FIXED_RANDCONFIG: |
+  CONFIG_BOOT_TIME_CPUPOOLS=n
   CONFIG_COVERAGE=n
   CONFIG_EXPERT=y
   CONFIG_GRANT_TABLE=n
   CONFIG_MEM_ACCESS=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..fc7a04872f 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -1,12 +1,10 @@
-# 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_BOOT_TIME_CPUPOOLS is not set
 # CONFIG_GRANT_TABLE is not set
-# CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
 # CONFIG_MEM_ACCESS 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
diff --git a/xen/arch/riscv/include/asm/domain.h 
b/xen/arch/riscv/include/asm/domain.h
index 027bfa8a93..16a9dd57aa 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include 
+
 struct hvm_domain
 {
 uint64_t  params[HVM_NR_PARAMS];
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 87b13f8979..aa86fa10a7 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -2,6 +2,8 @@
 #ifndef __ASM_RISCV_P2M_H__
 #define __ASM_RISCV_P2M_H__
 
+#include 
+
 #include 
 
 #define paddr_bits PADDR_BITS
-- 
2.44.0

Re: [PATCH] docs: arm: Update where Xen should be loaded in memory

[Julien Grall]

Hi,

On 12/04/2024 07:41, Luca Fancellu wrote:




On 12 Apr 2024, at 07:16, Michal Orzel  wrote:

Since commit 6cd046c501bc ("xen/arm: Enlarge identity map space to 10TB")
Xen can be loaded below 10 TiB. Update docs accordingly.

Take the opportunity to update stale links to Linux docs.

Signed-off-by: Michal Orzel 
---


Reviewed-by: Luca Fancellu 


Committed. Thanks!

Cheers,

--
Julien Grall

Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Luca Fancellu]

Hi Stefano,

> Other deviations:
> -
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index b7b447e152..00db02ad34 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -652,12 +652,38 @@ maintainers if you want to suggest a change.
>declared
>  - See comment for Rule 21.1
> 
> +   * - `Rule 21.6 
> `_
> + - Required
> + - The Standard Library input/output routines shall not be used
> + - See the snprintf() and vsnprintf() deviation in deviations.rst
> +
>* - `Rule 21.13 
> `_
>  - Mandatory
>  - Any value passed to a function in  shall be representable as 
> an
>unsigned char or be the value EOF
>  -
> 
> +   * - `Rule 21.14 
> `_
> + - Required
> + - The Standard Library function memcmp shall not be used to compare
> +   null terminated strings
> + -
> +
> +   * - `Rule 21.15 
> `_
> + - Required
> + - The pointer arguments to the Standard Library functions memcpy,
> +   memmove and memcmp shall be pointers to qualified or unqualified
> +   versions of compatible types 

There is a trailing space at the end of this line

> + - void* arguments are allowed, see deviations.rst
> +
> +   * - `Rule 21.16 
> `_
> + - Required
> + - The pointer arguments to the Standard Library function memcmp
> +   shall point to either a pointer type, an essentially signed type,
> +   an essentially unsigned type, an essentially Boolean type or an
> +   essentially enum type

Also here.

> + -
> +
>* - `Rule 21.17 
> `_
>  - Mandatory
>  - Use of the string handling functions from  shall not result 
> in
> 

Apart from them, that I guess can be addressed on commit, it looks good to me,
I’ve also tested that the changes don’t break convert_misra_doc.py build.

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

Re: [PATCH] xen/efi: Rewrite DOS/PE magic checking without memcmp()

[Roger Pau Monné]

On Tue, Apr 16, 2024 at 04:52:51PM +0100, Andrew Cooper wrote:
> Misra Rule 21.16 doesn't like the use of memcmp() between a string literal and
> a UINT8 array.  Rewrite using plain compares.

The commit message makes it look like it's a type mismatch issue
between the two elements being compared, but from my reading of the
rule the issue is with the usage of a char pointer with memcmp().
IOW: even if the two parameters are char pointers it would still be a
violation.

"Misra Rule 21.16 forbids the use of memcmp() against character
arrays.  Rewrite using plain compares since checking for "PE\0\0"
cannot be done using strncmp()."

> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

LGTM (possibly pending the adjustment of the commit message):

Acked-by: Roger Pau Monné 

One question below to ensure my understating is correct.

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> CC: consult...@bugseng.com 
> CC: Roberto Bagnara 
> CC: Federico Serafini 
> CC: Nicola Vetrini 
> ---
>  xen/common/efi/pe.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/efi/pe.c b/xen/common/efi/pe.c
> index a84992df9afe..ef8a2543e0a1 100644
> --- a/xen/common/efi/pe.c
> +++ b/xen/common/efi/pe.c
> @@ -111,7 +111,8 @@ const void *__init pe_find_section(const void *image, 
> const UINTN image_size,
>  UINTN offset, i;
>  
>  if ( image_size < sizeof(*dos) ||
> - memcmp(dos->Magic, "MZ", 2) != 0 )
> + dos->Magic[0] != 'M' ||
> + dos->Magic[1] != 'Z' )

For this one you could likely use strncmp()?

>  return NULL;
>  
>  offset = dos->ExeHeader;
> @@ -119,7 +120,10 @@ const void *__init pe_find_section(const void *image, 
> const UINTN image_size,
>  
>  offset += sizeof(*pe);
>  if ( image_size < offset ||
> - memcmp(pe->Magic, "PE\0\0", 4) != 0 )
> + pe->Magic[0] != 'P' ||
> + pe->Magic[1] != 'E' ||
> + pe->Magic[2] != '\0' ||
> + pe->Magic[3] != '\0' )

This one with the double null terminator is indeed not suitable to be
checked using strncmp().

Thanks, Roger.